3.2.b Implement and troubleshoot IPv4 protocol independent multicast

and 1.1b cef…

ccieordie_pim

note the below output:

r1#sh ip route 192.168.46.6
Routing entry for 192.168.46.0/24
Known via “ospf 1”, distance 110, metric 3, type intra area
Last update from 192.168.13.3 on FastEthernet1/0, 00:52:16 ago
Routing Descriptor Blocks:
192.168.13.3, from 6.6.6.6, 00:52:16 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1
* 192.168.12.2, from 6.6.6.6, 00:52:16 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1

http://ccieordie.com/?p=365

There is also an asterisk (*) next to one of the block entries. This corresponds to the active route that is used for new traffic.

i wouldn’t be so sure about this… ospf can load balance across equal paths, although it actually relies on cef to achieve this…

the trace from r5 to r6 is always preferring the route through r3…

this is where this command becomes useful to get the true picture of what cef is doing:

r1#sh ip cef exact-route 192.168.12.1 192.168.46.6
192.168.12.1    -> 192.168.46.6   : FastEthernet0/0 (next hop 192.168.12.2)
r1#sh ip cef exact-route 192.168.13.1 192.168.46.6
192.168.13.1    -> 192.168.46.6   : FastEthernet0/0 (next hop 192.168.12.2)
r1#sh ip cef exact-route 192.168.15.1 192.168.46.6
192.168.15.1    -> 192.168.46.6   : FastEthernet1/0 (next hop 192.168.13.3)

if pim is disabled on r3 (either interface) the rpf will fail…

unicast routing is still fine:

R5#trace 192.168.46.6

Type escape sequence to abort.
Tracing the route to 192.168.46.6

1 192.168.15.1 16 msec 20 msec 12 msec
2 192.168.13.3 28 msec 36 msec 28 msec
3 192.168.34.4 52 msec 44 msec 52 msec
4 192.168.46.6 60 msec 48 msec 72 msec

R5#mtrace 192.168.15.5 192.168.46.6 224.1.1.1
Type escape sequence to abort.
Mtrace from 192.168.15.5 to 192.168.46.6 via group 224.1.1.1
From source (?) to destination (?)
Querying full reverse path…
0  192.168.46.6
-1  192.168.24.4 PIM  [192.168.15.0/24]
-2  192.168.34.3 None Multicast disabled [192.168.15.0/24]

that’s fairly obvious… but sh ip rpf isn’t being truthful:

r1#sh ip rpf 192.168.46.6
RPF information for ? (192.168.46.6)
RPF interface: FastEthernet1/0
RPF neighbor: ? (192.168.13.3)
RPF route/mask: 192.168.46.0/24
RPF type: unicast (ospf 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables

turning pim back on r3 int f1/0:

R5#mtrace 192.168.46.6
Type escape sequence to abort.
Mtrace from 192.168.46.6 to 192.168.15.5 via RPF
From source (?) to destination (?)
Querying full reverse path…
0  192.168.15.5
-1  192.168.15.5 PIM  [192.168.46.0/24]
-2  192.168.15.1 PIM  [192.168.46.0/24]
-3  192.168.13.3 PIM  [192.168.46.0/24]
-4  192.168.34.4 PIM  [192.168.46.0/24]
-5  192.168.46.6