* 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
....
