Multicast over NBMA with auto-rp and a spoke mapping agent

Here is the topology. There is no PVC between R2 and R3. Nice frame cloud, eh?


R1 (hub), R2 and R3 are connected via frame-relay: 172.12.123.0/24.
R4 connects to R3 via another serial connection: 192.168.14.0/24.

OSPF area 0 is everywhere.

R1 will be the RP-candidate.
R3 will be the mapping agent.
R2 will be joining group 232.0.0.2.
R4 will sending pings to 232.0.0.2.

R1 will announce itself as RP candidate and R3 as the MA:

R1(config)#ip pim send-rp-announce lo 0 scope 5

R3(config)#ip pim send-rp-discovery loopback 0 scope 5

Now according to this doc:

Using IP Multicast Over Frame Relay Networks

"All candidate RPs must be connected to the MA"
AND
"All MAs must be connected to all PIM routers"

In order for R2 to successfully receive the rp-to-group mappings from R3, they need to be PIM neighbors. The reason is R1 will not forward an autorp message received on it's frame-relay interface back out that same interface. So R2 will never get it!

We can create a tunnel between the two and enabling sparse-mode on the tunnel:

R2(config)#int tun 0
R2(config-if)#ip address 172.12.23.2 255.255.255.0
R2(config-if)#tunnel source 172.12.123.2
R2(config-if)#tunnel destination 172.12.123.3
R2(config-if)#ip pim sparse-mode

R3(config)#int tun 0
R3(config-if)#ip address 172.12.23.3 255.255.255.0
R3(config-if)#tunnel source 172.12.123.3
R3(config-if)#tunnel destination 172.12.123.2
R3(config-if)#ip pim sparse-mode

Now R2 and R3 are PIM neighbors:

R2#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
172.12.123.1 Serial1/0 01:44:07/00:01:38 v2 1 / S
172.12.13.3 Tunnel0 00:06:29/00:01:42 v2 1 / S

However theres is still one issue. When R2 receives the auto-rp messages from R3 the rpf check fails because R2 uses its FR interface to perform the rpf check:

R2#show ip rpf 3.3.3.3
RPF information for ? (3.3.3.3)
RPF interface: Serial1/0
RPF neighbor: ? (172.12.123.1)
RPF route/mask: 3.3.3.3/32
RPF type: unicast (ospf 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables

Thus R2 will never learn the rp-to-group mapping. We can fix this by making a static mroute for R3's loopback pointing towards the tunnel:
R2(config)#ip mroute 3.3.3.3 255.255.255.255 Tunnel0


Now the RPF will pass for auto-rp messages:

R2#show ip rpf 3.3.3.3
RPF information for ? (3.3.3.3)
RPF interface: Tunnel0
RPF neighbor: ? (172.12.23.3)
RPF route/mask: 3.3.3.3/32
RPF type: static
RPF recursion count: 0
Doing distance-preferred lookups across tables

Let's verify on R4:

R4#ping 232.0.0.2 repeat 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 232.0.0.2, timeout is 2 seconds:

Reply to request 0 from 172.12.123.2, 500 ms
Reply to request 1 from 172.12.123.2, 188 ms
Reply to request 2 from 172.12.123.2, 492 ms
Reply to request 3 from 172.12.123.2, 300 ms
Reply to request 4 from 172.12.123.2, 292 ms

Sweet!

Configuring multipoint subinterface so the interface status reflects status of the PVC

On a physical frame-relay interface, if the opposite end goes down, the local interface will remain up/up. When using multipoint subinterfaces this is not the case. When the remote interface goes down (taking the dlci with it), the local ends puts its interface in a down/down state.

R1, R3 and R5 connect via full mesh frame-relay, subnet 190.1.135.0/24

R1 dlci 103 maps to R3 dlci 301
R1 dlci 105 maps to R5 dlci 501
R3 dlci 305 maps to R5 dlci 503

Configure all routers on the physical interfaces.

Here is the outlook so far from R3:

R3#show ip int brief serial 1/0
Interface IP-Address OK? Method Status Protocol
Serial1/0 190.1.135.1 YES manual up up
R3#

Now Let's shut the physical interfaces On R5 and R1:

R5(config)#int s0/0
R5(config-if)#shut

R1(config)#int s0/0
R1(config-if)#shut

R3 still has its interface up/up:

R3#show ip int brief serial 1/0
Interface IP-Address OK? Method Status Protocol
Serial1/0 190.1.135.1 YES manual up up

If we want R3's interface to go down when R5 and R1 are no longer available we need to use multipoint subinterface. Let's create one on R3 and move the config over:

R3(config)#interface Serial1/0
R3(config-if)# no ip address 190.1.135.1 255.255.255.0
R3(config-if)# no frame-relay map ip 190.1.135.1 301
R3(config-if)# no frame-relay map ip 190.1.135.5 305
R3(config-if)#int s1/0.3 multipoint
R3(config-subif)# ip address 190.1.135.1 255.255.255.0
R3(config-subif)# frame-relay map ip 190.1.135.1 301 broadcast
R3(config-subif)# frame-relay map ip 190.1.135.5 305 broadcast
R3(config-subif)# no frame-relay inverse-arp

Bring up R5 and R1 again and now we have:

R3#show ip int brief s1/0.3
Interface IP-Address OK? Method Status Protocol
Serial1/0.3 190.1.135.1 YES manual up up

Shut down R5 and R3 is stil up but look at the debug frame-relay lmi. The status of PVC 305 is 0x0 which is inactive

R3#show ip int brief s1/0.3
Interface IP-Address OK? Method Status Protocol
Serial1/0.3 190.1.135.1 YES manual up up

*Mar 1 08:27:43.170: Serial1/0(in): Status, myseq 115, pak size 45
*Mar 1 08:27:43.170: RT IE 1, length 1, type 0
*Mar 1 08:27:43.170: KA IE 3, length 2, yourseq 115, myseq 115
*Mar 1 08:27:43.170: PVC IE 0x7 , length 0x6 , dlci 301, status 0x2 , bw 0
*Mar 1 08:27:43.170: PVC IE 0x7 , length 0x6 , dlci 302, status 0x0 , bw 0
*Mar 1 08:27:43.170: PVC IE 0x7 , length 0x6 , dlci 304, status 0x2 , bw 0
*Mar 1 08:27:43.170: PVC IE 0x7 , length 0x6 , dlci 305, status 0x0 , bw 0

Now let's shut down R1 and take a look at R3 again, notice pvc 301 is now status 0x0. and the interface is down/down on R3

*Mar 1 08:30:03.170: Serial1/0(in): Status, myseq 129, pak size 45
*Mar 1 08:30:03.170: RT IE 1, length 1, type 0
*Mar 1 08:30:03.170: KA IE 3, length 2, yourseq 129, myseq 129
*Mar 1 08:30:03.170: PVC IE 0x7 , length 0x6 , dlci 301, status 0x0 , bw 0
*Mar 1 08:30:03.170: PVC IE 0x7 , length 0x6 , dlci 302, status 0x0 , bw 0
*Mar 1 08:30:03.170: PVC IE 0x7 , length 0x6 , dlci 304, status 0x2 , bw 0
*Mar 1 08:30:03.174: PVC IE 0x7 , length 0x6 , dlci 305, status 0x0 , bw 0

R3#show ip int brief s1/0.3
Interface IP-Address OK? Method Status Protocol
Serial1/0.3 190.1.135.1 YES manual down down

Route Redistribution Issues Part I – RIP and OSPF

This is part of task I had on IEWB volume 3 workbook lab 1. I tweaked it a little. I wanted to get better idea of redistribution when there are multiple points of redistribution. It is always the hardest concept for me to get my head around because there so many things going on. I know the tasks may only be a few points, but it affects reachability which can hurt you later if you do not have it.

If you develop a thought process for it and recognize patterns and spot issues beforehand, you will be better off. I don't have any configurations here, just my thought flow. I was doing this practice lab at the same but I just wanted to document the thoughts.


Perform redistribution between RIP and OSPF on R4 and R5 and ensure reachability to the loopback interfaces on R1 and R9 from anywhere when R4 or R5’s frame link are down. If both are down then reachability to R9 and R1 cannot be achieved from R2.

Thought Process:

First thing I would do is identify which networks need to be learned via each protocol on each router, along with back up routes:

Router	Destination	Primary Route	Backup Route
R1	R9, LAN59	RIP via R4	n/a
R4	R9, LAN59 R1	RIP via R5 RIP via R1	OSPF via R5 n/a
R5	R1, LAN14 R9	RIP via R4 RIP via R9	OSPF via R4 n/a
R9	R1, LAN14	RIP via R5	n/a
R2	All	OSPF via R4 or R5	n/a

Next thing is to break down the redistribution into steps. These steps can be in various orders which may affect traffic flow, but I like to start with the edge networks in and resolve issues as we progress. We have 4 steps here:

Step 1: Redistribute RIP into OSPF on R5
R2 now has access to R9 loopback and LAN59 via R5
R5 has no changes to it’s routes
R4 now learns the route to R9 and LAN59 via OSPF through R5
R1 no longer has a route to R9 or LAN59 because R4 learns these via OSPF, not RIP anymore

Step 2: Redistribute RIP into OSPF on R4
R2 now has access to R1 loopback and LAN14 via R4.
R4 is the same as in step 1.
R5 now learns the route to R1 Loopback and LAN14 via OSPF through R4
R9 cannot reach R1 anymore because R5 is learning R1 and LAN14 through OSPF, not RIP

Issues remaining after steps 1 and 2:
R1 or R9 cannot respond to pings from R2 because they do not have a route for the OSPF network.
R1 and R9 cannot reach each other’s loopbacks or connected LANs.

Step 3: Redistribute OSPF into RIP on R4
Here is we encounter a loop. The reason is that once R4 does this it will now advertise RIP routes back to R1 and R5 that may have already been in RIP to begin with. So the problems will be with any existing RIP routes on these routers. R5 currently has a RIP route for R9 loopback with a metric of 1. R4 is going to redistribute this route back to R5 also with a mteric of 1 (the metric is up to use, but I use 1 for example). R5 now will load share between two routes to R9. One router will be a loop (the one through R4). R5 has no way of knowing that this route is the same route it redistributed into OSPF. We can resolve this by setting a higher metric on the routes that R4 redistributes into RIP. Setting the metric to 2 in this example resolves the issue.

R2 now has reachability to R1 and LAN14, but still no reachability to R9 because R9 has no route back. R9 also has no route to R1.

Step 4: Redistribute OSPF into RIP on R5
In the final step of redistribution R5, we may cause another loop by advertising R1’s loopback back to R4 over the serial link with a metric 1. However, we set the metric to 2 to rpevent this.

Shutting down serial link between R4 and R5:
Because this link is not used for any transit networks, this link does not affect reachability to R1 or R9 whether up or down.

Shutting down only R5 frame-relay interface:
R5 loses its OSPF networks and learns all routes via RIP through R4. R4 uses the RIP link to reach R9 and LAN59.

Shutting down only R4 frame-relay interface:
R4 loses it OSPF networks and learns all routes via RIP through R5. LAN14 and R1 are still learned directly from R1.