[j-nsp] self-pointing route resolution: static vs. bgp ?

[Alexandre Snarskii]

Hi!

Imagine there is a directly connected network: 

A.B.C.40/29   *[Direct/0] 41w1d 00:10:40
> via xe-0/0/2.232

There is a good old trick: you can configure 'self-pointing'
host route with next-hop within this network: 

snar@router> show configuration routing-options static route A.B.C.43/32
   
next-hop A.B.C.43;

it will be accepted, resolved and installed into routing table:

snar@router> show route A.B.C.43/32 detail 

A.B.C.43/32 (1 entry, 1 announced)
State: 
*Static Preference: 5
Next hop type: Router, Next hop index: 1256
Address: 0x21a45c90
Next-hop reference count: 5
Next hop: A.B.C.43 via xe-0/0/2.232, selected

(this trick was used before introduction vrf-table-label to install 
host routes in vrf's for customers who did not wanted to install CPE).

However, when such self-pointing route is received over iBGP 

snar@router> show route A.B.C.42/32 receive-protocol bgp ...

  A.B.C.42/32 (1 entry, 0 announced)
 Accepted
 Nexthop: A.B.C.42
 MED: 100
 Localpref: 20
 AS path: I

it becomes hidden with Unusable next-hop

snar@router> show route A.B.C.42/32 hidden detail 

A.B.C.42/32 (1 entry, 0 announced)
 BGPPreference: 170/-21
Next hop type: Unusable
Address: 0x24e59bc
Next-hop reference count: 3
State: 
Accepted
Localpref: 15
Indirect next hops: 1
Protocol next hop: A.B.C.42
Indirect next hop: 0 - INH Session ID: 0x0


and not installed into forwarding table. Well, Juniper documentation
clearly says[1] that it will not accept route pointing to device itself,
but it is not the case, Local address is .41:

A.B.C.41/32   *[Local/0] 44w0d 23:41:25
  Local via xe-0/0/2.232


Question: are there any way to convince JunOS to resolve and install
such self-pointing route when received over iBGP ?  

12.3R5.7, MX80 if that matters.

[1]:
http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/hidden-routes-understanding.html
Routes can be hidden for the following reasons:
[...]
The next hop address is the address of the local routing device.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Phil Shafer]

Stepan Kucherenko writes:
>What else...oh, annotate ! It's clunky and not very easy to use.

Yes, annotate is a sore spot.  I made the grammar production:

K_ANNOTATE annotate_target T_STRING

with the expectation that I'd be able to coerce a path into the
target, but it didn't happen.  I should have done it as:

K_ANNOTATE T_STRING annotate_target

and then allow anything as a target, like:

cli# annotate "Client X" interfaces ge-0/0/0.0 family inet address 1.2.3.4/5

but can't make that work without making a new command ("comment"?).

>I wish we could just add a comment in the end of a line instead, like 
>"set interface ge-0/0/0.0 family inet address x.x.x.x/y //client X" and 
>then see "x.x.x.x/y //client X" and the same line when asking for 
>|display set.

We generate line comments in JUNOS, so we need to discard them (and
comments before close braces) to prevent out-of-date comments from
getting loaded as real annotations.

Hmm  I should make a M-, keybinding to copy all arguments from the
previous command so you can:

[edit interfaces ge-0/0/0 unit 0]
cli# set family inet address 1.2.3.4/5

[edit interfaces ge-0/0/0 unit 0]
cli# comment "Client X" [ESC-,]

and it will insert the "family inet address 1.2.3.4/5" from
the previous "set" command.

This is similar to the existing M-. and M-/ bindings.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Mark Tinka]

On 22/Oct/15 00:40, Chad Myers wrote:

>   And finally putting commas in the monitor interface traffic output.

Or just use the correct units of measurement, e.g., Kbps, Mbps, Gbps and
Tbps :-).

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Adam Vitkovsky]

Hi Jeff,

> Jeff Haas
> Sent: Wednesday, October 21, 2015 8:16 PM
>
>
> That said, we are preserving the One JUNOS paradigm.  Even if we did go
> multi-process with disjoint protocol implementation (that's not what we're
> doing),
>

Can you expand on this please?
I thought that's the plan to separate routing protocols to separate processes 
or is this concerning only BGP?
Thank you.

adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Mark Tinka]

On 22/Oct/15 09:12, Raphael Mazelier wrote:

>
>  
> +1. When I begin to use Junos I was really surprised/frustated that I
> couldn't use tag/communities on connected, which break the classic
> logic of redistributing route in junos. That said this is even worse
> on other network os.

In IOS and IOS XE, my annoyance is that you can't use a tag as a match
condition to export routes to BGP neighbors.

Not sure what the policy in IOS XR is.

For exporting Direct routes in Junos, we go the old-fashioned way; but
yes, being able to add tags to those would be great.

Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Adam Vitkovsky]

> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Thursday, October 22, 2015 11:54 AM
> On 22 October 2015 at 10:38, Adam Vitkovsky
>  wrote:
>
> Hey,
>
> > I thought that's the plan to separate routing protocols to separate
> processes or is this concerning only BGP?
>
> Not processes, threads, due to IPC concerns.
>
Hey,

I see, so no possibility to offload BGP to another node nor multi-chassis 
capability in Junos right?
With regards to IPC, there got to be some XR folks in Juniper so where's the 
holdup :)

adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Saku Ytti]

On 22 October 2015 at 14:31, Adam Vitkovsky  wrote:
> I see, so no possibility to offload BGP to another node nor multi-chassis 
> capability in Junos right?
> With regards to IPC, there got to be some XR folks in Juniper so where's the 
> holdup :)

IOS-XR seems to have fair share problems with the IPC :)

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Phil Mayers]

On 22/10/15 13:05, Saku Ytti wrote:

On 22 October 2015 at 14:31, Adam Vitkovsky  wrote:

I see, so no possibility to offload BGP to another node nor multi-chassis 
capability in Junos right?
With regards to IPC, there got to be some XR folks in Juniper so where's the 
holdup :)


IOS-XR seems to have fair share problems with the IPC :)



In fairness, concurrency is "teh hardz" on any platform, in any framework.

You can use threads and shared memory then problems two you have.

You can bodge it by serialising everything and pushing data between 
threads/processes with queues and using craploads of locking, but you 
typically want fast CPUs for that. Or you can cheat and coop multitask, 
but then you're back at IOS classic / JunOS rpd.


You can write it in a concurrent-friendly language like Erlang (or maybe 
Go) but then you have problem employing developers on the cheap, and 
have to discard your existing codebase (yikes!)


I'm sympathetic to Juniper/Cisco/etc. here - they've got huge codebases 
they can't afford to discard because of the years of accumulated 
real-world behavioural tweaks, but proper concurrency typically involves 
ground-up design principles.


It's not a solved problem yet :o(
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Saku Ytti]

On 22 October 2015 at 10:38, Adam Vitkovsky  wrote:

Hey,

> I thought that's the plan to separate routing protocols to separate processes 
> or is this concerning only BGP?

Not processes, threads, due to IPC concerns.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Saku Ytti]

On 22 October 2015 at 08:30, Bradley Gould
 wrote:

Hey,

> "routing-options interface-routes" already exists, so keeping commonality 
> with "routing-options static":
>
> set routing-options interface-routes family inet community [ 1:1 2:2 3:3 ]
> set routing-options interface-routes interface xe-1/2/3 family inet community 
> [ 1:1 2:2 4:4 ]
>
> I'd think you'd want an ability to set a "global" community set for all 
> interface routes and also be able to set them individually.

I don't see 'interface-routes interface X' in config?

http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/interface-routes-edit-routing-options.html


Even if this exits, it does not seem to give address granularity,
which is crucial point, so you can discriminate between two addresses.



-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Zaid Hammoudi]

On Thu, Oct 22, 2015 at 6:36 AM, Stepan Kucherenko  wrote:

> If we're speaking about "quality of life" stuff then I wish JunOS/FreeBSD
> traceroute would stop adding source routing bit when you include source
> interface/gateway/bypass-routing.
>

JUNOS currently uses a version of traceroute that is over 13 years old.
Apparently that's also what the latest version of FreeBSD uses too.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] self-pointing route resolution: static vs. bgp ?

[Adam Vitkovsky]

Hi Alexandre,

Hmmm looks like you are trying to accomplish something fishy here :) (probably 
involving loopback right?)
Can you please expand on what your end goal is please, there might be some 
other way to skin the cat.

adam

>

Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


-Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Alexandre Snarskii
> Sent: Thursday, October 22, 2015 6:30 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] self-pointing route resolution: static vs. bgp ?
>
>
> Hi!
>
> Imagine there is a directly connected network:
>
> A.B.C.40/29   *[Direct/0] 41w1d 00:10:40
> > via xe-0/0/2.232
>
> There is a good old trick: you can configure 'self-pointing'
> host route with next-hop within this network:
>
> snar@router> show configuration routing-options static route A.B.C.43/32
> next-hop A.B.C.43;
>
> it will be accepted, resolved and installed into routing table:
>
> snar@router> show route A.B.C.43/32 detail
>
> A.B.C.43/32 (1 entry, 1 announced)
> State: 
> *Static Preference: 5
> Next hop type: Router, Next hop index: 1256
> Address: 0x21a45c90
> Next-hop reference count: 5
> Next hop: A.B.C.43 via xe-0/0/2.232, selected
>
> (this trick was used before introduction vrf-table-label to install host 
> routes in
> vrf's for customers who did not wanted to install CPE).
>
> However, when such self-pointing route is received over iBGP
>
> snar@router> show route A.B.C.42/32 receive-protocol bgp ...
>
>   A.B.C.42/32 (1 entry, 0 announced)
>  Accepted
>  Nexthop: A.B.C.42
>  MED: 100
>  Localpref: 20
>  AS path: I
>
> it becomes hidden with Unusable next-hop
>
> snar@router> show route A.B.C.42/32 hidden detail
>
> A.B.C.42/32 (1 entry, 0 announced)
>  BGPPreference: 170/-21
> Next hop type: Unusable
> Address: 0x24e59bc
> Next-hop reference count: 3
> State: 
> Accepted
> Localpref: 15
> Indirect next hops: 1
> Protocol next hop: A.B.C.42
> Indirect next hop: 0 - INH Session ID: 0x0
>
>
> and not installed into forwarding table. Well, Juniper documentation clearly
> says[1] that it will not accept route pointing to device itself, but it is 
> not the
> case, Local address is .41:
>
> A.B.C.41/32   *[Local/0] 44w0d 23:41:25
>   Local via xe-0/0/2.232
>
>
> Question: are there any way to convince JunOS to resolve and install such
> self-pointing route when received over iBGP ?
>
> 12.3R5.7, MX80 if that matters.
>
> [1]:
> http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/hidden
> -routes-understanding.html
> Routes can be hidden for the following reasons:
> [...]
> The next hop address is the address of the local routing device.
>
> ___
> 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] Multi Core on JUNOS?

[Raphael Mazelier]

In fairness, concurrency is "teh hardz" on any platform, in any framework.

You can use threads and shared memory then problems two you have.

You can bodge it by serialising everything and pushing data between
threads/processes with queues and using craploads of locking, but you
typically want fast CPUs for that. Or you can cheat and coop multitask,
but then you're back at IOS classic / JunOS rpd.

You can write it in a concurrent-friendly language like Erlang (or maybe
Go) but then you have problem employing developers on the cheap, and
have to discard your existing codebase (yikes!)

I'm sympathetic to Juniper/Cisco/etc. here - they've got huge codebases
they can't afford to discard because of the years of accumulated
real-world behavioural tweaks, but proper concurrency typically involves
ground-up design principles.

It's not a solved problem yet :o(


The approach to run rpd on one core, and other process on avaibles one 
is a quick win. And optimizing the actual code before thinking in 
paralelism may be a faster approach to make speed gain ?


I complelty agree that to make a good paralelized junos, major rewrite 
or complete rewrite must be engaged.


Btw Junos on intel RE is fast enough for me. But not all on other cpu, 
specially on EX/QFX one... Perhaps Juniper should install x86 cpu on 
switch too (other vendor do this).



--
Raphael Mazelier
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Phil Mayers]

On 22/10/15 15:06, Raphael Mazelier wrote:


The approach to run rpd on one core, and other process on avaibles one
is a quick win. And optimizing the actual code before thinking in
paralelism may be a faster approach to make speed gain ?


Sure, moving the rest of the OS onto other cores is a no-brainer; 
they're already crossing a process boundary.



Btw Junos on intel RE is fast enough for me. But not all on other cpu,
specially on EX/QFX one... Perhaps Juniper should install x86 cpu on
switch too (other vendor do this).


Better CPU choices would help a lot of devices ;o)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Phil Bedard]

Well you may see the ability to run the  Junos CP on more powerful external 
servers with virtualized hardware, I think a few vendors are working on those 
type of a solutions.  Juniper has done similar things in the past with 
multi-chassis.  

Phil

-Original Message-
From: "Adam Vitkovsky" 
Sent: ‎10/‎22/‎2015 7:31 AM
To: "Saku Ytti" 
Cc: "" 
Subject: Re: [j-nsp] Multi Core on JUNOS?

> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Thursday, October 22, 2015 11:54 AM
> On 22 October 2015 at 10:38, Adam Vitkovsky
>  wrote:
>
> Hey,
>
> > I thought that's the plan to separate routing protocols to separate
> processes or is this concerning only BGP?
>
> Not processes, threads, due to IPC concerns.
>
Hey,

I see, so no possibility to offload BGP to another node nor multi-chassis 
capability in Junos right?
With regards to IPC, there got to be some XR folks in Juniper so where's the 
holdup :)

adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
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] Multi Core on JUNOS?

[Doug McIntyre]

On Thu, Oct 22, 2015 at 08:51:10AM +0200, Mark Tinka wrote:
> On 22/Oct/15 00:40, Chad Myers wrote:
> 
> >   And finally putting commas in the monitor interface traffic output.
> 
> Or just use the correct units of measurement, e.g., Kbps, Mbps, Gbps and
> Tbps :-).

I so wish there was a '-h' flag to 'monitor interface' that did that..


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Stepan Kucherenko]

If we're speaking about "quality of life" stuff then I wish 
JunOS/FreeBSD traceroute would stop adding source routing bit when you 
include source interface/gateway/bypass-routing.


It's being filtered EVERYWHERE in real world so it's not possible to 
look at the second-best route via non-active path, it's either best 
route or guessing. Or maybe I'm missing something ?



Also fractional interval in traceroute monitor (=mtr), I always use -i 
0.1 or even less in real life for faster drop detection but can't do the 
same in Junos even if it's the same mtr.



What else...oh, annotate ! It's clunky and not very easy to use.

I wish we could just add a comment in the end of a line instead, like 
"set interface ge-0/0/0.0 family inet address x.x.x.x/y //client X" and 
then see "x.x.x.x/y //client X" and the same line when asking for 
|display set.



I'm sure you guys can add even more stuff like that. It's small but I 
think it's still important. And a low-hanging fruit in many cases :-)



On 22.10.2015 15:33, Doug McIntyre wrote:

On Thu, Oct 22, 2015 at 08:51:10AM +0200, Mark Tinka wrote:

On 22/Oct/15 00:40, Chad Myers wrote:


   And finally putting commas in the monitor interface traffic output.


Or just use the correct units of measurement, e.g., Kbps, Mbps, Gbps and
Tbps :-).


I so wish there was a '-h' flag to 'monitor interface' that did that..


___
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] Multi Core on JUNOS?

[Adam Vitkovsky]

> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Thursday, October 22, 2015 1:05 PM
>
> On 22 October 2015 at 14:31, Adam Vitkovsky
>  wrote:
> > I see, so no possibility to offload BGP to another node nor multi-chassis
> capability in Junos right?
> > With regards to IPC, there got to be some XR folks in Juniper so where's the
> holdup :)
>
> IOS-XR seems to have fair share problems with the IPC :)
>
Well I'm alright with that for as long as I can distribute BGP process suits to 
several nodes and unless it doesn't severely impact performance which I'm not 
aware of.


adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Raphael Mazelier]

Le 21/10/15 23:44, Chad Myers a écrit :

On Oct 21, 2015, at 3:58 PM, Tarko Tikan  wrote:


hey,


set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 tag Z
set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 community K


Thats what I had in mind as well.


I'm for that method as well.




+1. When I begin to use Junos I was really surprised/frustated that I 
couldn't use tag/communities on connected, which break the classic logic 
of redistributing route in junos. That said this is even worse on other 
network os.


--
Raphael Mazelier
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp