Hi Santiago, This is what I have: Global: log syslog {debug, trace, info, remote, warning, error, auth, fatal, bug}; Each BGP neighbor: debug { states, events }; It should be enough right? In syslog I cannot see BGP up "established" and BGP "down" messages :( Cheers, Jimmy On 12/3/13 11:35 PM, "Ondrej Zajicek" <santiago@crfreenet.org> wrote:

On Tue, Mar 12, 2013 at 10:24:33PM +0800, Jimmy Halim wrote:

...

Hi guys,

Can I confirm with you guys that syslog is only logging the event for BGP Notification errors only? I mean, it does not log the BGP session up and down event?

Depends on config. By default, only warnings and errors are logged. If you want more, use appropriate 'debug' option, like 'debug {events};' protocol option or 'debug protocols {events};' global option.

-- Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

Hi Santiago, We are getting it now after we set the syslog severity to debug. Just wondering, is it possible for you guys to include the BGP up and down event under "info" severity? If not I guess the syslog will be flooded with those unwanted debugging events. Mar 13 14:14:35 Birdy bird6: Testing_601: Down Mar 13 14:04:20 Birdy bird6: Testing_601: State changed to up Thanks, Jimmy On 13/3/13 12:41 AM, "Ondrej Zajicek" <santiago@crfreenet.org> wrote:

On Wed, Mar 13, 2013 at 12:01:23AM +0800, Jimmy Halim wrote:

...

Hi Santiago,

This is what I have:

Global: log syslog {debug, trace, info, remote, warning, error, auth, fatal, bug};

Each BGP neighbor: debug { states, events };

It should be enough right? In syslog I cannot see BGP up "established" and BGP "down" messages :(

Yes this is OK, you should see:

BGP session established

BGP session closed

You could try log "filename" instead of log debug. If you would see that in direct file log and not in syslog-based log, then probably it is an issue in your syslog config.

BTW, you can also use 'log syslog all' instead of 'log syslog { ... }'.

-- Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

On 29.3.2013 13:40, Jimmy Halim wrote:

Hi guys,

Hi Jimmy! I have never seen this. Can you send me relevant parts of the BIRD configuration? And did you try to debug this protocol in BIRD? Ondrej

We have just moved 1 of our route server from OpenBGPd to BIRD this morning. However we were having issue bringing up 1 BGP session with our peering that is running ASR. We keep getting hold timer expired error. The BGP keep flapping every 2 minutes.

...

From the tcpdump, I can see we are getting destination unreachable due to destination host is administratively prohibited.

Have u guys encountered this issue? All other BGP with other peering are working ok. Below is the log from ASR..

Logs from ASR -------------

RP/0/RP0/CPU0:Mar 29 07:48:19.078 UTC: bgp[1044]: %ROUTING-BGP-5-ADJCHANGE : neighbor 119.27.63.253 Up (VRF: default) RP/0/RP0/CPU0:Mar 29 07:49:53.328 UTC: tcp[355]: %IP-TCP_NSR-5-DISABLED : 119.27.63.38:28514 <-> 119.27.63.253:179:: NSR disabled for TCP connection because Retransmission threshold exceeded RP/0/RP0/CPU0:Mar 29 07:49:53.343 UTC: bgp[1044]: %ROUTING-BGP-3-NBR_NSR_DISABLED : NSR disabled on neighbor 119.27.63.253 due to TCP retransmissions RP/0/RP1/CPU0:Mar 29 07:49:53.357 UTC: bgp[1044]: %ROUTING-BGP-5-NBR_NSR_DISABLED_STANDBY : NSR disabled on neighbor 119.27.63.253 on standby due to Peer closing down the session (VRF: default)

Thanks, Jimmy

I'm having a problem with sending a default route. I have two providers I provide a full routing table to through BGP. I'm trying to set up a 3rd BGP session on another interface to a downstream client, so I can take his announced prefixes and announce them to my upstream ISPs. The main issue is they only want me to export the default route (0.0.0.0/0) to them, not the full table. Does anyone have a simple example of this, exporting just the default route to a downstream client, but accepting his prefix (X.X.X.X/24).

Yeah, I've tried similar to that. I'm using multiple kernel tables and pipes though, so it is a little more complicated then that. Let me give you my config for that bgp session. define myas = 54XXX; define linkc = 16XXX; define gatewayc = X.X.X.X; . . . protocol static static_default_route { route 0.0.0.0/0 reject; } function net_linkc() { ## ip blocks they can export return net ~ [ X.X.X.X/22+ ]; } dunction rt_import_linkc() { if net_linkc() then return true; return false; } function rt_export_linkc() { if proto = "static_default_route" then return true; if source != RTS_BGP then return false; if net_martian() then return false; if bgp_path.len > 64 then return false; return bgp_path.first ~ [ myas, linkc ]; } protocol kernal k_c { table ispc; export all; kernal table 5; scan time 15; } filter bgp_in_uplink_c { if ! rt_import_linkc() then reject; accept; } filter bgp_out_uplink_c { if ! rt_export_linkc() then reject; accept; } protocol pipe p_c { table master peer table ispc; import filter bgp_in_uplink_c; export filter bgp_out_uplink_c; } protocol bgp bgp_c { table ispc; import all; export all; local as myas; neighbor gatewayc as linkc; } -----Original Message----- From: "Wojciech Dec" <wojtek@systemx.com.pl> Sent: Friday, March 29, 2013 3:25pm To: bird-users@atrey.karlin.mff.cuni.cz Subject: Re: BGP Default route W dniu 2013-03-29 23:15, dspazman@epicup.com pisze:

I'm having a problem with sending a default route.

I have two providers I provide a full routing table to through BGP. I'm trying to set up a 3rd BGP session on another interface to a downstream client, so I can take his announced prefixes and announce them to my upstream ISPs. The main issue is they only want me to export the default route (0.0.0.0/0) to them, not the full table.

Does anyone have a simple example of this, exporting just the default route to a downstream client, but accepting his prefix (X.X.X.X/24).

Hi, Maybe this is not the best solution but it works :) Make a new protocol protocol static default_originate { route 0.0.0.0/0 reject; } add to a export filter if proto = "default_originate" then { accept; } regards

So I had to give up a bandwidth customer because of this situation. I really want to track down what it could be though. I was able to ping their router. We had an established BGP session. They were on a cisco unit, I'm using Bird. I could see all the routes in my table. I could run show protocols all <protocol> and see the filter filtering down the full routing table to just export 4 routes (one was the default route, other three were just 3 more we were trying). I could run show route export <protocol> and see the 4 routes listed as being exported. But they never saw any routes. They never got my announced routes. But it was an established BGP session. Any ideas?

Yeah, it showed all 4 routes as exported. The only thing else I could think of was there was a level 2 smart switch between the two routers (mine and theirs). I wouldn't think that would make any effect, as the machines could ping each other fine and establish a session fine. -----Original Message----- From: "Martin Kraus" <martin.kraus@wujiman.net> Sent: Monday, April 1, 2013 2:20am To: dspazman@epicup.com Cc: "bird-users@bird.network.cz" <bird-users@trubka.network.cz> Subject: Re: Got to ask, any ideas? On Mon, Apr 01, 2013 at 12:24:20AM -0700, dspazman@epicup.com wrote:

So I had to give up a bandwidth customer because of this situation. I really want to track down what it could be though.

I was able to ping their router. We had an established BGP session. They were on a cisco unit, I'm using Bird. I could see all the routes in my table. I could run show protocols all <protocol> and see the filter filtering down the full routing table to just export 4 routes (one was the default route, other three were just 3 more we were trying). I could run show route export <protocol> and see the 4 routes listed as being exported.

But they never saw any routes. They never got my announced routes. But it was an established BGP session.

Any ideas?

If you do show proto <name of bgp proto> all does it show in the Routes: line any exported routes? mk

They were running a cisco router. They would do this: show ip bgp neighbors X.X.X.X received-routes And get: Total number of prefixes 0 Apparently. I never saw it, but that is what they would tell me. -----Original Message----- From: "Martin Kraus" <martin.kraus@wujiman.net> Sent: Monday, April 1, 2013 1:40pm To: dspazman@epicup.com Cc: "bird-users@bird.network.cz" <bird-users@trubka.network.cz> Subject: Re: Got to ask, any ideas? On Mon, Apr 01, 2013 at 11:55:02AM -0700, dspazman@epicup.com wrote:

Yeah, it showed all 4 routes as exported.

The only thing else I could think of was there was a level 2 smart switch between the two routers (mine and theirs). I wouldn't think that would make any effect, as the machines could ping each other fine and establish a session fine.

How do you know they didn't receive those routes? Do you have output from their #show ip bgp neighbor <ip> #show ip bgp neighbor <ip> routes mk

Yeah, that was basically the "route" I had been going through. I have two upstream ISPs that get my routes fine, and that I get the routes from them fine. But I tried probably 20 different bird config versions (using pipes, filters on the pipes, not using pipes, filters on the table itself, and he never got anything to show up. I think I'm just going to maybe call it a problem on his end, maybe his cisco router was not set to accept my ASN or something I guess. Just seems weird, curious if there was something basic that I was overlooking. But it doesn't sound like it. The intercepting of packets was a good call for troubleshooting too, but the client already moved on. I was just trying to do a postmortem on the situation to see if it really was my fault for some reason. I actually think I'm going to pick up an old Cisco switch and set up a BGP session between it and my bird router on that port, just to be 100% sure that everything was set up right on my side. If I do find anything though I'll pass it along. -----Original Message----- From: "Christian Lyra" <lyra@pop-pr.rnp.br> Sent: Monday, April 1, 2013 2:48pm To: "bird-users@bird.network.cz" <bird-users@trubka.network.cz> Subject: Re: Got to ask, any ideas? Hi, I would check the basics... do you have a route for the networks you are exporting? The cisco router has a route to the gateway of the exported networks. From where came the routes (from the router itself or you learn it from another procotol/peer)? On Mon, Apr 1, 2013 at 6:29 PM, <dspazman@epicup.com> wrote:

They were running a cisco router. They would do this:

show ip bgp neighbors X.X.X.X received-routes

And get:

Total number of prefixes 0

Apparently. I never saw it, but that is what they would tell me.

-----Original Message----- From: "Martin Kraus" <martin.kraus@wujiman.net> Sent: Monday, April 1, 2013 1:40pm To: dspazman@epicup.com Cc: "bird-users@bird.network.cz" <bird-users@trubka.network.cz> Subject: Re: Got to ask, any ideas?

On Mon, Apr 01, 2013 at 11:55:02AM -0700, dspazman@epicup.com wrote:

...

Yeah, it showed all 4 routes as exported.

The only thing else I could think of was there was a level 2 smart switch between the two routers (mine and theirs). I wouldn't think that would make any effect, as the machines could ping each other fine and establish a session fine.

How do you know they didn't receive those routes? Do you have output from their

#show ip bgp neighbor <ip>

#show ip bgp neighbor <ip> routes

mk

-- Christian Lyra PoP-PR/RNP

On Mon, Apr 01, 2013 at 01:31:59PM +0800, Jimmy Halim wrote:

Hi guys,

Interestingly, actually the BGP packets from that particular peers are not hitting the permitted filter in my server: ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:bgp

Problem is solved after I changed the filter to: ACCEPT tcp -- anywhere anywhere tcp dpt:bgp

I have no clue why only this peer is having the issue with my route server. Let me know if you guys have any clue.

Hi. Could you describe where are you hitting your problem? Does the bgp session establish? Do the routers finish exchanging routing information? Which router is hitting the hold time? Did the same machine work with your old routing daemon against the same ASR before switching to bird? Did you do any other changes to it while switching to bird? mk

On Wed, Apr 03, 2013 at 11:15:27AM +0800, Jimmy Halim wrote:

...

Does the bgp session establish? [Jimmy] Yes Do the routers finish exchanging routing information? [Jimmy] Nope, we did not receive any routes Which router is hitting the hold time? [Jimmy] Both sides Did the same machine work with your old routing daemon against the same ASR before switching to bird? [Jimmy] Yes, old machine running openbsd and OpenBGPd as routing daemon. New server is running centos and BIRD as routing daemon Did you do any other changes to it while switching to bird? [Jimmy] No

Can you dump the tcp bgp session on the centos? What happens after the bgp session establishes? If it doesn't exchange routes and the holdtimer is hit then there should be no tcp traffic. Is the MTU on both sides the same and can the layer 2 support it? Martin

On Wed, Sep 04, 2013 at 11:43:31PM +0800, Jimmy Halim wrote:

Hi guys,

I had problem bringing up 1 IPv6 BGP neighbour after migration from OpenBGPd to BIRD. The session keeps flapping and no routes have been exchanged as well.

The log in BIRD: Sep 5 00:13:38 ixrs2 kernel: MD5 Hash mismatch for (2001:0de8:0005:0000:0000:0000:1234:0001, 56545)->(2001:0de8:0005:0000:0000:0002:1234:0002, 179) ... Have you guys encountered the same issue before? I have confirmed that the MD5 password is matching. The same neighbour has BGP session to my other BIRD server and the session is running fine! The next step from my side probably is to remove the MD5 password on my end and on other end.

Hello BIRD is running on Linux or on BSD? The second working session also uses MD5 password? The other BIRD server uses the same kind of hardware (esp. the network card)? We heard about such kind of problems with MD5 checksums, but as it is handled almost completely by OS kernel, i would guess that the problem is there (probably in some network card IP offloading or in some firewall rules). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

On Thu, Sep 05, 2013 at 05:41:00PM +0800, Jimmy Halim wrote:

Hi Santiago,

BIRD running on Centos. The 2nd working session also use the same MD5 password and same hardware. The funny part is we have just fixed the issue by removing the MD5 password. We then tried a different MD5 password but the session flaps again.

The funny part, when the BGP is established during the flap, I don't get any routes from the neighbour. But the neighbour claims that they received all prefixes that are advertised by us. Is there any other aspect that might cause this?

I guess that initial packets that established session worked, then BIRD side ignored next received packets. It sent its prefixes and either TCP-ACK packets were not ignored, or the number of exported prefixes were small enough that it does not matter. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."