Change in the order of RT-import for a few NG-MVPN source routes causing multicast stream issues

By default, in Inter-AS option-A deployment, route communities are not stripped before advertising. This may result in undesired behaviour, resulting in a multicast stream accessibility issue

The issue will be outlined using below set-up:

Topology [S, G - 10.1.11.1, 232.252.5.5]:

Source ------ PE1 ------ P1 ------- ASBR1 [AS64514] ----- Option A with MVPN & PIM ------ [AS64515] ASBR2 --- P2 --- PE5 ------- Receiver

Lo0 addresses:

PE1 - 172.31.11.11

P1 - 10.1.1.1

ASBR1 - 10.10.10.10

ASBR2 - 172.31.20.0

P2 - 10.2.2.2

PE5 - 172.31.55.55

user@PE5_RE# run show route table CUST.mvpn.0 match-prefix "7:*" extensive 

CUST.mvpn.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
7:20.20.20.20:20:64514:32:10.1.11.1:32:232.252.5.5/240 (1 entry, 1 announced)
        *PIM    Preference: 105
                Next hop type: Multicast (IPv4) Composite, Next hop index: 1048579
                Address: 0x7a9b7c4
                Next-hop reference count: 12
                Kernel Table Id: 0
                State: <Active Int Ext>
                Age: 57:49      Metric: 0 
                Validation State: unverified 
                Task: PIM.CUST
                Announcement bits (3): 0-PIM.CUST 1-mvpn global task 2-rt-export 
                AS path: I 
                Communities: target:172.31.20.0:8
                Thread: junos-main 

Mcast source extended community details for source route 10.1.11.1:

user@PE1_RE# run show route advertising-protocol bgp 10.1.1.1 extensive 10.1.11.1 | match communi 
     Communities: target:64514:64515 src-as:64514:0 rt-import:172.31.11.11:8

user@ASBR1_RE# run show route 10.1.11.1 extensive | match communit 
     Communities: target:64514:64515 src-as:64514:0 rt-import:172.31.11.11:8
     Communities: target:64514:64515 src-as:64514:0 rt-import:172.31.11.11:8

user@ASBR2_RE# run show route advertising-protocol bgp 10.2.2.2 extensive 10.1.11.1 | match communit 
     Communities: target:64514:64515 src-as:64514:0 src-as:64515:0 rt-import:172.31.20.0:8 rt-import:172.31.11.11:8

user@PE5_RE# run show route extensive 10.1.11.1 | match communit 
     Communities: target:64514:64515 src-as:64514:0 src-as:64515:0 rt-import:172.31.20.0:8 rt-import:172.31.11.11:8
     Communities: target:64514:64515 src-as:64514:0 src-as:64515:0 rt-import:172.31.20.0:8 rt-import:172.31.11.11:8

In the above scenario, Receivers connected to PE5 will not be able to get the multicast stream for 232.252.5.5 from source 10.1.11.1, as the Source_PE rt-import being selected was that of ASBR2 rather than PE1.

rt-import is a VRF route import extended community auto-generated for internal use, specifically for importing c-multicast [c - Customer] in NG-MVPN.

Please check out the document below for more details.

https://www.juniper.net/documentation/us/en/software/junos/multicast/topics/concept/src-as-rt-import-communities-generating.html

When NG-MVPN is stitched across ASs via Inter-AS option-A, the rt-imports are retained end-to-end. Since NG-MVPN relies on BGP community selection criteria [refer to KB108279 [juniper.net] for more details] and honours communities based on the order in which they were received, this may result in the issue outlined in the symptoms section.

If this is not a desired behaviour, the user can adopt one of the following steps to attain predictable results:

1. Apply route policy to strip the rt-import received from the neighbour peer AS, as outlined in KB108165 [juniper.net]

   After the above route-policy config application on ASBR2, it now advertises the Mcast source without PE1's rt-import community:

   user@ASBR2_RE# run show route advertising-protocol bgp 10.2.2.2 extensive 10.1.11.1 | match communit   

      Communities: target:64514:64515 src-as:64514:0 src-as:64515:0 rt-import:172.31.20.0:8

2. Plan the extended route communities as per Big/little-endian selection sorting, as outlined in KB108279 [juniper.net], so that the source_PE rt-import community takes precedence

   For instance - Big-endian sorting with respect to rt-import extended communities:

   user@ASBR2_RE# run show route advertising-protocol bgp 10.2.2.2 extensive 10.1.11.1 | match communit 

      Communities: target:64514:64515 src-as:64514:0 src-as:64515:0 rt-import:172.16.20.0:8 rt-import:172.31.11.11:8 --> Starting from most significant bit, lowest value is 16 over 31 [as 1st octet is the same, i.e. 172, contention moves to 2nd octet], so rt-import:172.16.20.0:8 takes precedence over rt-import:172.31.11.11:8

    

   Little-endian* [which stores the least significant byte (the "little end") first]:

   For instance - Little-endian sorting with respect to rt-import extended communities:

   user@ASBR2_RE# run show route advertising-protocol bgp 10.2.2.2 extensive 10.1.11.1 | match communit 

      Communities: target:64514:64515 src-as:64514:0 src-as:64515:0 rt-import:172.31.20.0:8 rt-import:172.31.11.11:8 --> Starting from least significant bit, lowest value is 0 over 11, so rt-import:172.31.20.0:8 takes precedence over rt-import:172.31.11.11:8

    

   *Endianness refers to the order in which bytes are arranged in system memory. Big/little-endian sorting selection varies across platforms/vendors, but is consistent within the same model