MULTICASTING AUTO RP AND GRE

MULTICASTING AUTORP AND GRE

• Cisco Propetiary Technique of learning RP dynamically
• Dynamic RP are preffered over statis
• You have 2 components Candidate RP_Device willing to be RP sends advertisement to mapping agent via 224.0.1.39
• Mapping Agent advertises to all routers via 224.0.1.40
• There is a problem with this in order to join and listen on 224.0.1.40 group the hosts need to know where the rp address is it but they obviously can not learn the rp address with joining to 224.0.1.40 group
• To get around this problem we run the groups 224.0.1.39 and 224.0.1.40 in dense mode then the rest of the groups can run in sparse mode once they learn the rp via auto rp. 
• To have the 2 groups in dense mode is known as the AutoRP listener feature  
• There can be issue with Auto RP in NBMA Partial mesh scenerios in that RPF will block advertisement of the RP from interface it recieved on this is covered in the Lab along with a solution with GRE

LAB

For the LAB we will configure AUTORP listner feature and we look at an issue with NBMA multipoint interfaces
so i have enabled the following on all routers/switches
ip multicast-routing
ip pim autorp-listener- this enables the autorp listner feature allowing the 224.0.1.39 and 224.0.1.40 to be sent in dense mode
OK for this lab we will set r2 to be the rp candidate and the mapping agent

r2
---
r2(config)#ip pim send-rp-announce lo0 scope 255
Must first configure PIM mode on the interface: Loopback0
r2(config)#

if you notice straight away it says pim must be enabled on the loopback for the rp the loopback that your referencing must be enabled for pim

r2(config)#int lo0
r2(config-if)#ip pim sparse
r2(config-if)#exi
*Mar  1 07:04:00.883: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Loopback0t
r2(config)#ip pim send-rp-announce lo0 scope 255
r2(config)#
OK that is enabled r2 as candidate for rp with interface lo0  the scope is referening a time to live so i have set to 255. So this enables the 224.0.1.39

r2(config)#ip pim send-rp-discovery lo0 scope 255 interval 5
r2(config)#
this enables the mapping agent on r2 they do not need to be the same router but can be

so the candidate needs to be able to communicate to the mapping agent via the multicast address 224.0.1.39 while the mapping agent needs to be able to communicate to all routers via the address 224.0.1.40
Lets see have all the routers got the rp

r5
---
r5#sh ip pim rp mapping
*Feb 12 13:55:00.123: %SYS-5-CONFIG_I: Configured from console by console
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
  RP 2.2.2.2 (?), v2v1
    Info source: 2.2.2.2 (?), elected via Auto-RP
         Uptime: 00:04:50, expires: 00:00:15
r5#
has it
r1
---

r1#sh ip pim rp map
PIM Group-to-RP Mappings
r1#
r1 does not

r4
---
r4#sh ip pim rp map
PIM Group-to-RP Mappings
r4#
does not

s2
---
s2#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
  RP 2.2.2.2 (?), v2v1
    Info source: 2.2.2.2 (?), elected via Auto-RP
         Uptime: 00:15:28, expires: 00:00:12
s2#

does

so we have situation where some of the routers are getting it and some are not

If we look at the topology we have a issue where r5 is going to recieve the rp mapping advertisement on s0/0
but then can not readvertise it back out the same interface as of the split horizon rule
There is a few ways we could fix this issue we could change r5 to use point to point interfaces of the frame-relay so it would be coming in s0/0.2 and going out s0/0.1 to r1 and s0/0.4 to r4 etc this would work
we could move the mapping agent onto r5 so r5 would be sending out the advertisement directly not it coming in s0/0 and then trying to go back out or we could look at gre tunnel between
r2 and r5 so the traffic is coming the tunnel and then been advertised out the s0/0 which would be fine

We look at the gre tunnel for this example so we need to create a tunnel between r2 and r5

r2
---
r2(config-if)#int tunnel0
r2(config-if)#tunnel source 155.0.0.2
r2(config-if)#tunnel destination 155.0.0.5
r2(config-if)#
*Mar  1 07:32:29.703: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
r2(config-if)#ip address 26.0.0.2 255.255.255.0
r2(config-if)#ip pim sparse

r5
--- 

r5(config)#int tunnel0
r5(config-if)#
*Feb 12 14:19:57.579: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
r5(config-if)#tunnel source s0/0/0
r5(config-if)#tunnel destination 155.0.0.2
r5(config-if)#
*Feb 12 14:20:25.531: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
r5(config-if)#ip address 26.0.0.5 255.255.255.0
r5(config-if)#ip pim sparse
r5(config-if)#

we have pim neighbor relationship across the tunnel
r5#sh 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
155.0.0.2         Serial0/0/0              01:01:45/00:01:33 v2    1 / S
155.0.0.1         Serial0/0/0              01:01:45/00:01:32 v2    1 / S
155.0.58.2        FastEthernet0/0          00:59:48/00:01:34 v2    1 / S
26.0.0.2          Tunnel0                  00:00:36/00:01:38 v2    1 / S
r5#

ok we will see has this fixed the issue

r1
---
r1#sh ip pim rp map
PIM Group-to-RP Mappings
r1#

still on r1 no mapping

r5
---
we will do a debug on r5
 r5#debug ip pim
PIM debugging is on
r5(config)#int tunnel 0
.r5(config-if)#no ip mroute-cac
r5(config-if)#
*Feb 12 14:26:57.867: PIM(0): Send v2 Assert on Tunnel0 for 224.0.1.40, source 2.2.2.2, metric [90/2297856]
*Feb 12 14:26:57.867: PIM(0): Assert metric to source 2.2.2.2 is [90/2297856]
*Feb 12 14:26:57.867: PIM(0): We win, our metric [90/2297856]
*Feb 12 14:26:57.867: PIM(0): Prune Tunnel0/224.0.1.40 from (2.2.2.2/32, 224.0.1.40)
*Feb 12 14:26:57.867: PIM(0): Pruning immediately Tunnel0 (p2p)
*Feb 12 14:26:57.903: PIM(0): Received v2 Assert on Tunnel0 from 26.0.0.2
*Feb 12 14:26:57.903: PIM(0): Assert metric to source 2.2.2.2 is [0/0]
*Feb 12 14:26:57.903: PIM(0): We lose, our metric [90/2297856]
*Feb 12 14:26:57.867: PIM(0): Pruning immediately Tunnel0 (p2p)
*Feb 12 14:26:57.903: PIM(0): Received v2 Assert on Tunnel0 from 26.0.0.2
*Feb 12 14:26:57.903: PIM(0): Assert metric to source 2.2.2.2 is [0/0]
*Feb 12 14:26:57.903: PIM(0): We lose, our metric [90/2297856]
*Feb 12 14:26:57.903: PIM(0): (2.2.2.2/32, 224.0.1.40) oif Tunnel0 in Prune state
*Feb 12 14:26:58.851: PIM(0): Received v2 Assert on Tunnel0 from 26.0.0.2
*Feb 12 14:26:58.851: PIM(0): Assert metric to source 2.2.2.2 is [0/0]
*Feb 12 14:26:58.851: PIM(0): We lose, our metric [90/2297856]
*Feb 12 14:26:58.851: PIM(0): (2.2.2.2/32, 224.0.1.40) oif Tunnel0 in Prune state

basically what is happing is that for the loopback address 2.2.2.2 the rp candidate our rpf to 2.2.2.2 is not via the tunnel in igp so the rpf interface is not via tunnel it is via s0/0/0 so it is not valid for us to recieve the advertisment on the tunnel

 we need to override this rpf for 2.2.2.2 in order to get the tunnel working 
we can do this with a
r5(config)#ip mroute 2.2.2.2 255.255.255.255 tunnel0

r1
---
r1#sh ip pim rp ma
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
  RP 2.2.2.2 (?), v2v1
    Info source: 2.2.2.2 (?), elected via Auto-RP
         Uptime: 00:00:55, expires: 00:00:15
r1#

is now recieving it