[j-nsp] Next Gen MVPN flooding assistance

Chris Evans chrisccnpspam2 at gmail.com
Wed Sep 21 07:35:55 EDT 2011


After finding the bug below I upgraded code and tried to test it again, this
is why the threshold wasn't working to trigger S-PMSI. I was running 11.2R1,
but moved to 11.2R2 and it seems to be working sporadically. Currently right
now it takess about 6 minutes for the Selective tunnel to kick in. I don't
believe that is the right behavior. The documentation doesn't mention about
how/when it should work. I'm curious if anyone else knows?



https://www2.juniper.net/prsearch/viewpr.jsp?txtPrnumber=607563




On Tue, Sep 20, 2011 at 1:03 PM, Mark Tinka <mtinka at globaltransit.net>wrote:

> On Wednesday, September 21, 2011 12:48:21 AM Stefan Fouant
> wrote:
>
> > Just out of curiousity, since I am always eager to learn
> > how people are deploying this in the real-world - do you
> > have multiple ingress nodes streaming the same content
> > and use diverse P2MP LSPs to your head-ends a-la
> > "live-live" or some other approach for ensuring
> > redundant data?
>
> For redundancy, we do have multiple ingress points streaming
> the same content, but we're always choosing one source at a
> time, as it would be too complex to try and take live
> streams from all sources at the same time just by IP routing
> alone.
>
> In this case, a particular Sender PE router is chosen to
> ingress Multicast data for the network based on the
> LOCAL_PREF value of the BGP route toward (C-S). Every Sender
> PE router applies a BGP LOCAL_PREF value to the (C-S) route
> in a "3, 2, 1" type order. So basically, a live/standby
> approach.
>
> This is the simplest approach we could take prior to the
> protocol introducing support for 'draft-morin-l3vpn-mvpn-
> fast-failover-05'.
>
> Cheers,
>
> Mark.
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


More information about the juniper-nsp mailing list