If there are no other influences, the Multicast RPF table is populated by the Unicast routing table. In many instances this is fine but in some cases there may be a requirement that the unicast and multicast traffic take different paths. This is example is one of them.
The topology is described below:
R4 is a simple host (multicast client) attached to R5
R5 is dual homed to R6
Link 1 is a FastEthernet connection, where the Service Provider does not allow multicast traffic
Link 2 is a serial connection that would typically be the backup path but we can run multicast on this link
R6 will have our Multicast Source attached to it and therefore is the best device to be the RP since we are going to be using PIM Sparse-Mode
Here is our unicast topology:
R4
hostname R4
interface FastEthernet0/0
description R5 Fa0/1
ip address 192.168.101.4 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.101.5
R5
hostname R5
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface FastEthernet0/0
description R6 Fa0/1
ip address 192.168.56.5 255.255.255.0
ip ospf network point-to-point
!
interface Serial0/0
description R6 S0/0
ip address 192.168.156.5 255.255.255.0
clock rate 2000000
!
interface FastEthernet0/1
description R4 Fa0/0
ip address 192.168.101.5 255.255.255.0
!
router ospf 1
passive-interface FastEthernet0/1
network 5.5.5.5 0.0.0.0 area 0
network 192.168.56.5 0.0.0.0 area 0
network 192.168.101.5 0.0.0.0 area 0
network 192.168.156.5 0.0.0.0 area 0
R6
hostname R6
interface Loopback0
ip address 6.6.6.6 255.255.255.255
!
interface Serial0/0
description R5 S0/0
ip address 192.168.156.6 255.255.255.0
!
interface FastEthernet0/1
description R5 Fa0/0
ip address 192.168.56.6 255.255.255.0
ip ospf network point-to-point
!
router ospf 1
network 6.6.6.6 0.0.0.0 area 0
network 192.168.56.6 0.0.0.0 area 0
network 192.168.67.6 0.0.0.0 area 0
network 192.168.156.6 0.0.0.0 area 0
As we would expect, under normal circumstances, the FastEthernet path will always be preferred simply because it has a much lower metric than the serial link, however recall that we want to run multicast applications even when the FastEthernet Path is active:
Lets start to apply the multicast Configurations to R5 and R6 - we're going to use BSR for the RP selection but the concepts would be the same if we used Auto-RP or Static RP
R5
ip multicast-routing
interface Serial0/0
description R6 s0/0
ip pim sparse-mode
!
interface FastEthernet0/1
description R4 Fa0/0
ip pim sparse-mode
!
R6
ip multicast-routing
interface Loopback0
ip pim sparse-mode
interface Serial0/0
description R5 s0/0
ip pim sparse-mode
!
ip pim bsr-candidate Loopback0
ip pim rp-candidate Loopback0
Lets see if the RP is learnt by R5
R5#sh ip rpf 6.6.6.6
RPF information for ? (6.6.6.6) failed, no route exists
R5#sh ip pim rp
R5#sh ip pim rp mapping
PIM Group-to-RP Mappings
Okay, so we cant see the RP at all, is PIM running?
R5#sh ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
192.168.156.5 Serial0/0 v2/S 1 30 1 0.0.0.0
192.168.101.5 FastEthernet0/1 v2/S 0 30 1 192.168.101.5
Yes, we can see that on S0/0 we have a neighbor - lets check R6
R6#sh ip rpf 6.6.6.6
RPF information for ? (6.6.6.6)
RPF interface: Loopback0
RPF neighbor: ? (6.6.6.6) - directly connected
RPF route/mask: 6.6.6.6/32
RPF type: unicast (connected)
RPF recursion count: 0
Doing distance-preferred lookups across tables
R6#sh ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
6.6.6.6 Loopback0 v2/S 0 30 1 6.6.6.6
192.168.156.6 Serial0/0 v2/S 1 30 1 0.0.0.0
R6#sh ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
BSR address: 6.6.6.6 (?)
Uptime: 00:42:22, BSR Priority: 0, Hash mask length: 0
Next bootstrap message in 00:00:49
Candidate RP: 6.6.6.6(Loopback0)
Holdtime 150 seconds
Advertisement interval 60 seconds
Next advertisement in 00:00:34
R6#sh ip pim rp
R6#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
This system is the Bootstrap Router (v2)
Group(s) 224.0.0.0/4
RP 6.6.6.6 (?), v2
Info source: 6.6.6.6 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:41:41, expires: 00:01:47
Okay, so this looks ok here - lets go back to R5 and see if we can work out what the issue is
R5#deb ip pim bsr
PIM-BSR debugging is on
*Mar 1 01:02:25.199: PIM-BSR(0): bootstrap on non-RPF path Serial0/0
Well thats a good hint as to what the problem is, if we recall the RPF check is determined by default by first checking the multicast RPF table on how to get back to the RP/Source to determine the appropriate input interface we should be listening to.
R5#sh ip route 6.6.6.6
Routing entry for 6.6.6.6/32
Known via "ospf 1", distance 110, metric 11, type intra area
Last update from 192.168.56.6 on FastEthernet0/0, 00:50:54 ago
Routing Descriptor Blocks:
* 192.168.56.6, from 6.6.6.6, 00:50:55 ago, via FastEthernet0/0
Route metric is 11, traffic share count is 1
If nothing is specifically populating this table we will use the unicast routing table as the source - so since Fa0/0 is what is being used for the RPF check, and it isn't running PIM and isn't the link we want, we need to fix this somehow.
Options:
- Change the Routing Metric so that the serial path is the preferred path over the fast ethernet path. Probably not the best option considering we're probably paying top dollar for a 100Meg ethernet connection
- Do something to influence the multicast RPF table so that it is different to the unicast routing table.
Option 1 - Static Mroute
Applying a static mroute statement using the serial interface as the next hop is an easy way to resolve this - it doesn't have any impact on the unicast forwarding table and is pretty easy to test:
R5(config)#ip mroute 6.6.6.6 255.255.255.255 s0/0
R5(config)#do sh ip rpf 6.6.6.6
RPF information for ? (6.6.6.6)
RPF interface: Serial0/0
RPF neighbor: ? (192.168.156.6)
RPF route/mask: 6.6.6.6/32
RPF type: static
RPF recursion count: 0
Doing distance-preferred lookups across tables
R5(config)#do sh ip pim bsr
PIMv2 Bootstrap information
BSR address: 6.6.6.6 (?)
Uptime: 00:10:02, BSR Priority: 0, Hash mask length: 0
Expires: 00:01:10
R5(config)#do sh ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 6.6.6.6 (?), v2
Info source: 6.6.6.6 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:10:22, expires: 00:02:10
Well that looks like it has resolved the issue - lets confirm by having R4 join a group and seeing if R6 can reach us.
R4(config)#int fa0/0
R4(config-if)#ip igmp join-group 239.1.1.1
R5(config)#do sh ip pim rp
Group: 239.1.1.1, RP: 6.6.6.6, v2, uptime 00:13:31, expires 00:02:02
Ok, so this looks promising
R6#ping 239.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Reply to request 0 from 192.168.101.4, 8 ms
Ok, so that's fixed but in some cases we are unable to use this method, the CCIE exam is full of restrictions on what you can and cant use, so we may need to have an alternative to use.
Option 2 - Use BGP and the ipv4 multicast address family to influence the RPF table
It;s a bit more work but not that difficult to get going
Lets just remove R4 from the 239.1.1.1 group
R4(config-if)#int fa0/0
R4(config-if)#no ip igmp join-group 239.1.1.1
Remove the static ip mroute config from R5
R5(config)#no ip mroute 0.0.0.0 0.0.0.0 s0/0
Now lets set up an IBGP session between R5 and R6 for the ipv4 multicast address-family
R5(config)#router bgp 64512
R5(config-router)#bgp router-id 5.5.5.5
R5(config-router)#no bgp default ipv4-unicast
R5(config-router)#neighbor 6.6.6.6 remote-as 64512
R5(config-router)#neighbor 6.6.6.6 update-source Loopback0
R5(config-router)#address-family ipv4 multicast
R5(config-router-af)#neighbor 6.6.6.6 activate
R5(config-router-af)#no auto-summary
R5(config-router-af)#no synchronization
R6(config)#router bgp 64512
R6(config-router)#no bgp default ipv4-unicast
R6(config-router)#neighbor 5.5.5.5 remote-as 64512
R6(config-router)#neighbor 5.5.5.5 update-source Loopback0
R6(config-router)#address-family ipv4 multicast
R6(config-router-af)#redistribute connected metric 100 route-map MC-Source
R6(config-router-af)#neighbor 5.5.5.5 activate
R6(config-router-af)#no auto-summary
R6(config-router-af)#no synchronization
The special sauce here is thanks to the route-map which will be used to influence the next-hop R5 uses to get to R6's Loopback0 for the Multicast RPF Checks by specifying the IP address of R6's S0/0 interface
R6(config-router-af)#route-map MC-Source
R6(config-route-map)#match interface Loopback0
R6(config-route-map)#set ip next-hop 192.168.156.6
% Warning: Next hop address is our address
This warning is ok, since we are advertising this outwards from R6 to R5
So we wait for BGP to come up and on R5 check the unicast routing table to 6.6.6.6 is unchanged
R5#sh ip route 6.6.6.6
Routing entry for 6.6.6.6/32
Known via "ospf 1", distance 110, metric 11, type intra area
Last update from 192.168.56.6 on FastEthernet0/0, 00:28:56 ago
Routing Descriptor Blocks:
* 192.168.56.6, from 6.6.6.6, 00:28:56 ago, via FastEthernet0/0
Route metric is 11, traffic share count is 1
Fine, is R5 getting the multicast RPF check info?
R5#sh ip bgp ipv4 multicast
BGP table version is 2, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i6.6.6.6/32 192.168.156.6 0 100 0 ?
R5#sh ip rpf 6.6.6.6
RPF information for ? (6.6.6.6)
RPF interface: Serial0/0
RPF neighbor: ? (192.168.156.6)
RPF route/mask: 6.6.6.6/32
RPF type: mbgp
RPF recursion count: 0
Doing distance-preferred lookups across tables
Yes, so can we see the BSR?
R5#sh ip pim bsr-router
PIMv2 Bootstrap information
BSR address: 6.6.6.6 (?)
Uptime: 00:02:03, BSR Priority: 0, Hash mask length: 0
Expires: 00:02:07
R5#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 6.6.6.6 (?), v2
Info source: 6.6.6.6 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:03:16, expires: 00:02:13
Cool, so for the last check, lets get R4 to join a group and try to ping it
R4(config)#int fa0/0
R4(config-if)#ip igmp join-group 239.9.9.9
R5#sh ip pim rp
Group: 239.9.9.9, RP: 6.6.6.6, v2, uptime 00:04:59, expires 00:01:28
R6#ping 239.9.9.9
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.9.9.9, timeout is 2 seconds:
Reply to request 0 from 192.168.101.4, 12 ms
Alright!
No comments:
Post a Comment