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


3 comments:

  1. Superb.. This is going to help a lot

    ReplyDelete
  2. Swap, can you give me the configs for this diagram. I am trying to set up something similar and I was wondering how you are peering the ASBR's and if you have to put send-label everywhere? Or are you redistributing the ASBR connections back into the IGP? Whenever I set up this scenario I have to put send-label everywhere. Otherwise the VPN doesn't work, should this be the standard if you see this type of CSC setup? By everywhere I am talking about the all the PEs and the ASBRs.

    ReplyDelete
  3. As you rightly said, there are two ways to distribute the labels within the AS -
    1. redistribute into local IGP
    2. use BGP to distribute labels using "send-label" for all neighbors. Note that "send-label" must be configured on both sides for BGP send-label feature to work. e.g. if PE1 and ASBR1 form iBGP and we intend to use BGP for disributing labels, we must use send-label on both PE1 and ASBR1.

    For configs, you can do a quick search on OptionB and OptionC inter-as, you'll find plenty of sample configs on the net. Let me know if u r still unable to locate the configs, i'll post them.

    Swap
    #19804

    ReplyDelete