[j-nsp] EX4300 - Too many VLAN-IDs on interface

[Dan Peachey]

Hi,

I just hit an issue where I tried to configure 2000 VLAN's on a LAG and got
the error message "Too many VLAN-IDs on interface". If I remove the
interface from the LAG I am able to configure all the VLAN's without issue.
Based on the unit number that threw the error it seems like the number of
VLAN's configurable is limited to 1024.

The LAG had 2 member interfaces, each of which were on separate switches in
a VC stack (2 switches). Encapsulation on the LAG was
"extended-vlan-bridge".

Anyone else seen this? Is this a known limitation?

JunOS version is 13.2X51-D36.1.

Cheers,

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

[j-nsp] authentication failure in case of configuration archival over scp

[Martin T]

Hi,

I have a Juniper router(Junos 10.4R12.4) which should archive its
configuration over scp in case of commit:

configuration {
transfer-on-commit;
archive-sites {
"scp://juniper@backupserver:/home/juniper/configbackups"
password "$9$2joDkf5F9tOik0IhcMWGDjq5Q"; ## SECRET-DATA
}
}

In addition, it has SSH server public-key under "ssh-known-hosts".
This setup worked fine for a while, but all of the sudden router is no
longer able to scp its configuration to server. Router simply logs
that "transfer-file failed to transfer" and SSH server log tells that
"error: PAM: Authentication failure for juniper from r1". If I execute
scp from shell("start shell sh"), then there are no problems:

$ scp /var/transfer/config/r1_juniper.conf.gz_20151021_135546
juniper@backupserver:/home/juniper/configbackups
Password:
r1_juniper.conf.gz_20151021_135546


100%   64KB  64.4KB/s   00:00
$


What might cause this?


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

Re: [j-nsp] authentication failure in case of configuration archival over scp

[Stacy W. Smith]

> On Oct 21, 2015, at 10:16 AM, Martin T  wrote:
> 
> SSH server log tells that "error: PAM: Authentication failure for juniper 
> from r1".

> What might cause this?

Assuming the Junos version has not changed on the router, have there been any 
changes to the SSH server, or the OS, on backupserver (potentially including 
"security patches")?

Assuming OpenSSH, you may want to "man sshd_config" and look into the various 
Authentication settings as well as the UsePAM. I suspect some recent 
upgrade may have changed the default value of some of these settings.

I would normally suggest changing the client's config to interoperate with the 
server, but since that's not easy to do on a Junos device, you might look at 
changing the server config.

--Stacy

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

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

[Jeff Haas]

> On Oct 21, 2015, at 3:05 PM, Chad Myers  wrote:
> 
> Please don't go the IOS/EOS/non-Junos method for rpd where each protocol is 
> completely independent and isolated from the others.  It is extremely helpful 
> to be able to do things like put communities on static routes.  Even 
> protocols that don't use communities can leverage them in the export policy, 
> the community just isn't announced.  Ditto for import policies.
> 
> Sacrificing that flexibility and simplicity to multithread rpd and shifting 
> to explicit route redistribution with limited route attributes per protocol 
> would be a huge loss.

I always found using communities on non-BGP routes a little weird, but everyone 
has their favorite operational tricks.  (And I try to seek out people to talk 
about them at conferences.  It often leads to small features.)

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), we'd be keeping the same source base.  Thus, static routes could have 
communities, or color or your unusual mechanism of choice. :-)

-- Jeff

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

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

[Jeff Haas]

> On Oct 21, 2015, at 3:21 PM, Tarko Tikan  wrote:
> 
> hey,
> 
>> I always found using communities on non-BGP routes a little weird,
>> but everyone has their favorite operational tricks.  (And I try to
>> seek out people to talk about them at conferences.  It often leads to
>> small features.)
> 
> Communities on static routes are great.
> 
> But everyone wants more :) It would be super helpful if you would support 
> communities or tags on connected routes as well.

Hijacking the thread momentarily, what would you expect that to look like in 
the config?  community/tag keywording in a interface ... family foo {} scope?

-- Jeff

___
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 21 October 2015 at 22:29, Jeff Haas  wrote:
> Hijacking the thread momentarily, what would you expect that to look like in 
> the config?  community/tag keywording in a interface ... family foo {} scope?

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

HTH,
-- 
  ++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?

[Chad Myers]

On Oct 9, 2015, at 10:08 AM, Jeff Haas  wrote:

> Adam,
>
>> On Oct 9, 2015, at 9:45 AM, Adam Chappell  wrote:
>>>
>> I can imagine that making rpd MT is probably hard to the point of almost
>> not being worth the benefit (with current REs), unless one can adequately
>> break down the problem into divisable chunks of work that are insensitive
>> to execution order.  BGP peer route analysis, comparison against import
>> policy and current RIB might fall into that category, but not without a lot
>> of locking and potential for races.
>
> It is non-trivial work.  But it is also somewhat easier to incrementally 
> introduce threading than it is to split large hunks of code and workflow into 
> multiple processes.
>
> We're not going into deep technical detail on mailing lists such as these at 
> the moment.  The work is in progress.

Please don't go the IOS/EOS/non-Junos method for rpd where each protocol is 
completely independent and isolated from the others.  It is extremely helpful 
to be able to do things like put communities on static routes.  Even protocols 
that don't use communities can leverage them in the export policy, the 
community just isn't announced.  Ditto for import policies.

Sacrificing that flexibility and simplicity to multithread rpd and shifting to 
explicit route redistribution with limited route attributes per protocol would 
be a huge loss.

-Chad



This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of Intercontinental 
Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a 
contract or guarantee. Unencrypted electronic mail is not secure and the 
recipient of this message is expected to provide safeguards from viruses and 
pursue alternate means of communication where privacy or a binding message is 
desired.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Tarko Tikan]

hey,


I always found using communities on non-BGP routes a little weird,
but everyone has their favorite operational tricks.  (And I try to
seek out people to talk about them at conferences.  It often leads to
small features.)


Communities on static routes are great.

But everyone wants more :) It would be super helpful if you would 
support communities or tags on connected routes as well.


--
tarko
___
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 21 October 2015 at 22:05, Chad Myers  wrote:

Hey Chad,

> Please don't go the IOS/EOS/non-Junos method for rpd where each protocol is 
> completely independent and isolated from the others.  It is extremely helpful 
> to be able to do things like put communities on static routes.  Even 
> protocols that don't use communities can leverage them in the export policy, 
> the community just isn't announced.  Ditto for import policies.
>
> Sacrificing that flexibility and simplicity to multithread rpd and shifting 
> to explicit route redistribution with limited route attributes per protocol 
> would be a huge loss.

You don't need to worry, these two issues have nothing in common. What
you're talking about is very high level concept and it implies nothing
about the underlaying architecture.

Having said that, why on earth no tags/communities on direct/connected
routes on any(?) platform. It dilutes usefulness in static routes as
well, as you're still going to need to have logic to provision
prefix-lists, so might as well do it same way for statics and directs.




-- 
  ++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?

[Tarko Tikan]

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.

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

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

[Chad Myers]

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.




This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of Intercontinental 
Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a 
contract or guarantee. Unencrypted electronic mail is not secure and the 
recipient of this message is expected to provide safeguards from viruses and 
pursue alternate means of communication where privacy or a binding message is 
desired.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Chad Myers]

On Oct 21, 2015, at 3:34 PM, Saku Ytti  wrote:
> Hey Chad,
>
>> Please don't go the IOS/EOS/non-Junos method for rpd where each protocol is 
>> completely independent and isolated from the others.  It is extremely 
>> helpful to be able to do things like put communities on static routes.  Even 
>> protocols that don't use communities can leverage them in the export policy, 
>> the community just isn't announced.  Ditto for import policies.
>>
>> Sacrificing that flexibility and simplicity to multithread rpd and shifting 
>> to explicit route redistribution with limited route attributes per protocol 
>> would be a huge loss.
>
> You don't need to worry, these two issues have nothing in common. What
> you're talking about is very high level concept and it implies nothing
> about the underlaying architecture.

True, but I also know a good bit about the underlying architecture and have a 
good grasp of general system and programming concepts.  Definitely not a 
developer though so I don't typically know the specifics on how something is 
implemented.

>From a general view it seems that the simplest and fastest method to get rpd 
>to leverage multicore systems better is splitting apart the different 
>protocols.  That opens up having to deal with contention amongst the different 
>protocols trying to access a single global route table simultaneously.  It can 
>be done but it could also be sidestepped entirely by having per protocol 
>tables rather than a single global table.  I would hope that isn't the path 
>taken, but I've already dealt with various groups within Juniper and elsewhere 
>that have made design decisions ranging from fantastic to questionable to 
>absolutely horrible.  My request is just trying to prevent seeing Junos core 
>do something really bad, either inadvertently or on purpose.

> Having said that, why on earth no tags/communities on direct/connected
> routes on any(?) platform. It dilutes usefulness in static routes as
> well, as you're still going to need to have logic to provision
> prefix-lists, so might as well do it same way for statics and directs.

Adding that would be on the fantastic side of design decisions.

As would getting the group that handles spd to adhere to the same standards as 
the rest of Junos with regard to naming conventions, inheritance, and 
prefix-list expansions.  And finally putting commas in the monitor interface 
traffic output.

-Chad



This message may contain confidential information and is intended for specific 
recipients unless explicitly noted otherwise. If you have reason to believe you 
are not an intended recipient of this message, please delete it and notify the 
sender. This message may not represent the opinion of Intercontinental 
Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a 
contract or guarantee. Unencrypted electronic mail is not secure and the 
recipient of this message is expected to provide safeguards from viruses and 
pursue alternate means of communication where privacy or a binding message is 
desired.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp