Hi Paul,

On Mon, Sep 12, 2016 at 12:06 PM, Paul S. <cont...@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to