bgp router-id command

Netwurk

Ran into a problem with my lab where I accidentally gave 2 of my routers the same loopback address (which BGP usually uses as the router-id).

Error was

%BGP-3-NOTIFICATION: received from neighbor 10.0.0.8 (BGP identifier wrong)

So I gave the problem router a unique IP but still got the same errors as you need to reset BGP in some way to get it to advertise a new router-id.

Lots of ways to do this although I did find that the clear ip bgp commands don't help with this (as far as I can tell).

I didn't want to reload or tear down BGP and start over (too easy).

So what I finally decided on was to enter BGP config and use the bgp router-id to explicitly tell BGP to use the new ID. That worked.

I noticed that a possible drawback was that the router-id was now in the start config and so I issued the command no bgp router-id to get rid of the explicit instructions. Worked perfectly and BGP did not even need to restart.

Hope this helps someone although maybe this is beyond the scope of the exam?

vinbuck

This is a perfect exercise to illustrate why router ids should be assigned under the routing protocol and not through the default highest ip method. BGP is actually a very robust protocol in terms of being able to modify it without disrupting everything.

This is why I like getting my hands dirty in the lab because you never know where it's going to lead. I was working on labs for SWITCH today and discovered that if you don't shut down your ports while trying to put them into an etherchannel, you can get them into a state known as err-disabled. Had to google that one to figure out how to get everything back to working (you just do a shut/no shut), but I learned a valuable lesson that will be helpful in future troubleshooting.

Good stuff Netwurk...

Netwurk

vinbuck wrote: »

I was working on labs for SWITCH today and discovered that if you don't shut down your ports while trying to put them into an etherchannel, you can get them into a state known as err-disabled.

Even worse, try tearing down an etherchannel without first doing a no shut on the ports. On some switches (like the one I tried it on), it will ignore the spanning tree rules and create a switch crippling endless loop. Cool that I learned these things in my lab as it prevents me from doing things like that at work.