Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Multicast in MPLS TE environment

* Problem : MPLS Traffic Engineering tunnels are unidirectional tunnels used to transport unicast packets only. Multicast packets do NOT flow through the TE tunnels but through underlying physical connections. This creates a problem for RPF checks since unicast routes point to tunnels while multicast traffic use physical links...

In below outputs, RPF fails for a remote PE loopback (192.168.2.2) since it's reachable through a TE tunnel :

PE1#sh ip mroute 239.1.1.1
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,
       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

(192.168.2.2, 239.1.1.1), 2d20h/stopped, flags: sTIZ
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    MVRF cust, Forward/Sparse, 2d20h/00:01:23

...


PE1#sh ip rpf 192.168.2.2
RPF information for ? (192.168.2.2) failed, no route exists
PE1#


The 'no route exists' info is a bit misleading since we have a route :


PE1#sh ip route 192.168.2.2
Routing entry for 192.168.2.2/32
  Known via "ospf 1", distance 110, metric 75, type intra area
  Last update from 192.168.2.2 on Tunnel1, 00:14:34 ago
  Routing Descriptor Blocks:
  * 192.168.2.2, from 192.168.2.2, 00:14:34 ago, via Tunnel1
      Route metric is 75, traffic share count is 1

PE1#


but the route is learnt through the TE tunnel interface and we don't have any PIM neighborship on the TE tunnel, that's why RPF fails...

* Solution(s) :

For multicast to work in TE environment, RPF should be done using physical interfaces despite the fact unicast routing table uses TE tunnels.
There is an easy solution when using AA (Autoroute Announce). Things are more complex when using FA (Forwarding Adjacency)...

a) AA (Autoroute Announce) is used to push traffic into TE tunnel

When using AA (i.e. 'tunnel mpls traffic-eng autoroute announce'), we simply need to enable the below command in the IGP (OSPF or ISIS) to solve the problem.


(config-router)# mpls traffic-eng multicast-intact

This command basically tells the IGP to keep 2 sets of best paths during SPF calculation : one for unicast (using TE tunnels and physical interfaces) and one for multicast (using physical interfaces only). This command should be configured on all core routers (part of the traffic engineering cloud).

After having configured this command in our previous example, we see the RPF is done via physical interface, despite unicast route points through TE tunnel interface :

PE1#sh ip route 192.168.2.2
Routing entry for 192.168.2.2/32
  Known via "ospf 1", distance 110, metric 75, type intra area
  Last update from 192.168.2.2 on Tunnel1, 22:30:06 ago
  Routing Descriptor Blocks:
  * 192.168.2.2, from 192.168.2.2, 22:30:06 ago, via Tunnel1
      Route metric is 75, traffic share count is 1

PE1#


PE1#sh ip rpf  192.168.2.2
RPF information for ? (192.168.2.2)
  RPF interface: Ethernet1/0
  RPF neighbor: ? (192.168.1.2)
  RPF route/mask: 192.168.2.2/32
  RPF type: unicast (ospf 1)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
PE1#


PE1#sh ip mroute 239.1.1.1
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,
       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

(192.168.2.2, 239.1.1.1), 3d18h/00:02:41, flags: sTIZ
  Incoming interface: Ethernet1/0, RPF nbr 192.168.1.2
  Outgoing interface list:
    MVRF cust, Forward/Sparse, 3d18h/00:02:45

....

b) FA (Forwarding Adjacency) is used to push traffic into TE tunnel

'mpls traffic-eng multicast-intact' does NOT work with FA (i.e. ' tunnel mpls traffic-eng forwarding-adjacency'), we need to explicitly force the RPF to occur via physical interface.

We typically use MBGP to achieve this. In environment where it's not suitable to run BGP, using static mroute is an alternative.

Here are the steps when implementing the MBGP option :

  • define a new loopback (with private addressing)
  • advertise this loopback via a separate IGP
  • advertise the prefixes that we need to RPF to (ex:BGP loopback for MVPN) via ipv4 multicast AF
  • modify next-hop in ipv4 multicast AF with outbound route-map to set next-hop = new loopback

Here below a config example where we use ISIS to advertise reachability of new loopback used as next-hop in ipv4 multicast AF :


PE1

interface Loopback0
description Loopback used for BGP peerings
ip address 192.168.2.1 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
description USED AS BGP NEXT-HOP FOR MULTICAST
ip address 172.16.2.1 255.255.255.255
!
interface Ethernet1/0
description CORE INTERFACE
ip router isis MULTICAST
!
interface Ethernet2/0
description CORE INTERFACE
ip router isis MULTICAST
!
router isis MULTICAST
net 49.0001.1111.1111.1111.00
is-type level-2-only
passive-interface Loopback1
!
router bgp 1
neighbor RR peer-group
neighbor RR remote-as 1
neighbor RR update-source Loopback0
neighbor 192.168.2.3 peer-group RR
neighbor 192.168.2.4 peer-group RR
!
address-family ipv4 multicast
  neighbor RR route-map MBGP-MCAST out
  neighbor 192.168.2.3 activate
  neighbor 192.168.2.4 activate
  no auto-summary
  network 192.168.2.1 mask 255.255.255.255
exit-address-family
!              
route-map MBGP-MCAST permit 10
set ip next-hop 172.16.2.1

PE2

interface Loopback0
description Loopback used for BGP peerings
ip address 192.168.2.2 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
description USED AS BGP NEXT-HOP FOR MULTICAST
ip address 172.16.2.2 255.255.255.255
!
interface Serial1/0
description CORE INTERFACE
ip router isis MULTICAST
!
interface Serial2/0
description CORE INTERFACE
ip router isis MULTICAST
!
router isis MULTICAST
net 49.0001.2222.2222.2222.00
is-type level-2-only
passive-interface Loopback1
!        
router bgp 1
neighbor RR peer-group
neighbor RR remote-as 1
neighbor RR update-source Loopback0
neighbor 192.168.2.3 peer-group RR
neighbor 192.168.2.4 peer-group RR
!
address-family ipv4 multicast
  neighbor RR route-map MBGP-MCAST out
  neighbor 192.168.2.3 activate
  neighbor 192.168.2.4 activate
  no auto-summary
  network 192.168.2.2 mask 255.255.255.255
exit-address-family       
!        
route-map MBGP-MCAST permit 10
set ip next-hop 172.16.2.2

All core routers should be configured to participate in IGP (here ISIS) used to propagate reachability of new loopbacks.

Here below some outputs when using FA with such a config :

PE1#sh ip rpf 192.168.2.2
RPF information for ? (192.168.2.2)
  RPF interface: Ethernet2/0
  RPF neighbor: ? (192.168.1.10)
  RPF route/mask: 192.168.2.2/32
  RPF type: mbgp
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
PE1#

We end up with this result because the mBGP route is preferred over the unicast route.
When looking at mBGP update, we see the next-hop is the new loopback defined :


PE1#sh ip bgp ipv4 multicast 192.168.2.2
BGP routing table entry for 192.168.2.2/32, version 11
Paths: (2 available, best #2, table Default-MBGP-Routing-Table)
  Not advertised to any peer
  Local
    172.16.2.2 (metric 20) from 192.168.2.4 (192.168.2.4)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 192.168.2.2, Cluster list: 0.0.0.32
  Local
    172.16.2.2 (metric 20) from 192.168.2.3 (192.168.2.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 192.168.2.2, Cluster list: 0.0.0.32
PE1#


and the route towards that next-hop is learnt via ISIS through the physical interface :


PE1#sh ip route 172.16.2.2
Routing entry for 172.16.2.2/32
  Known via "isis", distance 115, metric 20, type level-2
  Redistributing via isis
  Last update from 192.168.1.10 on Ethernet2/0, 00:11:19 ago
  Routing Descriptor Blocks:
    192.168.1.10, from 172.16.2.2, via Ethernet2/0
      Route metric is 20, traffic share count is 1
  * 192.168.1.2, from 172.16.2.2, via Ethernet1/0
      Route metric is 20, traffic share count is 1

PE1#

PE1#sh ip mroute 239.1.1.1
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,
       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

(192.168.2.2, 239.1.1.1), 3d18h/00:02:41, flags: sTIZ
  Incoming interface: Ethernet2/0, RPF nbr 192.168.1.10
  Outgoing interface list:
    MVRF cust, Forward/Sparse, 3d19h/00:07:28

....

Version history
Revision #:
1 of 1
Last update:
‎11-03-2010 07:20 AM
Updated by:
 
Labels (1)
Everyone's tags (2)
Comments
New Member

Very good explanation

New Member

Hello Fabrice,

Good explaination. I have one doubt -  when we have inter area tunnels is there any extra configuration that is needed?

autoroute announce would work when we have tunnels in the same area. For the inter area tunnels, i am using the command autoroute destination. I tried to enable the command mpls traffic-eng multicast-intact on all the core routers but I was getting rpf error when my ingress pe tries to join the mdt tunnel for the egress pe router.

As a workaround I had to use the static mroute pointing towards my next hop router's interface for the rpf to work.

Regards,

Shreeram

Cisco Employee

Hi Shreeram,

multicast-intact feature works only with AA, it doesn't work in any other scenario.

In your case, you are then left with using static mroute or the solution described in point b)

Thx,

Fabrice