Obviously the same destination means longest match can not be used. Also note the use of "if" in his sentence, which indicates a caveat/condition is coming next.
"Administrative distance is the first criterion that a router uses to determine which routing protocol to use if two protocols provide route information for the same destination."
This is both technically and grammatically correct.
... View more
'show ip ospf rib' will give you the information you want. Note that '>" indicates whether this route will be installed in the routing table. Not having '>' may be an indication the router has a path to the prefix via another routing protocol with a lower AD . In the case illustrated below (220.127.116.11/24) redistributed routes from EIGRP into OSPF have had the AD altered to be 175 (from 110). Unlike EIGRP, OSPF does not change the AD of redistributed routes by default, but rather leaves those at 110. EIGRP will set them at 170 and internal routes will be at 90.
R22#sh ip ospf rib
OSPF Router with ID (18.104.22.168) (Process ID 1)
Base Topology (MTID 0)
OSPF local RIB Codes: * - Best, > - Installed in global RIB
*> 22.214.171.124/24, Ext2, cost 20, tag 0 via 126.96.36.199, Ethernet0/0 *> 188.8.131.52/24, Ext2, cost 20, tag 0 via 184.108.40.206, Ethernet0/0 * 220.127.116.11/24, Ext2, cost 20, tag 0 via 18.104.22.168, Ethernet0/0 * 22.214.171.124/24, Intra, cost 10, area 0, Connected via 126.96.36.199, Ethernet0/0 *> 188.8.131.52/24, Intra, cost 20, area 0 via 184.108.40.206, Ethernet0/0 * 220.127.116.11/24, Ext2, cost 20, tag 0 via 18.104.22.168, Ethernet0/0
Routing entry for 22.214.171.124/24 Known via "eigrp 1", distance 170, metric 409600, type external Redistributing via ospf 1, eigrp 1 Advertised by ospf 1 subnets Last update from 126.96.36.199 on Ethernet0/1, 00:16:05 ago Routing Descriptor Blocks: * 188.8.131.52, from 184.108.40.206, 00:16:05 ago, via Ethernet0/1 Route metric is 409600, traffic share count is 1 Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
Hope this helps
... View more
Your best in this case is to remove the nail down route via null 0, the reason is that with the null 0 approach you may end up null routing traffic if your R1-R2 link fails AND your fa2/0 is also down while your BGP upstream link is active. In my opinion it would be better to put the prefix into BGP using the bare network command with the static route via fa2/0. if f2/0 goes down the iBGP route from the R1 will prevent the prefix from flapping and a double hop will occur for any traffic landing on the router with the failed f2/0 interface, that's all. Because the way you are originating the prefix into BGP is impossible to have the router pick the iBGP peer as the best path the null0 interface always win. The best you can end up with is a half working solution after manipulating weight and/or local preference. If you do this you will always end up on one side with a rib-failure that never advertises the path via r1-r2 to the other iBGP peer (rib-failed prefixes are advertised only when they contain a best-path matching the next hop installed for that prefix in the RIB) Finally make sure you track an upstream route to avoid having an active VRRP peer attracting outbound traffic that has nowhere to go (i.e R1-R2 and upstream down but f2/0 up )
... View more