BGP Default Route

Another great article from Ivan Pepelnjak.

What was particularly interesting to me is the idea to check presence of specific routes in the routing table before advertising default route!

This kind of tracking can also be used to quickly close peering session with a neighboring BGP router. Imagine we have a host route to a BGP peer loopback that is advertised, for example, via OSPF. We can match this route with a prefix-list and then use it in a route-map to create a condition for a BGP session closing. This described in a great detail in Designing Fast Converging BGP Networks.

Frame-relay Inverse-ARP caveats

Hello, long time no see!
Today I have come across a very interesting examples of Inverse-ARP.

1

Suppose we have a "hub and spoke" topology where hub uses multipoint interface with the following configuration:

interface Serial0/0.200 multipoint
  ip address 155.1.200.5 255.255.255.0
  frame-relay interface-dlci 503
  frame-relay interface-dlci 504

 Spokes have the following config under their respective interfaces:

interface Serial1/0
  ip address 155.1.200.3 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 155.1.200.5 305 broadcast

This configuration is working. And the reason lies in the fact that "frame-relay map" command effectively disables Inverse-ARP on the particular DLCI, but it's important to understand that it disables only Inverse-ARP requests but not Inverse-ARP responses!

It means that "spoke" has static map to reach the "hub" that disable Inverse-ARP requests. However, it still replies to the requests coming from the "hub", so the "hub" will have dynamic mappings from Inverse-ARP!

2

Imagine that we have the exact same topology but now "spokes" have static mappings to reach each other, however static mapping to reach the "hub" has been removed.

interface Serial0/0.200 multipoint
  ip address 155.1.200.5 255.255.255.0
  frame-relay interface-dlci 503
  frame-relay interface-dlci 504

Spokes have the following config under their respective interfaces:
Spoke 1

interface Serial1/0
  ip address 155.1.200.3 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 155.1.200.4 305 broadcast

Spoke 2

interface Serial1/0
  ip address 155.1.200.4 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 155.1.200.3 405 broadcast

Since "spokes" use the same DLCI to reach "hub" and other "spokes" Inverse-ARP now can't be used to discover "hub's" IP to Layer-2 mapping. The interesting thing is that this configuration works because "hub" still sends Inverse-ARP requests and even though it's disabled on "spokes", they are still able to add dynamic mappings to reach "hub" (while responding to Inverse-ARP requests, spokes also add dynamic mappings to reach "hub")!




P.S. It wouldn't change anything if I added "no frame-relay inverse-arp" under the "spoke's" serial interfaces.
P.P.S. I hate Frame-Relay :D

Redistribution facts

1. When redistributing something (for example, EIGRP into BGP) with route-maps, changes in access-list that used to match specific routes, do not force new routes to automatically populate BGP table! For this to happen, we have to "no redistribute eigrp X ......" and then re-enter it!

More to come :)

Redistribution of static routes to EIGRP

I have learnt an interesting fact about redistribution into EIGRP process. If you want to redistribute static route as INTERNAL to EIGRP, you should use simple network x.x.x.x command instead of redistribute static. EIGRP treats static routes to interface as a connected networks, so it works pretty well!

eBGP connection issues

eBGP connections differ form iBGP connections in the way router with TTL value inside the IP packet. By default, BGP sends packets with TTL value set to 255 to it's iBGP peers, so if we are connecting to the loopback interface (or other IP addresses that are more than 1 hop away) everything works well out of the box. This is not the case for the eBGP peers. In order to connect to loopback interface of eBGP peer, we have to configure "neighbor x.x.x.x ebgp-multihop 'TTL value'" router command, because by default BGP sends packets with IP TTL set to 1! If you forgot to do this this, "show ip bgp summary" will show the neighbor connection sitting in IDLE state!