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