Wednesday, December 23, 2009

Detailed working with Multicast InterAS support (IOS 12.0S, not 12.2S) –

Detailed working with Multicast InterAS support (IOS 12.0S, not 12.2S) –



Summary –


1. PE1 initiates traffic on MDT multicast IP. Traffic passes





1. INTER-AS Option B



- Consider the MDT Default group = 232.1.1.1.


- Let’s assume PE1B initiates the MTI neighborship to PE1A.


- MDT SAFI is needed only between ASBR-to-ASBR and ASBR-PE only. Not with P.



Direction: AS55 <---<------< ----AS65 <---<-----<-----



i.) PE1B advertises the default MDT information for VPN blue using the BGP MDT SAFI with itself (PE1B) as the next hop.







ii.) ASBR1B receives the MDT SAFI information and, in turn, advertises this information to ASBR1A with itself (ASBR1B) as the next hop.







iii.) ASBR1A advertises the MDT SAFI to PE1A with itself (ASBR1A) as the next hop.


iv.) PE1A learns the source PE router, the RD, and the default MDT group address from BGP MDT SAFI updates. In addition, from the same BGP MDT SAFI updates, PE1A learns that the RPF Vector, ASBR1A, is the exit router to source PE1B RD 55:1111.






AS55 -->---->------> to AS65






v.) PE1A learns that P1A is an RPF neighbor through an IGP. PE1A then inserts the RPF Vector into the PIM join (with payload data saying “RPF VECTOR ASBR1A” and “SOURCE PE1B”) and sends the PIM join that is destined for source PE1B to P1A.






vi.) source PE1B is not reachable on P1A, but the RPF Vector ASBR1A is reachable, and the next hop is ASBR1A, as learned from the IGP running in the core. P1A then forwards the PIM join to ASBR1A.


vii.) the PIM join sent from P1A to ASBR1A contains the RPF Vector, ASBR1A. When ASBR1A receives the RPF Vector, it learns that it is ITSELF the exit router for source PE1B with RD 55:1111.


viii.) Source PE1B is not reachable on ASBR1A, but source PE1B, RD 55:1111, and group 232.1.1.1 is known from the BGP MDT SAFI updates.


ix.) ASBR1A realizes that the Proxy Vector is itself and sends a regular PIM join towards PE1B with an RPF neighbor of ASBR1B.


x.) ASBR1B passes on this Join to PE1B










2. Inter-AS Option C







i.) PE1B advertises the default MDT information for VPN blue to RR1B within the BGP MDT SAFI.


ii.) RR1B receives the MDT SAFI information, and, in turn, advertises this information to RR1A_(other AS)


iii.) RR1A receives the MDT SAFI information, and, in turn, advertises this information to PE1A.


iv.) PE1A sends a PIM Join with the Proxy Vector that identifies ASBR1A as the exit router to reach source PE1B with RD 55:1111 and Default MDT 232.1.1.1.


v.) P1A does not know how to reach PE1B. However, the PIM join with the Proxy Vector sent from PE1A identifies ASBR1A as being the exit router to reach source PE1B with RD 55:1111 and Default MDT 232.1.1.1. P1A needs to use the Proxy Vector to reach PE1B. The RPF neighbor to reach ASBR1A is through P2A. P1A, thus, forwards the PIM SSM join to P2A.


vi.) P2A does not know how to reach PE1B. However, the PIM join with the Proxy Vector sent from P1A identifies ASBR1A as being the exit router to reach source PE1B with RD 55:1111 and Default MDT 232.1.1.1. P2A uses the Proxy Vector, ASBR1A, to reach PE1B. The RPF neighbor to reach ASBR1B is through ASBR1A (that is, itself).


vii.) ASBR1A receives a PIM Join with Proxy Vector from P2A. ASBR1A realizes that the Proxy Vector is itself and sends a regular PIM join towards PE1B with an RPF neighbor of ASBR1B. The PIM joins continue hop-by-hop building the SSM Default MDT until PE1B


Issues in 12.2S Inter-AS and CSC Multicast

Issues in 12.2S without Multicast VPN Inter-AS Support



Officially InterAS OptionB, optionC and CSC multicast are not supported on any code that doesn't have MDT SAFI support.



InterAS topology used for the below explanation –

CE1----PE1—P1—ASBR1(AS1)------------(AS2)ASBR2—P2—PE2----CE2


  1. Option A – works

    1. does not require support for inter-AS MDTs. All works fine.

  2. Option B Inter-AS – doesn't work
the Source PE address is not shared between ASs

  1. 1st issue: PE1 (in AS1 connected to CE1) doesn't have its loopback IP address sent to the other AS (AS2). Only the loopback of ASBR1 is sent via eBGP to the other AS. Hence, P2 router on the other AS won't be able to perform successful RPF check for the PE1's loopback due to absence of routing info.
  2. 2nd issue: when PIM join in received from CE1 to PE1, PE1 will do a route lookup in the VRF routing table for the next-hop destination. This next-hop destination should be reachable via the MTI tunnel and there should be PIM neighborship with the next-hop. But since in Option2, the next-hop is changed by the ASBR to itself, there will be a contradiction and RPF check will fail on the PE.
  3. In an adjacent autonomous system, a PE router that wants to join a particular source of the default MDT for a given MVPN must know the originator's address of the source PE router. This presents some challenges for Option B inter-AS deployments because the originator next hop for VPNv4 routes is rewritten. The default MDT for inter-AS MVPN could not be established coz the P2 routers in other AS don't hold the PE1 routes.

  1. Option C Inter-AS - works

    1. In case of a typical deployment where RR contains all VPNv4 routes, it'll work. No issues. PE1-AS1 to PE2-AS2 MTI PIM neighborship should be up.




  2. CSC Hierarchical VPN multicast - works

    Check my blog for CSC multicast config (too much config to post here)–

    http://eminent-ccie.blogspot.com/2009/11/csc-hierarchical-mpls-vpn-mvpn-csc.html