28 July 2014

Still Going

So I haven't posted anything lately I know.  I have had to take a couple weeks off of studying for personal and work events.  I moved 900 miles from my old location to a new one.  Had to knock out one Aruba cert and working on another.  Had to reset up my lab and remote access as well.  Lots to work on.  Hoping that by the end of this week I can get it all fleshed out and get back to working on studying.  Guess we will see.

01 July 2014

BGP Part 1

Well with work and my upcoming move, I will post when I can about what I get done.  Some posts may be far and in between but I will be doing what I can.  Also for work I have to study for the Aruba Certified Mobility Associate (ACMA) and pass it as well in the next two weeks.  Well, enough belly-aching.  On to the fun stuff.

Most engineers know about the ebgp-multihop option for the neighbor command in BGP but there is also the disable-connected-check option as well.  What I understand about this option is that it is used when you are peering with a device that is directly connected but you are not using the next-hop interface.  Think about peering with the loopback of the remote device.  The updates are still sent out with a TTL of 1 but the router with the option doesn't worry about it since it can tell that the router is directly connected.  This can be seen if you simulate a failure and the packets are routed over a third router.  The third router drops the updates since the TTL is 1.  Can be usA ned when you want to peer with a router's loopback but want to make sure that the device is only peering over a direct connection.

When using route-reflectors, clusters are formed, but what is a cluster?  A cluster is the router reflector and its clients.  A nice way to talk about 2 to the n number of routers.

Route reflectors have the following rules when it comes to sending updates:
  • routes learned form eBGP can be sent to eBGP peers, reflector clients, and non-clients
  • routes learned from reflector clients can be sent to eBGP peers, other reflector clients, and non-clients
  • routes learned from non-client peers can be sent to eBGP peers and reflector clients
    • they CANNOT be sent to non-clients

BGP confederation AS_CONFED_SET is only seen as one AS.  This means that sometimes the straightest path is not always chosen.  AS_CONFED_SET (65437 65238) can be chosen over AS_CONFED_SET (65186) if the router-id is lower on the advertising router for the longer set.  This can possibly lead to sub-optimal routing.

With synchronization, a route is not eligible to be used or advertised unless it is known by the IGP and in the routing table.  That means that for external routes, you have to redistribute the routes from the eBGP borders to the IGP routers.  Without doing that, BGP cannot use the route.  Well, there is another option and that would be to create static routes on the router and that will add the route to the routing table but would you really want to do that?


RIB-failures in BGP are when there is a path that can be used via Best-Path Selection but cannot be installed in the routing table because there is a static or IGP route with a lower administrative distance.  By default, these routes can still be advertised to other neighbors.  If the command bgp suppress-inactive is used then RIB-failure routes are not advertised.

When redistributing from BGP to an IGP, by default only eBGP routes are redistributed.  To redistribute iBGP routes, you have to use the bgp redistribute-internal command.  This can cause routing loops so the administrative distances may need to be adjusted on some router's IGPs to combat this.