OSPF Distance command

The OSPF distance command can be used in a number of different ways.   I found the first one is well documented on the doc cd in the ospf routing section. However  the next three are strangely absent therein.  There is some info under the general distance command but this does not detail its use in OSPF.

I) distance ospf {external/inter-area/intra-area} AD

II) distance AD - this sets the distance for all routes

III) distance AD {ip-address wild-card-mask} - this sets the distance for all routes learned from a specific source-router. The source router is the RID of the link-state router that origininated the route!!!

IV) distance AD (ip-address wild-card0mask} ACL  identical to the previous command but it is applied to only a subset of routes that match the ACL.

IPV6 Multicast

IPv6 multicast rears its head on V4 of the CCIE blueprint.  If you know the basics of IPv4 multicast then the basics of IPv6 multicast should be pretty straightforward.   In fact with IPv6 its not even  necessary to define interfaces as multicast capable! Once ipv6 multicast routing is enabled on the router the interfaces become multicast enabled as well.

Here is a config example between just 2 routers connected via an ethernet interface: R1---R2. The basic steps are
i) enable ipv6 multicast routing
ii) define the rp
iii) join an interface with a multicast group

R1

Ipv6 multicast-routing

ipv6 pim rp-address 2002::2

R2

Ipv6 multicast-routing

Int lo0

   ipv6 mld join-group FF04::2

ipv6 pim rp-address 2002::2

With the above configuration an IPV6 PIM neighbourship forms between R1 and R2

The show ipv6 pim group-map command can be used to see a that a multicast address is associated with the RP.

Finally i test the multicast group with a ping

BGP adjacency problem

In this post i detail a recent problem encountered with a flapping BGP adjacency and a number of ways to resolve.

R1 has a BGP adjacency with R2. However this is continually flapping (see below).

The routers are peering using Loopback 0s that are reachable via OSPF.     The issue arises because as the BGP peering comes up the Loopback prefixes are advertised over the BGP adjacency.  OSPF AD is 110 whereas the eBGP route AD is 20. Hence the Loopback routes becomes preferred over the BGP adjacency. This is a type of recursive loop and not allowed (Just as learning the destination of the tunnel over the tunnel itself).     The adjacency is dropped and the whole process starts again.

I have detailed three solutions to the problem here

1) Block the Loopback prefixes from being received

On R2

ip prefix-list ric seq 5 deny 1.1.1.1/32
ip prefix-list ric seq 10 permit 0.0.0.0/0 le 32

router bgp 2
    neighbor 1.1.1.1 prefix-list ric in

2) Modify the distance of OSPF to be preferred over an eBGP route

router ospf 1
distance  ospf intra-area 19

3) Make use of the BGP backdoor command to raise the AD of the BGP route to 200.

router bgp 1
net 2.2.2.2 mask 255.255.255.255 backdoor

Once the command is used the route to 2.2.2.2 shows up in the BGP table as a RIB failure.  Use of the show ip bgp rib command completes the verification.