From my last post here:http://mellowd.co.uk/ccie/?p=3205 – I was pretty sure I had autorp listener covered. However there is always something more to trip you up, and hence something more to learn.
I was labbing away on a very simple topology:
R1 and R3 have PVCs to R2 only. They do not connect directly to each other. R1 and R3 have slightly different configurations as well just to mix things up:
interface Loopback0 ip address 22.214.171.124 255.255.255.255 ip pim sparse-mode ip ospf 1 area 0 ! interface Serial0/0 ip address 10.0.123.1 255.255.255.0 ip pim sparse-mode encapsulation frame-relay ip ospf network point-to-multipoint ip ospf priority 0 ip ospf 1 area 0 frame-relay map ip 10.0.123.3 102 frame-relay map ip 10.0.123.2 102 broadcast no frame-relay inverse-arp
interface Loopback0 ip address 126.96.36.199 255.255.255.255 ip pim sparse-mode ip ospf 1 area 0 ! interface Serial0/0 ip address 10.0.123.2 255.255.255.0 ip pim nbma-mode ip pim sparse-mode encapsulation frame-relay ip ospf network point-to-multipoint ip ospf 1 area 0 frame-relay map ip 10.0.123.1 201 broadcast frame-relay map ip 10.0.123.3 203 broadcast no frame-relay inverse-arp
interface Loopback0 ip address 188.8.131.52 255.255.255.255 ip pim sparse-mode ip igmp join-group 184.108.40.206 ip ospf 1 area 0 ! interface Serial0/0 no ip address encapsulation frame-relay no frame-relay inverse-arp ! interface Serial0/0.123 point-to-point ip address 10.0.123.3 255.255.255.0 ip pim sparse-mode ip ospf network point-to-multipoint ip ospf priority 0 ip ospf 1 area 0 frame-relay interface-dlci 302
R3 has joined the 220.127.116.11 group for later testing.
I would like to use auto-rp to map groups to the RP which I want to be R1. R2 is the only router connected to both routers directly and both of those links are over the same interface.
The routers will not allow you to you have IIL (Incoming Interface List) to match your OIL (Outgoing Interface List) by default as this will cause loops. This is a split-horizon issue also seen with EIGRP and RIP. ip pim nbma-mode allows us to override this default behavior and have the IIL and OIL match. So R2 should be able to receive auto-rp messages on s0/0 from R1, and send those message out to R3 on s0/0 again.
I initially configured R1 to be both the RP and the MA. I configured ip pim autorp listener only on R2 so that it can forward traffic destined to 18.104.22.168 back out s0/0 to R3. However this doesn’t work. Why not?
First, let’s check what R2 sees as the RP. Is it receiving autorp messages from R1?
R2#sh ip pim autorp AutoRP Information: AutoRP is enabled. AutoRP groups over sparse mode interface is enabled PIM AutoRP Statistics: Sent/Received RP Announce: 0/0, RP Discovery: 0/41 R2# R2# R2#sh ip pim rp map PIM Group-to-RP Mappings Group(s) 22.214.171.124/4 RP 126.96.36.199 (?), v2v1 Info source: 188.8.131.52 (?), elected via Auto-RP Uptime: 00:03:20, expires: 00:00:12
R2 is definitely receiving Discovery messages from the MA and so it knows that R1 is the RP. the mroute tables shows that this router is NOT sending this information from 184.108.40.206 back out to R3 as the OIL doesn’t have s0/0 in it.
R2#sh ip mroute 220.127.116.11 | beg \(1 (18.104.22.168, 22.214.171.124), 00:08:43/00:02:54, flags: LT Incoming interface: Serial0/0, RPF nbr 10.0.123.1 Outgoing interface list: Loopback0, Forward/Sparse, 00:08:43/00:00:00
R3 therefore knows nothing about this RP:
R3#sh ip pim autorp AutoRP Information: AutoRP is enabled. PIM AutoRP Statistics: Sent/Received RP Announce: 0/0, RP Discovery: 0/0 R3#sh ip pim rp map PIM Group-to-RP Mappings
So why exactly is this happening? In theory R2 should be receiving that group and dense-mode flooding it back out s0/0 off to R3. But this is not happening. A little digging however and I come across this gem over here: http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/frm_rlay.html#wp1029926 The important bit is that it’s saying that the hub router (R2 in my case) will NOT forward MA group traffic if the initial MA packet came into the same interface as we want it to go back out again. Basically because R2 has received an MA announcement from R1 over s0/0, it will NOT send that packet back out s0/0 to R3. Regardless of whether ip pim nbma-mode and ip pim autorp listener is configured.
As long as the MA announcement comes into a different interface, then it’ll go out to R3. We can simulate this by simply making R2 the MA:
R2(config)#ip pim send-rp-discovery lo0 scope 10 interval 5
R3 now receives that information and has the correct RP mappings:
R3#sh ip pim autorp AutoRP Information: AutoRP is enabled. PIM AutoRP Statistics: Sent/Received RP Announce: 0/0, RP Discovery: 0/7 R3#sh ip pim rp map PIM Group-to-RP Mappings Group(s) 126.96.36.199/4 RP 188.8.131.52 (?), v2v1 Info source: 184.108.40.206 (?), elected via Auto-RP Uptime: 00:00:39, expires: 00:00:14
And as a final test, R1 is now able to ping the group joined by R3’s lo0 interface:
R1#ping 220.127.116.11 repeat 5 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 18.104.22.168, timeout is 2 seconds: Packet sent with a source address of 22.214.171.124 Reply to request 0 from 10.0.123.3, 4 ms Reply to request 0 from 10.0.123.3, 40 ms Reply to request 1 from 10.0.123.3, 20 ms Reply to request 1 from 10.0.123.3, 20 ms Reply to request 2 from 10.0.123.3, 12 ms Reply to request 2 from 10.0.123.3, 40 ms Reply to request 3 from 10.0.123.3, 16 ms Reply to request 3 from 10.0.123.3, 24 ms Reply to request 4 from 10.0.123.3, 1 ms Reply to request 4 from 10.0.123.3, 24 ms
This is probably only something you’re likely to come across in a lab exam. In the real world I would be using multiple subinterfaces on R2 which would be considered separate L3 interfaces. And that’s a big IF I was using frame-relay anyway