Please note that I have moved this blog and you will be redirected to the new page @ netprovia.se

Wednesday, February 22, 2012

Multicast PIM-DM Acrobatics

Imagine a network looking like this:



Green boxes symbolize a small portion of two different MANs under the same management. Each city is running PIM-SM with their own RP. The cities interconnect with BGP and MSDP.

City1-R1 is directly attached to an IP-TV Service Provider. There is no PIM neighborship, the SP is just flooding all their streams out the interface connected to City1-R1.

Everything is working just fine in City1. The streams are visible in the Multicast routing table and customers all over the city can view the different channels. The MAN operator now wants customers in City 2 to be able to watch the same channels. This should be possible since they have a working MSDP connection. But of course it doesn't work because that's how it is in our wonderful world. Things don't work(tm). City2-R1 (RP) lacks the SAs from the Service Provider. Looking at the mroute table on City1-R1 reveals the following sample
#sh ip mroute 233.x.y.z

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 233.x.y.z), 7w0d/00:02:34, RP 10.x.y.z, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vlan42, Forward/Sparse, 00:41:21/00:02:30
    Port-channel70, Forward/Sparse, 11w0d/00:02:34

(a.valid.source.1.1.1.1, 233.x.y.z), 1w5d/00:03:27, flags: T
  Incoming interface: Vlan42, RPF nbr validNbr, RPF-MFD
  Outgoing interface list:
    Port-channel70, Forward/Sparse, 1w5d/00:02:40, 
Spot the flags for the S,G entry.  We are missing the A or M flags. This entry will not be propagated using MSDP. The first solution seems to be to just ask to get a MSDP connection with the Provider (will give the M-flag = propagation will occur) but this was not possible. The provider gave an explanation with some acceptable (..weeell..) arguments so we had to find a different solution.

This is when it becomes painfully obvious that Multicast is a bit of a black hole. There's not a lot of resources out there. Well that's not entirely true. There are resources but there's not a lot of real world examples. The solution finally seems to appear when an operator of the MAN remembers that he saw something about dense-mode during an Advanced Multicast session at CLEUR2012. After some digging we find that there's an add-on to ip pim dense-mode. Proxy register! From documentation:
Dense Mode with Proxy Registering
For a router in a PIM sparse mode (PIM-SM) domain configured to operate in sparse mode or sparse-dense mode, the ip pim dense-mode proxy-register command must be configured on the interface leading toward the bordering dense mode region. This configuration will enable the router to register traffic from the dense mode region with the rendezvous point (RP) in the sparse mode domain.
So we change from ip pim sparse-mode to ip pim dense-mode proxy-register on the interface facing the provider and whoop. A new show ip mroute:

#sh ip mroute 233.x.y.z

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
       V - RD & Vector, v - Vector
 
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 233.x.y.z), 7w0d/00:02:51, RP 10.x.y.z, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vlan42, Forward/Dense, 10:35:15/00:00:00
    Port-channel70, Forward/Sparse, 5w0d/00:02:51

(a.valid.source.1.1.1.1, 233.x.y.z), 5d23h/00:03:23, flags: TA  Incoming interface: Vlan42, RPF nbr validNbr, Mroute, RPF-MFD
  Outgoing interface list:
    Port-channel70, Forward/Sparse, 5d23h/00:03:01, H
Spot the flags. We now have an A which means that it will be sent to MSDP peers and verification on City2-R1 shows:

#sh ip msdp sa-cache 233.x.y.zMSDP Source-Active Cache - 1 entries for 233.x.y.z(validsource.1.1.1, 233.x.y.z), RP 10.11.254.2, BGP/AS 65001, 00:01:40/00:05:16, Peer 10.x.y.z 
 
#sh ip mroute 233.x.y.z  
(*, 233.x.y.z), 00:02:53/00:02:36, RP 10.x.y.z, flags: S  Incoming interface: Null, RPF nbr 0.0.0.0  Outgoing interface list:    GigabitEthernet1/36, Forward/Sparse, 00:02:53/00:02:36
 
(validsource.1.1.1.1, 233.x.y.z), 00:02:53/00:03:21, flags: MT  Incoming interface: Vlan2002, RPF nbr validNbr, Mroute, RPF-MFD   
Outgoing interface list:    GigabitEthernet1/36, Forward/Sparse, 00:02:53/00:02:36, H
There we go. dense-mode proxy-register solved the issue and customers in City2 can now view the channels. Note that this is a workaround solution implemented while waiting for the provider to be able to setup MSDP connections.

No comments:

Post a Comment