Re: [j-nsp] EX2200 LLDP Port Info

2015-03-27 Thread Luca Salvatore
We have submitted a feature request with juniper for this very issue.
It has changed to reporting the description in more recent versions, as
well as on QFX devices.
Reporting the interface description is pretty useless, i'd much rather see
the interface name.

On Thu, Mar 26, 2015 at 1:16 PM, Bill Blackford 
wrote:

> The EX2200 is reporting it's port info differently. If an interface
> description is present, the port info displays what is in the descr.(akin
> to ifAlias) If an interface description is not present, then the actual
> interface is displayed (akin to ifName)
>
>
> Example 1. from an EX4200 showing neighbor of EX2200
>
> Local InterfaceParent InterfaceChassis Id  Port info
>System Name
> ge-0/0/24.0ae24.0 _AE0_
>  XXX-2A-04-S1
>
>
>
> Example 2. from the same EX4200 shoeing neighbor of EX4550. the EX4550 has
> an interface descr.
>
> Local InterfaceParent InterfaceChassis Id  Port info
>System Name
> xe-0/1/0.0 ae48.0 xe-0/0/31.0
>  AR01.XXX
>
>
>
>
> Example 3. The same EX2200 as in ex. 1,  with the descr removed.
>
> Local InterfaceParent InterfaceChassis Id  Port info
>System Name
> ge-0/0/24.0ae24.0 ge-0/1/0.0
>XXX-2A-04-S1
>
>
>
> Seems to be undesired behavior. So, far I have not found anything in the
> release notes that would indicate a fix. any thoughts on this from the
> group?
>
> Thank you,
>
> -b
>
>
> --
> Bill Blackford
>
> Logged into reality and abusing my sudo privileges.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Luca Salvatore
Network Engineer
Cell: +1 (929) 214-7242
Desk: +1 (347) 305-4030
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] EX2200 LLDP Port Info

2015-03-27 Thread Saku Ytti
Hey Bey and Bill,

> In fact, the behaviour of LLDP from platform to platform across the whole 
> range is pretty inconsistent:

ACK.

> Anyway, you can partially resolve this issue with the following:
> set protocols lldp port-id-subtype interface-name

Yup.


What is the purpose of LLDP? I feel the purpose is to allow programmatic
discovery of the network. Ignore rest, if I've understood incorrectly.

LLDP standard allows exactly one subtype for portID and chassisID, but allows
you to choose from list of several options, including 'locally defined' which
can contain anything, and you cannot a-priori know how to parse it.

None of the options available are 'SNMP ifIndex', which seems most apt, for
programmatic discovery of the network. Some vendors choose to send 'locally
defined' portID, which contains 'SNMP ifIndex'.

You can have 100% compliant LLDP implemention, which will give you no useful
information what-so-ever. Some of the rationale here seems to be flexiblity of
the standard. I wish there would be more stringent requirement, that if you
implement IP and SNMP, then you MUST send MGMT address as chassisID and you
MUST send ifIndex in portID and you MAY send other subtypes as needed.

Less lazy people might propose IEEE to do:

---
- addition of ifIndex to portID (8.5.3.2, table 8.3)
- addition of ifDescr to portID (8.5.3.2, table 8.3)
- networkAddress defined as address which must responds to SNMP, if
host implements SNMP (table 8.2)
- 1 or more chassisID, portID must be in PDU (8.5.2.4, 8.5.4.2)
- new section in (8.5.2.2, 8.5.3.2) where it is mandated if host
implements SNMP and IP (any version) it one of the subtypes in
chassisID must be 'networkAddress' and one of the subtypes in portID
must be ifIndex.
---


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


Re: [j-nsp] EX2200 LLDP Port Info

2015-03-26 Thread Ben Dale
Hi Bill,

On 27 Mar 2015, at 3:16 am, Bill Blackford  wrote:
> Seems to be undesired behavior. So, far I have not found anything in the
> release notes that would indicate a fix. any thoughts on this from the
> group?

What you're seeing on the EX2200 changes from version to version

11.4R7 ignores the description and sends the logical interface name eg: 
ge-0/1/0.0
12.3R4.6 overrides the interface name with the description eg: "Link to switchA 
- ge-0/0/0"

In fact, the behaviour of LLDP from platform to platform across the whole range 
is pretty inconsistent:

MX80 - 14.2R1.9 (shows ifIndex of neighbouring interface):
Local InterfaceParent InterfaceChassis Id  Port info  
System Name
ge-1/1/2   -   40:b4:f0:49:98:f0   505
ACX1100 
ge-1/0/0   ae0 5c:5e:ab:0e:7f:40   516
MX80-B  
ge-1/1/0   ae0 5c:5e:ab:0e:7f:40   526
MX80-B  
ge-1/1/5   -   5c:5e:ab:0e:7f:40   531
MX80-B  

ACX1100 - 12.3something (shows ifIndex of neighbouring interface, and has no 
Parent interface to identify aggregates)
Local Interface Chassis IdPort info System Name
ge-0/0/45c:5e:ab:0e:60:30 528   MX80-A   
ge-0/0/15c:5e:ab:0e:7f:40 517   MX80-B   
ge-0/0/05c:5e:ab:0e:7f:40 527   MX80-B   

I seem to recall older versions of MX code (11 or 12) used to send the 
description field as well.

As for why - one example I know of is that there is a provider here that uses 
LLDP to send through the Circuit ID of their tails via Port Description, which 
is nice for operations staff on the remote end for ticket logging.

Anyway, you can partially resolve this issue with the following:

set protocols lldp port-id-subtype interface-name

This means that the *sending* LLDP device will now send the interface name in 
the Port ID field instead of the ifindex.  Unfortunately, the "show lldp 
neighbors" command will still only show the value of the Port Description 
field, which will get overridden by the interface description.  Instead you'll 
need to use "show lldp neighbours interface " to see it.

BEFORE:

bdale@GD-eng-22c# run show lldp neighbors interface ge-0/1/1.0 
...
Neighbour Information:
Chassis type   : Mac address
Chassis ID : b0:a8:6e:8d:5a:40
Port type  : Locally assigned
Port ID: 527   <-
Port description   : Uplink to GD-eng-22c
System name: GD-rck-22c 
   
AFTER:

bdale@GD-eng-22c# run show lldp neighbors interface ge-0/1/1.0 
.
Neighbour Information:
Chassis type   : Mac address
Chassis ID : b0:a8:6e:8d:5a:40
Port type  : Interface name
Port ID: ge-0/1/0   <-
Port description   : Uplink to GD-eng-22c
System name: GD-rck-22c

To fix this though, I've put together an op script that behaves in a similar 
manner to "show lldp neighbors" except that it lists the Port ID field as well: 
https://github.com/dfex/DFEXjunoscripts/blob/master/show-lldp-neat.slax

It works works on the EX22/42 okay, but the EX doesn't seem to support remote 
execution (eg: op url 
https://github.com/dfex/DFEXjunoscripts/blob/master/show-lldp-neat.slax) across 
any of the version I've tried: 11.4R7.5, 12.3R2.5, 12.3R4.6, 12.3R6.6, 
13.2X51-D20.2.

On the MX under 14.2R1.9, remote execution works, but the script is a bit 
borked as it seems to be trying to re-use the variable from the previous 
iteration in for-each - let me know if anyone has an better experiences.

Cheers,

Ben

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


[j-nsp] EX2200 LLDP Port Info

2015-03-26 Thread Bill Blackford
The EX2200 is reporting it's port info differently. If an interface
description is present, the port info displays what is in the descr.(akin
to ifAlias) If an interface description is not present, then the actual
interface is displayed (akin to ifName)


Example 1. from an EX4200 showing neighbor of EX2200

Local InterfaceParent InterfaceChassis Id  Port info
   System Name
ge-0/0/24.0ae24.0 _AE0_
 XXX-2A-04-S1



Example 2. from the same EX4200 shoeing neighbor of EX4550. the EX4550 has
an interface descr.

Local InterfaceParent InterfaceChassis Id  Port info
   System Name
xe-0/1/0.0 ae48.0 xe-0/0/31.0
 AR01.XXX




Example 3. The same EX2200 as in ex. 1,  with the descr removed.

Local InterfaceParent InterfaceChassis Id  Port info
   System Name
ge-0/0/24.0ae24.0 ge-0/1/0.0
   XXX-2A-04-S1



Seems to be undesired behavior. So, far I have not found anything in the
release notes that would indicate a fix. any thoughts on this from the
group?

Thank you,

-b


-- 
Bill Blackford

Logged into reality and abusing my sudo privileges.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp