[j-nsp] Design assistance with routing instances
Stefan Stoyanov
sonyxwing at gmail.com
Wed Sep 21 00:39:34 EDT 2016
Hi Paul,
On Mon, Sep 12, 2016 at 12:06 PM, Paul S. <contact at winterei.se> wrote:
> Hi folks,
>
> Dealing with some rather interesting design issues lately.
>
> The main issue is that we have to partition the global table to provide
> "selective access" (mainly due to massive cost disparity based on where
> traffic goes, this is in Asia) to customers as they want. Prefer to do it
> within a single MX router with routing instances.
>
> Usual criterion is like Global / Global + Local / Local Only and so on.
>
> The issue here is that if I replicate the global table to a
> routing-instance FIB, I basically end up with 1.3m routes there and this
> doesn't seem very future proof.
>
> With that in mind, I guess I'd love some input on:
>
> 1. Should I keep all upstream links on the default routing instance and
> only leak to the target vrfs? Or is putting upstreams that only serve
> specific purposes inside specific routing instances a better solution idea?
>
from the experience which I have, it will be better to put each upstream on
a separate instance.
>
> 2. On the topic of route leaking, are rib groups preferred, or real bgp
> sessions over the lt interface? I'd like the ability to announce things to
> "all upstreams" from the router itself.
>
RIB groups are prefered, becuase of speed restriction which you have on lt
interface.
>
> We plan to develop a backbone network with MPLS-TE for L{2|3}VPN services
> at a later date too, so the design shouldn't cause any interoperability
> issues.
>
> Any input on architecting this is welcome, thank you for reading!
>
>
> _______________________________________________
> 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