[c-nsp] [j-nsp] L3VPN/RR/PE on Same router

Robert Raszuk robert at raszuk.net
Fri Aug 17 04:56:52 EDT 2018


Hey Mark,

It has been a while ....

> We've been running all address families on the same RR's (different
> sessions, obviously, but same hardware)

Out of pure curiosity how are you setting up different BGP sessions to the
same RR ?

I think what Adam is proposing is real TCP session isolation, what you may
be doing is just same single TCP session, but different SAFIs which is not
the same.

Sure you can configure parallel iBGP sessions on the TCP level say between
different loopback addresses to the same RR, but what would that really buy
you ? You could even be more brave and use BGP multisession code path (if
happens to be even supported by your vendor) which in most implementations
I have seen is full of holes like swiss cheese but is this what you are
doing ?

Cheers,
R,.

PS.  Have not been reading -nsp aliases for a while, but now I see that I
missed a lot !  Btw do we really need per vendor aliases here ? Wouldn't it
be much easier to just have single nsp list ? After all we all most likely
have all of the vendors in our networks (including Nokia !) and we are all
likely reading all the lists :) Or maybe there is one already ?


On Fri, Aug 17, 2018 at 7:06 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 16/Aug/18 17:15, adamv0025 at netconsultings.com wrote:
>
> > Yes a good practice is to separate internet routes from internal/services
> > l3vpn routes onto separate BGP control planes (different sessions at
> least)
> > so that malformed bgp msg will affect just one part of your overall BGP
> > infrastructure.
>
> I see you've been giving this advice for quite some time now.
>
> We've been running all address families on the same RR's (different
> sessions, obviously, but same hardware) for almost 5 years. The only
> reason sessions have gone down is due to hardware problems. It didn't
> disrupt services because there are always 2 RR's, but we haven't seen an
> outage due to protocol problems in one address family spilling over into
> other address families.
>
> Of course, I see your concern, but from our own experience over several
> years, I've not seen this issue.
>
> I mention this because introducing this kind of separation is onerous.
>
> Mark.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


More information about the cisco-nsp mailing list