Routing

 View Only
last person joined: 23 hours ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
Back to discussions
Expand all | Collapse all

BGP inet/multicast in routing instance

  • 1.  BGP inet/multicast in routing instance

    Posted 12-19-2024 11:38

    Hi all - 

    I'm learning Juniper. I configured a network of two Juniper MX, NG-MVPNs over SR-MPLS.
    The multicast source is connected to MX-1, the receiver is connected to MX-2.
    Groups requested by IGMP are successfully delivered to the recipient. Everything is fine.

    Task: configure the inter-operator interface with the recipient - mBGP+MSDP
    mBGP with receiver must be configured with AFI/SAFI = inet/multicast

    All protocols are configured and their sessions are UP.
    I faced a problem that BGP does'nt advertise source routes.
    As far as I know, BGP on Juniper advertises and installs routes of multicast sources from and into the MVPN.inet.2 table.

    I was able to import only local routes into MVPN.inet.2 from MVPN.inet.0 on MX-2 (rib-group, auto-export)
    Routes received from MX-1 are not imported into MVPN.inet.2 at all and, accordingly,  multicast source routes are not advertised by BGP to CE.

    Did I choose the right approach to solving the problem?

    Why aren't all routes imported from MVPN.inet.0 to MVPN.inet.2?
    Is it possible to import them in  my configuration? And how?

    Here are some excerpts from the configuration:

    routing-options

    mpaul@MX-2> show configuration routing-options 
resolution;
router-id 192.168.0.4;
autonomous-system 65000;
rib-groups {
    From_MVPN_0_to_2 {
        import-rib MVPN.inet.2;
    }
}

    routing-instances

    mpaul@MX-2> show configuration routing-instances  
MVPN-1 {
    instance-type vrf;
    routing-options {
        auto-export {
            family inet {
                unicast {
                    rib-group From_MVPN_0_to_2;
                }
            }
        }
    }
    protocols {
        bgp {
            group CE {
                type external;
                family inet {
                    multicast;
                }
                neighbor 3.0.0.10 {
                    export ANY;
                    peer-as 100;
                }
            }
        }
        msdp {
            group CE {
                peer 3.0.0.10 {
                    local-address 3.0.0.1;
                }
            }
        }
        mvpn {
            mvpn-mode {
                spt-only {
                    convert-sa-to-msdp;
                }
            }
        }
        pim {
            rp {
                local {
                    address 100.0.0.4;
                    group-ranges {
                        233.0.0.0/8;
                    }
                }
            }
            interface all;
        }
    }
    interface xe-0/1/1.0;
    interface xe-0/1/2.0;
    interface lo0.100;
    route-distinguisher 192.168.0.4:10;
    vrf-target target:65000:10;
    vrf-table-label;
    provider-tunnel {
        rsvp-te {
            label-switched-path-template {
                default-template;
            }
        }
    }
}

    Some show routes

    mpaul@MX-2> show route table MVPN-1.inet.0 

MVPN.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.10.0/24        *[BGP/170] 13:39:13, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
2.0.0.0/24         *[Direct/0] 1d 03:04:16
                    >  via xe-0/1/1.0
2.0.0.1/32         *[Local/0] 1d 03:04:16
                       Local via xe-0/1/1.0
3.0.0.0/24         *[Direct/0] 12:13:11
                    >  via xe-0/1/2.0
3.0.0.1/32         *[Local/0] 12:13:11
                       Local via xe-0/1/2.0
100.0.0.3/32       *[BGP/170] 13:39:13, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
100.0.0.4/32       *[Direct/0] 1d 17:29:52
                    >  via lo0.100
224.0.0.2/32       *[PIM/0] 1d 17:29:52
                       MultiRecv
224.0.0.13/32      *[PIM/0] 1d 17:29:52
                       MultiRecv
224.0.0.22/32      *[IGMP/0] 1d 03:04:16
                       MultiRecv

mpaul@MX-2> show route table MVPN.inet.2    

MVPN.inet.2: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2.0.0.0/24         *[Direct/0] 17:40:25
                    >  via xe-0/1/1.0
2.0.0.1/32         *[Local/0] 17:40:25
                       Local via xe-0/1/1.0
3.0.0.0/24         *[Direct/0] 12:13:14
                    >  via xe-0/1/2.0
3.0.0.1/32         *[Local/0] 12:13:14
                       Local via xe-0/1/2.0
3.100.0.1/32       *[BGP/170] 03:11:47, MED 0, localpref 100
                      AS path: 100 I, validation-state: unverified
                    >  to 3.0.0.10 via xe-0/1/2.0
100.0.0.4/32       *[Direct/0] 17:40:25
                    >  via lo0.100


mpaul@MX-2> show route advertising-protocol bgp 3.0.0.10    

MVPN.inet.2: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 2.0.0.0/24              Self                                    I
* 3.0.0.0/24              Self                                    I
* 100.0.0.4/32            Self                                    I

     



    ------------------------------
    Paul Muller
    ------------------------------


  • 2.  RE: BGP inet/multicast in routing instance

    Posted 12-22-2024 11:09
    Edited by Flashover_ 12-22-2024 15:06

    Hello Paul,

    I will split your questions into several parts for analysis:

    • Is your VPN name "MVPN-1" or "MVPN"? Both are being mentioned in your post.
      • I will mention "$VPN" for my post as just a placeholder for any random name that your VRF could have.
    • You wrote:
      • As far as I know, BGP on Juniper advertises and installs routes of multicast sources from and into the MVPN.inet.2 table.

    Recap:

    1. Prefixes received from peers in global table with BGP AF [inet-multicast] will be imported in [inet.2] instead of [inet.0].
    2. Prefixes received from external peers living in a VRF with BGP AF [inet-multicast] will be imported in [$VPN.inet.2].
    3. Prefixes received from internal peers (via your core network, MX-1 + MX-2 etc) for a VRF with BGP AF [inet-vpn multicast] will be imported in [$VPN.inet.2].

    You wrote:

    • I was able to import only local routes into MVPN.inet.2 from MVPN.inet.0 on MX-2 (rib-group, auto-export)
    • Routes received from MX-1 are not imported into MVPN.inet.2 at all and, accordingly,  multicast source routes are not advertised by BGP to CE.
    • Why aren't all routes imported from MVPN.inet.0 to MVPN.inet.2?
    • Is it possible to import them in  my configuration? And how?

    To solve this I think you need to add the [inet-vpn multicast] family to your BGP network core. Could you try and check if the [inet-vpn multicast] is enabled in your core? I think then it matches points 2 + 3 from the previous list.

    set protocols bgp group $xyz family inet-vpn multicast
    • The VRF on MX-1 should have an external peer and it should advertise a prefix via [inet multicast] to your VPN.
    • Then MX-1 should advertise it via [inet-vpn multicast] to MX-2.
    • Then MX-2 should import it in $VPN.inet.2 automatically, no rib-group needed AFAIK.
    • Then MX-2 should be able to advertise the prefix with BGP to [neighbor 3.0.0.10].
    • PIM in $VPN should not look at $VPN.inet.0 but in $VPN.inet.2, for this a RIB-group at PIM level is needed, see below.

    To do this I think this configuration can be removed:

    MVPN-1 {
    routing-options {
        auto-export {
            family inet {
                unicast {
                    rib-group From_MVPN_0_to_2;
                }
            }
        }
    }

    Now to tell PIM to look at $VPN.inet.2 instead of $VPN.inet.0:

    (I've changed rib-group name a little bit for easier readability)

    rib-groups {
    RG_PIM_IMPORT_MVPN-1_INET_2 {
        import-rib MVPN-1.inet.2;
    }
}

#And link it to PIM in the VPN:

mpaul@MX-2> show configuration routing-instances  
MVPN-1 {
    protocols {
        pim {
            rib-group RG_PIM_IMPORT_MVPN-1_INET_2;
        }
    }
}

    After this change with command [show multicast rpf] you should be able to see the result:

    show multicast rpf instance MVPN-1

    https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-multicast-rpf.html

     user@host>  show multicast rpf 

Multicast RPF table: inet.0, 12 entries

    That "inet.0" text should change in your lab if you check before+after making changes I guess it should become "MVPN.inet.2" or "MVPN-1.inet.2" depending on your VPN name there.

    Then I think you want the prefix [1.0.10.0/24] to be advertised to the neighbor, so repeating this command should show it:

    mpaul@MX-2> show route advertising-protocol bgp 3.0.0.10

    • Once that neighbor has a receiver, you should receive a PIM Join.
      • I hope you have (S,G = SSM) not (*,G = ASM) network here as it would be a bit easier :)
    • In the VPN the PIM would do a lookup via [$VPN.inet.2] and find the next-hop for a source inside prefix [1.0.10.x] and find MX-1 as the upstream next-hop (=UMH).
    • Only if you have a Type-5 route it will generate a Type-7 Join.
      • I don't know if changes to MSDP are required or the whole interaction with MSDP <> Type-6 routes and PIM-RP.
    • Once MX-1 VPN receives it then it should be transformed into PIM Join towards the source there.
    • And finally, traffic should flow...

    Just noticed that MSDP allows for RIB-Groups as well:

    https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/rib-group-edit-protocols-msdp.html

    Configuration:

    set routing-instances MVPN-1 msdp rib-group RG_PIM_IMPORT_MVPN-1_INET_2

    You can check what MSDP is sending with:

    mpaul@MX-2> show route advertising-protocol msdp 3.0.0.10

    I can't say for sure if this MSDP part is required. AFAIK every PIM-RP needs the MSDP info, but not every PIM router.


    Original Message


  • 3.  RE: BGP inet/multicast in routing instance

    Posted 12-24-2024 03:19

    Hi Flashover_

    Thank you for your interest in my case.
    I apologize for misleading you.
    Typos in the configuration are related to the fact that I initially configured 2 NG-MVPN.
    Now only one routing-instance is configured in the test network - MVPN.

    Here is the diagram of test network. It should be clearer. MXs' configs are attached.

    Test network
    The multicast source is connected to MX-1 directly. There are no protocols between Ubuntu-1 and MX-1.
    MX-1 advertises the source route using BGP inet/mvpn.
    MX-2 does not import routes from MVPN.inet.0 to MVPN.inet.2, neither by itself nor via rib-groups. And that's the question - why?
    PIM only works between MX-2 and ASR1001. The fact that it checks RPF in MVPN.inet.0 is quite sufficient and suits me :)

    Adding rib-group to PIM in MVPN as you advise causes Ubuntu-2 and ASR1001 to stop receiving multicst at all.

    I found a workaround, but I think it's ugly. I configured a static route in MVPN.inet.2 table. But it works:

    mpaul@MX-2> show configuration routing-instances MVPN routing-options rib MVPN.inet.2 
static {
    route 1.0.10.0/24 {
        discard;
        metric 100;
    }
}

    Both receivers got mutlicast.

    Here are some outputs 

    From MX-1

    mpaul@MX-1> show pim join instance MVPN 
Instance: PIM.MVPN Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 233.1.1.2
    Source: 1.0.10.10
    Flags: sparse,spt
    Upstream interface: xe-0/1/1.10           

Instance: PIM.MVPN Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

mpaul@MX-1> show multicast route instance MVPN 
Instance: MVPN Family: INET

Group: 233.1.1.2
    Source: 1.0.10.10/32
    Upstream interface: xe-0/1/1.10
    Downstream interface list: 
        xe-0/1/0.0
    

Instance: MVPN Family: INET6

    From MX-2

    mpaul@MX-2> show pim join instance MVPN 
Instance: PIM.MVPN Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 233.1.1.2
    Source: 1.0.10.10
    Flags: sparse,spt
    Upstream protocol: BGP
    Upstream interface: Through BGP           

Instance: PIM.MVPN Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

mpaul@MX-2> show multicast route instance MVPN  
Instance: MVPN Family: INET

Group: 233.1.1.2
    Source: 1.0.10.10/32
    Upstream interface: lsi.4
    Downstream interface list: 
        xe-0/1/2.0
    

Instance: MVPN Family: INET6

mpaul@MX-2> show route advertising-protocol pro
                                               ^
syntax error, expecting <attribute-name>, <flag-value>, or <attribute-value>.
mpaul@MX-2> show route advertising-protocol msdp 3.0.0.10 

MVPN.inet.4: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

233.1.1.2,1.0.10.10/64*[MSDP/175/2] 00:00:04, from 100.0.0.3
                       Local

mpaul@MX-2> show route advertising-protocol bgp 3.0.0.10     

MVPN.inet.2: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 1.0.10.0/24             Self                 100                I
* 2.0.0.0/24              Self                                    I
* 3.0.0.0/24              Self                                    I
* 100.0.0.3/32            Self                                    I

mpaul@MX-2> show route table MVPN    

MVPN.inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.10.0/24        *[BGP/170] 4d 15:52:13, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
2.0.0.0/24         *[Direct/0] 4d 15:52:12
                    >  via xe-0/1/1.0
2.0.0.1/32         *[Local/0] 4d 15:52:12
                       Local via xe-0/1/1.0
3.0.0.0/24         *[Direct/0] 3d 16:54:58
                    >  via xe-0/1/2.0
3.0.0.1/32         *[Local/0] 3d 16:54:58
                       Local via xe-0/1/2.0
100.0.0.3/32       *[Direct/0] 4d 15:52:12
                    >  via lo0.100
                    [BGP/170] 4d 15:52:13, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
224.0.0.2/32       *[PIM/0] 4d 15:52:13
                       MultiRecv
224.0.0.13/32      *[PIM/0] 4d 15:52:13
                       MultiRecv
224.0.0.22/32      *[IGMP/0] 4d 15:52:12
                       MultiRecv

MVPN.inet.1: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

224.0.0.0/4        *[Multicast/180] 4d 15:52:13
                       MultiResolve
224.0.0.0/24       *[Multicast/180] 4d 15:52:13
                       MultiDiscard
232.0.0.0/8        *[Multicast/180] 4d 15:52:13
                       MultiResolve
233.0.0.0/8        *[Multicast/180] 4d 15:52:13
                       MultiResolve
233.1.1.2,1.0.10.10/64*[MVPN/70] 00:15:01
                       Multicast (IPv4) Composite
                    [PIM/105] 00:28:27
                       Multicast (IPv4) Composite

MVPN.inet.2: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.10.0/24        *[Static/5] 4d 15:00:59, metric 100
                       Discard
2.0.0.0/24         *[Direct/0] 4d 14:58:37
                    >  via xe-0/1/1.0
2.0.0.1/32         *[Local/0] 4d 14:58:37
                       Local via xe-0/1/1.0
3.0.0.0/24         *[Direct/0] 3d 16:54:58
                    >  via xe-0/1/2.0
3.0.0.1/32         *[Local/0] 3d 16:54:58
                       Local via xe-0/1/2.0
3.100.0.1/32       *[BGP/170] 3d 16:54:52, MED 0, localpref 100
                      AS path: 100 ?, validation-state: unverified
                    >  to 3.0.0.10 via xe-0/1/2.0
100.0.0.3/32       *[Direct/0] 4d 14:58:37
                    >  via lo0.100

MVPN.inet.4: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

233.1.1.2,1.0.10.10/64*[MSDP/175/2] 00:00:49, from 100.0.0.3
                       Local

MVPN.mvpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1:192.168.0.3:10:192.168.0.3/240               
                   *[BGP/170] 3d 19:20:42, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
1:192.168.0.4:10:192.168.0.4/240               
                   *[MVPN/70] 4d 15:52:13, metric2 1
                       Indirect
5:192.168.0.3:10:32:1.0.10.10:32:233.1.1.2/240               
                   *[BGP/170] 00:59:01, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
7:192.168.0.3:10:65000:32:1.0.10.10:32:233.1.1.2/240               
                   *[PIM/105] 00:15:01, metric 0
                       Multicast (IPv4) Composite


mpaul@MX-2>

    So  I still dont know how to get it work...



    ------------------------------
    Paul Muller
    ------------------------------

    Attachment(s)

    txt
    MX-2_cfg.txt   6 KB 1 version
    txt
    MX-1_cfg.txt   5 KB 1 version
    Original Message


  • 4.  RE: BGP inet/multicast in routing instance

    Posted 12-24-2024 13:19
    Edited by Flashover_ 12-24-2024 13:22

    Hi Paul,

    Thank you for the update!

    • Here is the diagram of test network. It should be clearer. MXs' configs are attached.

    Aaah perfect, that helps quite a bit for me! I thought you had another router (example: ASR1001) connected with eBGP behind MX-1 there too, and the source behind it.

    In this case what you can do is create a RIB-Group to copy the interface routes (Direct=1.0.10.0/24) from MVPN.inet.0 to MVPN.inet.2:

    set routing-options rib-groups MVPN_INTERFACES_TO_INET_2 import-rib [ MVPN.inet.0 MVPN.inet.2 ]

    And apply it:

    set routing-instances MVPN routing-options interface-routes rib-group MVPN_INTERFACES_TO_INET_2

    (I hope my syntax is correct)

    Then you should be able to see the route in the table on MX-1:

    show route table MVPN.inet.2 1.0.10.1/24
#or both RIBs:
show route table MVPN.inet. 1.0.10.1/24

    It should now also be advertised to MX-2:

    show route advertising-protocol bgp 192.168.0.4

    And it should be in the table there to:

    show route table MVPN.inet.2 1.0.10.1/24
#or both RIBs:
show route table MVPN.inet. 1.0.10.1/24

    On MX-1 it should be protocol Direct.

    On MX-2 it should be protocol BGP.

    Don't forget to remove the static route in inet.2 on MX-2 !! :)

    • PIM only works between MX-2 and ASR1001. The fact that it checks RPF in MVPN.inet.0 is quite sufficient and suits me :)

    Is there a hard requirement for the ASR1001 to receive it via that BGP family? Because practically it is not a necessity for PIM/MSDP/MVPN to work. They just need a route.

    From what I know it's only really needed to do if you have a multi-homed setup and want a "non congruent" topology which allows for traffic-management / traffic-engineering. So for example inter-AS multicast and you'd want to load-balance your unicast / multicast traffic over different ASBR devices and paths. Then at the start of a maintenance window you could apply AS-Path prepending or Local-Preferences to influence the unicast and/or multicast path-selection separately.

    Maybe in production it is a much larger setup and indeed multi-homed. But in your current setup you don't have that. So if that remains true then we've found a solution for something we don't need anymore (all resolution via inet.2) LOL :)

    • Adding rib-group to PIM in MVPN as you advise causes Ubuntu-2 and ASR1001 to stop receiving multicst at all.

    Yes that makes sense, I assumed the issue was the missing [inet-vpn multicast] route. I wasn't expecting a directly connected source on MX-1. It should be (fingers crossed...) fixed with the [interface-routes] rib-group.

    Another potential alternative if you did have an external router behind MX-1 with eBGP and they only support SAFI unicast, then you could apply a RIB-Group on the BGP neighbor to copy the route to inet.2 table:

    #BGP:
set group <group_name> family inet unicast rib-group <rib-group>
set group <group_name> neighbor <address> family inet unicast rib-group <rib-group>

    So now I think we've fixed the signalling part for the source route. I hope the MVPN works with resolution via the [inet.2] table, I've actually never done that before.

    Keep me posted.


    Original Message


  • 5.  RE: BGP inet/multicast in routing instance

    Posted 12-25-2024 08:27

    Yes! It's alive!
    SAFI multicast in global BGP and "routing-options interface-routes" in MVPN solved the problem.

    How could I forget about it?

    On this small test net I check a real case. The customer is a provider that already has a configured multicast network and does not want to change the interaction scheme with external sources.
    That is why the requirement MSDP+mBGP is mandatory.

    Thank you very much Flashover_



    ------------------------------
    Paul Muller
    ------------------------------

    Original Message


  • 6.  RE: BGP inet/multicast in routing instance

    Posted 12-25-2024 09:00
    Edited by Flashover_ 12-27-2024 10:57

    Good to hear it works!! :)

    Thank you for the background story about the requirements for this with the external customer/provider.

    I do have to say, in a weird way, just putting the static route in MVPN.inet.2 on MX-2 would be fine I guess. It would save you from going through the troubles (if you have a bigger network) of adding [inet-vpn multicast] everywhere and flapping route-reflector BGP sessions...?

    Could I ask for another two small tests before we conclude the case? 

    First test:

    Can you check what happens if the unicast route 1.0.10.0/24 does not exist anymore in MVPN.inet.0 on router MX-2? Then we're relying exclusively on the route in MVPN.inet.2 .

    RFC6514 actually discusses such "non congruent" topology in chapter 10 : https://www.rfc-editor.org/rfc/rfc6514.html#section-10

    So we'd need to find a way to block the import of that route:

    • specific VRF-import policy on MX-2 for that prefix with a REJECT action (don't put a Reject-all type policy there, it will break MVPN functionality)
    • or put a 1.0.10.10/32 static-discard route in RIB MVPN.inet.0
    • inet.2 table should have the /24 prefix

    Second test:

    The MVPN is probably very dependent on this part of configuration:

    set routing-instances MVPN protocols pim rib-group RG_PIM_IMPORT_MVPN-1_INET_2

    Can you confirm you still have this part in the configuration and that the stream stops once that PIM rib-group statement is removed?

    Just want to avoid the situation where MVPN ignores the extra routes in MVPN.inet.2 while PIM does indeed look there.

    I'd like to hear those results!


    Original Message


  • 7.  RE: BGP inet/multicast in routing instance

    Posted 12-27-2024 10:13

    Hi Flashover !

    I'll do these tests and post results here.

    But bit later. I'm on vacation.

    And thanks again.



    ------------------------------
    Paul Muller
    ------------------------------

    Original Message


  • 8.  RE: BGP inet/multicast in routing instance

    Posted 01-20-2025 08:55

    Hi Flashover_

    Let's start with the second test.
    For clarity I'm using configuration(*):

    set routing-options rib-groups MVPN_INTERFACES_TO_INET_2 import-rib MVPN.inet.0
set routing-options rib-groups MVPN_INTERFACES_TO_INET_2 import-rib MVPN.inet.2
set routing-instances MVPN routing-options interface-routes rib-group inet MVPN_INTERFACES_TO_INET_2

    only on MX-1. Rib groups for PIM are not used anywhere.

    And yes, removing the configuration (*) from the MX-1 stops sending multicast towards the ASR1001. Namely, mBGP source announcements to the ASR1001 will disappear.

    First test.
    I haven't found a way to filter the BGP_route of inet-vpn unicast. 
    This configuration

    set policy-options policy-statement MVPN-IMPORT term a from community MVPN_COMMUNITY
set policy-options policy-statement MVPN-IMPORT term a from route-filter 1.0.10.0/24 orlonger
set policy-options policy-statement MVPN-IMPORT term a then reject
set policy-options policy-statement MVPN-IMPORT term b from community MVPN_COMMUNITY
set policy-options policy-statement MVPN-IMPORT term b then accept
set policy-options policy-statement MVPN-IMPORT term c then reject

set routing-instances MVPN vrf-import MVPN-IMPORT

    filters routes in both MVPN.inet.0 and MVPN.inet.2

    But setting a static route in MVPN.inet.0 on MX-2

    set routing-instances MVPN routing-options static route 1.0.10.10/32 discard

    breaks the multicast to both receivers.



    ------------------------------
    Paul Muller
    ------------------------------

    Original Message


  • 9.  RE: BGP inet/multicast in routing instance

    Posted 01-20-2025 11:53

    Hi Paul,

    Thank you for testing, I wonder, if you can do the following couple commands:

    delete routing-instances MVPN vrf-import MVPN-IMPORT
set routing-instances MVPN routing-options static route 1.0.10.10/32 discard
set routing-instances MVPN protocols pim rib-groups inet MVPN_INTERFACES_TO_INET_2

    Does it then work again?

    The problem with the "term c" in your config is that any auto-generated MVPN policies (by JunOS, for protocol mvpn!) are also rejected in the policy chain. I don't know if that's causing problems now but they shouldn't be filtered out. You can see those policies with "show policy" in operational mode or probably also with "show route instance MVPN extensive".

    The selection for specific routes when filtering in the policy can maybe be done with "rib $name" and/or "family", I wish I could test along in my own lab but it's currently not set up for this.

    The static-route method should be ok for our test! Hope you can find the time to test this, I should have provided you the exact configuration as my help there. 

    Cheers!


    Original Message


  • 10.  RE: BGP inet/multicast in routing instance

    Posted 01-23-2025 02:37

    Hi Flashover_

    I have applied your configurations.
    Final configuration on MX-1:

    mpaul@MX-1# show routing-instances MVPN | display set 
set routing-instances MVPN instance-type vrf
set routing-instances MVPN routing-options interface-routes rib-group inet MVPN_INTERFACES_TO_INET_2
set routing-instances MVPN routing-options static route 1.0.10.10/32 discard
set routing-instances MVPN protocols bgp group CE type external
set routing-instances MVPN protocols bgp group CE family inet unicast
set routing-instances MVPN protocols bgp group CE family inet multicast
set routing-instances MVPN protocols bgp group CE neighbor 3.0.0.10 export ANY
set routing-instances MVPN protocols bgp group CE neighbor 3.0.0.10 peer-as 100
set routing-instances MVPN protocols msdp group CE local-address 3.0.0.1
set routing-instances MVPN protocols msdp group CE peer 3.0.0.10
set routing-instances MVPN protocols mvpn mvpn-mode spt-only convert-sa-to-msdp
set routing-instances MVPN protocols pim rib-group inet MVPN_INTERFACES_TO_INET_2
set routing-instances MVPN protocols pim rp local address 100.0.0.3
set routing-instances MVPN protocols pim rp local group-ranges 233.0.0.0/8
set routing-instances MVPN protocols pim interface xe-0/1/1.10
set routing-instances MVPN protocols pim interface all
set routing-instances MVPN interface xe-0/1/1.10
set routing-instances MVPN interface xe-0/1/2.0
set routing-instances MVPN interface lo0.100
set routing-instances MVPN route-distinguisher 192.168.0.3:10
set routing-instances MVPN vrf-target target:65000:10
set routing-instances MVPN vrf-table-label
set routing-instances MVPN provider-tunnel rsvp-te label-switched-path-template default-template


mpaul@MX-1# show routing-options rib-groups | display set 
set routing-options rib-groups MVPN_INTERFACES_TO_INET_2 import-rib MVPN.inet.0
set routing-options rib-groups MVPN_INTERFACES_TO_INET_2 import-rib MVPN.inet.2

    Multicast has stopped for all recipients.

    It is strange that the route 1.0.10.10/32 was not imported into MVPN.inet.2

    Here are routing tables on all routers:

    • MX-1
    mpaul@MX-1> show route table MVPN.inet.0   

MVPN.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.10.0/24        *[Direct/0] 2d 20:15:20
                    >  via xe-0/1/1.10
1.0.10.1/32        *[Local/0] 2d 20:15:20
                       Local via xe-0/1/1.10
1.0.10.10/32       *[Static/5] 01:17:03
                       Discard
2.0.0.0/24         *[BGP/170] 2d 20:03:21, localpref 100, from 192.168.0.4
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.1 via xe-0/1/0.0, label-switched-path r3-r4
3.0.0.0/24         *[BGP/170] 2d 20:03:21, localpref 100, from 192.168.0.4
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.1 via xe-0/1/0.0, label-switched-path r3-r4
3.0.0.1/32         *[Local/0] 2d 20:15:42
                       Reject
100.0.0.3/32       *[Direct/0] 2d 20:18:30
                    >  via lo0.100
                    [BGP/170] 2d 20:03:21, localpref 100, from 192.168.0.4
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.1 via xe-0/1/0.0, label-switched-path r3-r4
224.0.0.2/32       *[PIM/0] 2d 20:18:30
                       MultiRecv
224.0.0.13/32      *[PIM/0] 2d 20:18:30
                       MultiRecv
224.0.0.22/32      *[IGMP/0] 2d 20:15:20
                       MultiRecv

mpaul@MX-1> show route table MVPN.inet.2    

MVPN.inet.2: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.10.0/24        *[Direct/0] 2d 18:52:40
                    >  via xe-0/1/1.10
1.0.10.1/32        *[Local/0] 2d 18:52:40
                       Local via xe-0/1/1.10
3.0.0.1/32         *[Local/0] 2d 18:52:40
                       Reject
3.100.0.1/32       *[BGP/170] 2d 20:03:23, MED 0, localpref 100, from 192.168.0.4
                      AS path: 100 ?, validation-state: unverified
                    >  to 10.0.0.1 via xe-0/1/0.0, label-switched-path r3-r4
100.0.0.3/32       *[Direct/0] 2d 18:52:40
                    >  via lo0.100
    • MX-2
    mpaul@MX-2> show route table MVPN.inet.0 

MVPN.inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.10.0/24        *[BGP/170] 2d 18:35:21, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
1.0.10.10/32       *[BGP/170] 01:17:33, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
2.0.0.0/24         *[Direct/0] 2d 20:04:22
                    >  via xe-0/1/1.0
2.0.0.1/32         *[Local/0] 2d 20:04:22
                       Local via xe-0/1/1.0
3.0.0.0/24         *[Direct/0] 2d 20:04:21
                    >  via xe-0/1/2.0
3.0.0.1/32         *[Local/0] 2d 20:04:21
                       Local via xe-0/1/2.0
100.0.0.3/32       *[Direct/0] 2d 20:07:29
                    >  via lo0.100
                    [BGP/170] 2d 20:03:45, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
224.0.0.2/32       *[PIM/0] 2d 20:07:29
                       MultiRecv
224.0.0.13/32      *[PIM/0] 2d 20:07:29
                       MultiRecv
224.0.0.22/32      *[IGMP/0] 2d 20:04:22
                       MultiRecv

mpaul@MX-2> show route table MVPN.inet.2    

MVPN.inet.2: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.0.10.0/24        *[BGP/170] 2d 18:35:24, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
3.100.0.1/32       *[BGP/170] 2d 20:04:18, MED 0, localpref 100
                      AS path: 100 ?, validation-state: unverified
                    >  to 3.0.0.10 via xe-0/1/2.0
100.0.0.3/32       *[BGP/170] 2d 18:53:05, localpref 100, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    >  to 10.0.0.0 via xe-0/1/0.0, label-switched-path r4-r3
    • ASR1001
    ASR1001-LAB#sh bgp all     
For address family: IPv4 Unicast


For address family: VPNv4 Unicast


For address family: IPv4 Multicast


For address family: L2VPN E-VPN


For address family: VPNv4 Multicast

BGP table version is 50, local router ID is 3.100.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf MCast)
 *>   1.0.10.0/24      3.0.0.1                                0 65000 i
 *>   3.100.0.1/32     0.0.0.0                  0         32768 ?
 *>   100.0.0.3/32     3.0.0.1                                0 65000 i

For address family: MVPNv4 Unicast


For address family: VPNv4 Flowspec


    ------------------------------
    Paul Muller
    ------------------------------

    Original Message


  • 11.  RE: BGP inet/multicast in routing instance

    Posted 01-28-2025 17:34
    Edited by Flashover_ 01-28-2025 17:42

    Hi Paul,

    Thank you for continuing this extra testing with me!! :)

    You wrote:

    • I have applied your configurations.
    • Multicast has stopped for all recipients.

    Ok well that's not what I was hoping for... I think it tells me the PIM is looking at the "vpn.inet.2" but protocol-MVPN isn't...

    In your case I guess it shouldn't be a problem as your usecase has already been resolved but just for my extra testing it is applicable to a multi-homed setup and yours is single-homed so it's shouldn't be an issue for your setup.

    • It is strange that the route 1.0.10.10/32 was not imported into MVPN.inet.2

    That's expected for me as the RIB group is only applied to "interface-routes" (but not to the "static route") level in config with this line:

    set routing-instances MVPN routing-options interface-routes rib-group inet MVPN_INTERFACES_TO_INET_2

    I was really interested in having the /32-discard route only in inet.0 so the routing-tables look good indeed!!

    I see in your configuration this line:

    set routing-instances MVPN protocols pim rib-group inet MVPN_INTERFACES_TO_INET_2

    Could it be replaced with to the following on PE1 and PE2:

    delete routing-instances MVPN protocols pim rib-group inet MVPN_INTERFACES_TO_INET_2
set routing-options rib-groups PIM_INET_2 import-rib MVPN.inet.2
set routing-instances MVPN protocols pim rib-group inet PIM_INET_2

    (I see I suggest and made that error in my post #9 about 8 days ago...)

    Could you retest again at this point in the post?

    To potentially solve the MVPN issue, please keep the /32-discard in inet.0 and let's work on protocol-MVPN using the inet.2 (as PIM already does it). There's one idea I have, if it doesn't work then we'll probably need to close this case :)

    Could you try this line (please only apply it in lab!):

    set routing-options resolution rib MVPN.mvpn.0 resolution-ribs MVPN.inet.2

    Before+after applying it check the following command and collect output:

    https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-route-resolution.html

    show route resolution table MVPN.mvpn.0

    Maybe there will be a commit error... 

    Could you retest again at this point in the post?

    I guess I should find a way to test this in my lab...

    Cheers


    Original Message


  • 12.  RE: BGP inet/multicast in routing instance

    This message was posted by a user wishing to remain anonymous
    Posted 01-22-2025 16:49
    This message was posted by a user wishing to remain anonymous

    Excellent thread!  I'm working on qualifying a 30 node backbone solution with MX480s to do NG-MVPN for a customer at all sites in CONUS.  MSDP in 6 geographically diverse regions. Paul, you're using some interesting knobs and options to consider.  Flashover, your feedback on optimal implementation and detailed MCAST VPN processing is excellent.  Thank you both!!


    Original Message


  • 13.  RE: BGP inet/multicast in routing instance

    Posted 01-28-2025 17:36
     
    Hello Anonymous user, 
     
    Happy to help, excellent thread indeed! :)
     
    30 nodes is quite a bit, can you tell maybe a bit more? What is the type of multicast traffic? IPTV, stock market, or otherwise? How many groups/traffic is involved there if I may ask?

    Original Message