Thursday, February 6, 2014

NTS: Advanced Multicast

Advanced Multicast




RPF (Reverse Path Forwarding)

In an RPF check, the router looks in a routing table to determine its RPF interface, which is the interface closest to the root (the source or the RP). The RPF interface is also the incoming interface for the multicast data. RPF checks happen in the control-plane (PIM, MSDP) and in the data-plane (multicast data).

The routing table used for RPF checks can be the global unicast routing table or a separate multicast routing table. In any case, the RPF table contains only unicast routes (the multicast source or the RP).

MP-BGP and M-ISIS can be used to create separate unicast and multicast routing tables.

MP-BGP updates can include IPv4 multicast RPF routes along with IPv4 unicast routes, totally separated (different path attributes) from each other.

You can use "sh ip mroute count" to check for increasing RPF counts.


Fixing RPF issues

If you have IP connectivity over a TE tunnel and require PIM connectivity too, then extra care must be taked. Since you cannot activate PIM on a TE tunnel, you must somehow fix the possible RPF issue on the head-end. The same must be done in every other case where unicast and multicast forwarding do not agree.

Solutions
  • static mroute
  • multicast BGP
  • multicast topology in IS-IS
  • mpls traffic-eng multicast-intact (for IGP routes)

You can use the command "sh ip rpf" in order to verify RPF issues.

Before

IOS
R2#sh ip rpf 19.19.19.19
 failed, no route exists



IOS-XR
GSR#sh pim rpf 2.2.2.2
Table: IPv4-Unicast-default
* 2.2.2.2/32 [115/30]
    via Null with rpf neighbor 0.0.0.0



In IOS-XR, the command "sh pim rpf" provides an output only if the address provided is already used as a multicast source. Use "sh pim rpf hash" to check in advance.

After fixing the RPF issue:

IOS
R2#sh ip rpf 19.19.19.19
RPF information for ? (19.19.19.19)
  RPF interface: FastEthernet1/0.24
  RPF neighbor: ? (26.2.4.4)
  RPF route/mask: 19.19.19.19/32
  RPF type: unicast (isis)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base


IOS-XR
GSR#sh pim rpf 2.2.2.2
Table: IPv4-Multicast-default
* 2.2.2.2/32 [115/30]
    via GigabitEthernet0/1/0/1 with rpf neighbor 26.3.19.3



static mroute

IOS
ip mroute 2.2.2.2 255.255.255.255 Tunnel0

IOS-XR
multicast-routing
 address-family ipv4
  static-rpf 2.2.2.2 32 tunnel-te0 3.3.3.3



multicast-intact

When enabled on an IGP, the IGP automatically publishes to the RIB a parallel (or alternate) set of equal-cost next-hops for all IPv4 destinations learned through LS advertisements, for use solely by PIM. These next-hops are called mcast-intact next-hops. The mcast-intact next-hops have the following characteristics:

  • They are guaranteed not to contain any IGP shortcuts (like TE tunnels).
  • They are not used for unicast routing, but are used only by PIM to look up an IPv4 next-hop to a PIM source.
  • They are not published to the FIB.
  • When multicast-intact is enabled on an IGP, all IPv4 destinations that were learned through link-state advertisements are published with a set of equal-cost mcast-intact next-hops to the RIB. This attribute applies even when the native next-hops have no IGP shortcuts.

IOS
router ospf 1
 mpls traffic-eng multicast-intact
router isis 1
 mpls traffic-eng multicast-intact

IOS-XR
router ospf 1
 mpls traffic-eng multicast-intact
!

router isis 1
 address-family ipv4 unicast
  mpls traffic-eng multicast-intact



Multicast-intact doesn't work with TE forwarding-adjacency, use multicast BGP or static mroute.

multicast-intact vs static mroute in TE tunnels
  • use multicast-intact to accept multicast traffic coming from outside a TE tunnel, when the unicast route is pointing inside the TE tunnel
  • use static mroute to accept multicast traffic coming from inside a TE tunnel, when the unicast route is pointing outside the TE tunnel

IS-IS Multicast Topology

Multicast topology for ISIS allows the configuration of a separate IS-IS multicast topology for IPv4 or IPv6 routing, which runs a separate SPF.

IS-IS multicast inserts routes from the IS-IS multicast topology into the multicast-unicast table in the RIB for the corresponding address family. Since PIM uses this table, PIM uses routes from the multicast topology instead of routes from the unicast topology.


Multicast BGP

The multicast BGP database can be used by a a multicast routing protocol (i.e. PIM) to perform RPF lookups for multicast-capable sources. Thus, packets can be sent and accepted based on the multicast topology and not on the unicast topology.

This is an easy way to change the multicast routing without affecting unicast too. Static mroutes can also be used.

IOS
router bgp 65000
 no bgp default ipv4-unicast
 neighbor 7.7.7.7 remote-as 65000
 !
 address-family ipv4 multicast
  neighbor 7.7.7.7 activate

  network 192.168.7.0
 exit-address-family


IOS-XR
router bgp 65000
 address-family ipv4 multicast
  network 192.168.7.0/24
 !
 neighbor 7.7.7.7
  address-family ipv4 multicast



IOS
R8#sh ip rpf 192.168.7.0
RPF information for ? (192.168.7.0)
  RPF interface: FastEthernet0/0
  RPF neighbor: ? (192.168.78.7)
  RPF route/mask: 192.168.7.0/24
  RPF type: mbgp
  RPF recursion count: 0
  Doing distance-preferred lookups across tables



Changing of BGP distance might be needed on the remote peer, if an IGP already provides a better route.

When you enable the multicast address-family under BGP, then these prefixes take precedence over the prefixes learned in the BGP unicast address-family; only the BGP prefixes learned in the multicast address-family are used for any multicast routing. Use "show route ipv4 multicast" in IOS-XR to display the ipv4 multicast routes.

You might need to also advertise a specific next-hop for the RPF route, if the default next-hop doesn't satisfy the RPF needs (recursive lookup might not be supported).



MSDP & Anycast RP

MSDP provides a way to connect multiple PIM-SM domains, so that RPs can exchange information about active multicast sources. It uses

MSDP sessions are formed between the RPs of various PIM domains, which are called MSDP peers.

MSDP is also used between Anycast RPs within a single PIM domain to synchronize information about the active sources being served by each Anycast-RP peer. Anycast RPs will each have the same IP address configured on a Loopback interface (making this the Anycast address) and will MSDP peer with each other using a separate loopback interface.

With Anycast RP, RP failover depends only on IGP convergence

MSDP RPs send SA (Source-Active) messages in order to notify each other of active multicast sources.

An MSDP RP sends an SA message to its peers each time it receives a PIM Register or Null-Register message from a Source DR about a new/active source. MSDP SA messages include the same multicast data that is also encapsulated in PIM Register or Null-Register messages.


IOS
interface Loopback99
 ip address 99.99.99.99 255.255.255.255
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
ip msdp peer 1.1.1.1 connect-source Loopback0
ip msdp originator-id Loopback0

!
ip pim rp-address 99.99.99.99



IOS-XR
interface Loopback99
  ipv4 address 99.99.99.99 255.255.255.255
!

interface Loopback0
  ipv4 address 1.1.1.1 255.255.255.255
!
router msdp
 originator-id Loopback0
 peer 2.2.2.2
  connect-source Loopback0
!
router pim
 address-family ipv4
  rp-address 99.99.99.99



The address on the interface used as anycast RP must be advertised into an IGP (preferably as external route to be able to play easily with the metric).

When using anycast IPv4 addresses in Loopbacks, it's good practice to hardcode all the protocol router-ids manually in order to avoid using the anycast address as router-id for a protocol.

In some software releases originator-id might not be required, but it's always good practice to configure it (especially in anycast topologies).

In current releases, when running Inter-AS MSDP, the peer/source IPs must agree with the BGP update source on each neighbor. If you also have a BGP peering session with an MSDP peer, you should use the same IP address for MSDP (peer/connect-source) as you do for BGP (update-source). If MDT is using a non-loopback interface due to eBGP with directly connected neighbor, you might get the message "%MDT-4-LBSRC: VRF ABC: MDT X uses source address x.x.x.x from a non-loopback interface". Besides changing the update-source of the eBGP peering, you can also use the "bgp next-hop loopback X" command under the appropriate vrf.

Use "default-peer" in IOS-XR when the peer address isn't in BGP.

If there is a single MSDP peer, then no RPF check takes place about the originator-id. If there are multiple MSDP peers, then you can put them under a mesh-group in order to disable the RPF check on them.


Links




Multicast Filtering

Setting an interface to PIM v1 at the border of a PIM domain prevents v2 Bootstrap messages from leaking to the neighboring PIM domain.

Use "ip pim passive" under an interface if you want to block the forwarding of PIM control plane traffic; only IGMP traffic will pass.

BSR filtering

IOS
interface X
 ip pim bsr-border



IOS-XR
router pim
 address-family ipv4
  interface X
   bsr-border




Auto-RP filtering

IOS-XR
multicast-routing
 address-family ipv4
  interface TenGigE0/2/0/0
   boundary MCAST-ACL

!
ipv4 access-list MCAST-ACL
 deny host 224.0.1.39
 deny host 224.0.1.40
 permit any



IGMP filtering

IOS
interface X
 ip igmp access-group IGMP-ACL


! match (*,G)
ip access-list extended IGMP-ACL
 permit ip host 0.0.0.0 host GROUP


! match (S,G) and (*,G)
ip access-list extended IGMP-ACL
 permit ip any host GROUP





Multicast Admission Control


  • Global or per VRF
    • limit the number of mroutes that can be added to the global table
      • ip multicast route-limit MAX-MROUTES THRESHOLD
    •  limit the number of mroutes that can be added to a particular MVRF table
      • ip multicast vrf MVRF route-limit MAX-MROUTES THRESHOLD
    • limit the number of mroute states created from IGMP membership reports
      • ip igmp limit MAX-IGMPS
  • Per interface
    • limit the number of mroute states
      • ip multicast limit MCAST-ACL MAX-MROUTES
    • limit the number of mroutes states created from  IGMP membership reports
      • ip igmp limit MAX-IGMPS
  • Per neighbor
    • Limits the number of SA messages allowed in the SA cache from an MSDP peer
      • ip msdp sa-limit MSDP-PEER MAX-SA-MESSAGES
         
Check "Multicast Filtering" above for the format of MCAST-ACL.


Rate-limit

The "ip multicast rate-limit" interface command is not supported any more.

You need to use the the MQC syntax to define multicast traffic and then police it accordingly.




Multicast Fast Convergence

  • tune PIM hellos (queries)
  • tune RPF check interval/backoff
  • MoFRR


Multicast-only FRR

The basic idea of MoFRR is to send a secondary PIM join from the receiver toward the source on a backup path to a different upstream interface. The network then receives two copies of the multicast stream over two separate and redundant paths through the network, but the redundant packets are discarded at topology merge points due to RPF checks. When the primary path fails, it can switch over to the backup path instantly without issuing a new PIM join. 

Actually MoFRR is pre-building an alternate multicast tree in order to achieve faster convergence.

  • RIB-based MoFRR
    • Supported on CRS and XR12000 series routers
    • Based on routing convergence
  • Flow-based MoFRR
    • Supported ASR9k
    • Based on packet count per 30ms


IOS (15.2)

ip multicast rpf mofrr MOFRR-SG-ACL
!
ip access-list standard MOFRR-SG-ACL
 permit 10.10.10.0 0.0.0.255


IOS > 15.2 is required for MoFRR.


IOS-XR
router pim
 address-family ipv4
  mofrr rib MOFRR-SG-ACL
!

ipv4 access-list MOFRR-SG-ACL
 10 permit ipv4 host 1.1.1.1 host 239.3.3.3



Links



Troubleshooting

Enable "debug ip mfib fs" and "debug ip mfib ps" on the receiver, and then send some pings from a source to an igmp join group on the receiver to check the results.



IPv6 Multicast


IOS
ipv6 multicast-routing

IOS-XR
multicast-routing
 address-family ipv6
  interface all enable



In IOS, all IPv6 interfaces are PIM enabled by default after enabling ipv6 multicast-routing.


IPv6 RP definition

IOS

ipv6 pim bsr candidate bsr 2002:2:2::2
ipv6 pim bsr candidate rp 2002:2:2::2

!
ipv6 pim rp-address 2002:2:2::2

IOS-XR
router pim
 address-family ipv6
  rp-address 2002:2:2::2
  bsr candidate-rp 2002:2:2::2 

  bsr candidate-bsr 2002:2:2::2


MLD

IOS
ipv6 multicast-routing
!interface Loopback0
 ipv6 mld join-group FF99::99


IOS-XR
multicast-routing
 address-family ipv6
  interface all enable
!

router mld
 interface Loopback0
  join-group ff99::99


MLDv2 is used by default.


Verification

R2#sh ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF99::99), 00:00:08/00:03:21, RP 2002:2:2::2, flags: S
  Incoming interface: Tunnel4
  RPF nbr: 2002:2:2::2
  Immediate Outgoing interface list:
    Ethernet0/2, Forward, 00:00:08/00:03:21


R2#ping FF99::99
Output Interface: Ethernet0/2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF99::99, timeout is 2 seconds:
Packet sent with a source address of 2002:2:2:27::2

Reply to request 0 received from 2002:2:2::7, 60 ms
Reply to request 1 received from 2002:2:2::7, 0 ms
Reply to request 2 received from 2002:2:2::7, 4 ms
Reply to request 3 received from 2002:2:2::7, 4 ms
Reply to request 4 received from 2002:2:2::7, 0 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/13/60 ms
5 multicast replies and 0 errors.



Almost everything cli-wise is similar to IPv4.


Static mroutes

IOS
ipv6 route 2002:2:2::2/128 Tunnel0 multicast

IOS-XR
multicast-routing
 address-family ipv6
  static-rpf 2002:2:2::2 128 tunnel-te0 2002:3::1







NSF

IOS-XR
router pim
 nsf lifetime 30
!

router igmp
 nsf lifetime 30
!
router mld
 nsf lifetime 30



Generally, configure the IGMP NSF and PIM NSF lifetime values to be equal or larger than the query or join query interval, but less than the holdtime




Multipath

By default, if ECMP paths are available, the RPF for multicast traffic will be based on the highest IP address (aka highest PIM neighbor).

When the 'ip multicast multipath' command is configured, the multicast load splitting will be based on the source address of the stream. PIM Joins will be distributed over the different ECMP links based on a hash of the source address.

Multicast multipath must be enabled on the receiver side of the ECMP path.

IOS
ip multicast multipath

IOS
R2#sh ip rpf 19.19.19.19
RPF information for ? (19.19.19.19)
  RPF interface: FastEthernet0/0.24
  RPF neighbor: ? (20.2.4.4)
  RPF route/mask: 19.19.19.19/32
  RPF type: unicast (ospf 1)
  Doing distance-preferred lookups across tables
  Multicast Multipath enabled.
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base


By default only the source address is used in the calculation. Better load-splitting can be achieved by using the "s-g-hash next-hop-based" options.

When the ip multicast multipath command is enabled, the presence of PIM hello message from neighbors is not considered; that is, the chosen RPF neighbor does not depend on whether or not PIM hello messages are received from that neighbor; it only depends on the presence or absence of an equal-cost route entry.

If using BGP and multicast, then you must also enable multipath on BGP.

If using static mroutes, then you need to somehow create two (or more) different static mroutes because only one is accepted. You can use a dummy ip address and two (or more) static ip routes in order to achieve this.


IOS
ip route 192.168.1.1 255.255.255.255 20.2.3.3
ip route 192.168.1.1 255.255.255.255 20.2.4.4

!
ip mroute 19.19.19.19 255.255.255.255 192.168.1.1


In the above example, multicast load-balancing occurs between 20.2.3.3 and 20.2.4.4 for source 19.19.19.19 (192.168.1.1 is the dummy address used).

Use "sh ip multicast rpf tracked" to verify the multiple rpf paths.



1 comment: