[j-nsp] AS path preservation when importing from instance.inet.0 to inet.0

[Dragan Jovicic]

You could try import-rib policy, where you match on bgp routes and as-path
prepend, something like this:
set routing-options rib-groups rib-1 import-policy pl-1
set policy-options policy-statement pl-1 term 10 from proto bgp
set policy-options policy-statement pl-1 term 10 then as-path-prepend "XXXX"
set policy-options policy-statement pl-1 term 10 then accept

Try and let me know please.

[quote]
Speaking of the lt tunnel, is there any clear drawbacks to using it? Once
upon a time, I recall hearing that it was bandwidth constrained. I'm doing
this on a Trio MX.
[/quote]

There is a bandwidth limitation, check out docs. As for when to use it,
depends...

Best

Dragan



On Sun, Oct 16, 2016 at 6:05 PM, Paul S. <contact at winterei.se> wrote:

> Hi guys,
>
> So, in a bit of a peculiar situation. I think rather than explaining it,
> it's possibly easier to express through configs. I've added it at the end
> of the email.
>
> Basically, my local-as in a ri is different compared to my local-as set in
> the master instance. When I import a BGP route (that I'm actually
> originating in the RI and would like to originate in the master instance
> too), and then export it to other peers -- the originating ASN gets
> rewritten to the master instance's ASN instead.
>
> For example - AS-path in RI A for 20.20.20.0/24 is [2] I
>
> When imported via instance-import to inet.0 and exported to other peers, I
> can see that the AS-path becomes [1] I. What I'd like it to be is [1 2] I,
> i.e: the RI looks like a downstream adjacency of the master instance
> instead.
>
> Is there any way to achieve this (other than setting up a lt tunnel and
> peering with the master)? Speaking of the lt tunnel, is there any clear
> drawbacks to using it? Once upon a time, I recall hearing that it was
> bandwidth constrained. I'm doing this on a Trio MX.
>
> Pointers welcome, thank you for reading.
>
> (As to why the multi-asn stupidity, that's due to a limitation on our
> upstream provider's side. Sadly, no control over that)
>
>
> Config from the "*master*" instance:
>
>
> routing-options {
>
>     router-id 1.1.1.1;
>
>    autonomous-system 1;
>
> }
>
> protocols
>
> {
>
>     bgp {
>
>        nei 10.10.10.10 peer-as 500;
>
>    }
>
> }
>
>
> Config from a *second* routing-instance
>
> A {
>
>     instance-type virtual-router;
>
>     interface x;
>
>     routing-options {
>
>         router-id 2.2.2.2;
>
>     }
>
>     protocols { bgp {
>
>         nei 10.10.10.15 peer-as 500;
>
>         nei 10.10.10.15 local-as *2;*
>
>      }
>
> }
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>