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

2016-10-18 Thread Dragan Jovicic 
Awesome ! :)

Best
Dragan

On Mon, Oct 17, 2016 at 5:43 PM, Paul S.  wrote:

> Hi Dragan,
>
> That worked, actually. Many thanks!
>
> As to the lt interface, will read up as suggested.
>
>
> On 10/17/2016 03:18 AM, Dragan Jovicic wrote:
>
> 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
> ""
> 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.  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@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

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

2016-10-17 Thread Paul S. 

Hi Dragan,

That worked, actually. Many thanks!

As to the lt interface, will read up as suggested.

On 10/17/2016 03:18 AM, Dragan Jovicic wrote:
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 
""

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. > 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@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

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

2016-10-16 Thread 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 ""
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.  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@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

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

2016-10-16 Thread Paul S. 

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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp