[j-nsp] Interfaces with copper SFPs not getting torn down when partner is disabled (not correctly recognizing Media type?)

Jason Lixfeld jason-jnsp at lixfeld.ca
Tue Jul 19 16:08:57 EDT 2016


Hi Graham,

I hear what you are saying.  I’m in agreement that not all transceivers are created equally, however from my perspective, having used the same vendor of SFPs for many number of years in other platforms without any of the issues I’ve experienced here, I’m not sure I’d say the transceivers are coded incorrectly :)

Perhaps the other platforms have more internally tuned easy buttons that make certain issues transparent to the user, I don’t know.  Regardless, I’d be more inclined to contemplate a sliding scale when referring to the claim of "3rd party optics support”, no matter who the platform vendor is.

I’ll see if my supplier can code these as Juniper and see where that gets me.

Thanks! :)

> On Jul 19, 2016, at 3:43 PM, Graham Brown <juniper-nsp at grahambrown.info> wrote:
> 
> Hi Jason,
> 
> What your SE has told you is perfectly true, that third party transceivers are supported - however, not all transceivers are created equally, nor encoded correctly.
> 
> From your experience above, I would stick to Finistar for production and earmark the rest for lab use only.
> 
> Once you find a good supplier, stick with them and if you find any issues, they will generally work with you to assist.
> 
> Cheers,
> Graham
> 
> Graham Brown
> Twitter - @mountainrescuer
> LinkedIn
> 
> On 20 July 2016 at 03:59, Jason Lixfeld <jason-jnsp at lixfeld.ca> wrote:
> Hi Brian,
> 
> A couple of OEM and one Finisar.  All show up as Media type: Fiber
> 
> ario at lab01.juniper# run show chassis pic fpc-slot 0 pic-slot 1
> FPC slot 0, PIC slot 1 information:
>   Type                             10x 1GE SFP
>   State                            Online
>   PIC version                  2.4
>   Uptime                         3 days, 18 hours, 11 minutes, 58 seconds
> 
> PIC port information:
>                          Fiber                    Xcvr vendor       Wave-    Xcvr
>   Port Cable type        type  Xcvr vendor        part number       length   Firmware
>   0    GIGE 1000T        n/a   OEM                GLC-T-BF          UNKNOWN WAVELENGTH1 nm - UNKNOWN WAVELENGTH2 nm 0.0
>   1    GIGE 1000T        n/a   FINISAR CORP.      FCLF-8521-3       n/a      0.0
> 
> [edit]
> ario at lab01.juniper# run show chassis pic fpc-slot 0 pic-slot 3
> FPC slot 0, PIC slot 3 information:
>   Type                             10x 1GE SFP
>   State                            Online
>   PIC version                  2.4
>   Uptime                         3 days, 18 hours, 12 minutes, 10 seconds
> 
> PIC port information:
>                          Fiber                    Xcvr vendor       Wave-    Xcvr
>   Port Cable type        type  Xcvr vendor        part number       length   Firmware
>   0    GIGE 1000T        n/a   OEM                GLC-T-BF          UNKNOWN WAVELENGTH1 nm - UNKNOWN WAVELENGTH2 nm 0.0
> 
> [edit]
> ario at lab01.juniper#
> 
> I did some further testing Intra-9204 OEM to OEM, Intra-9204 OEM to Finisar, 9204 OEM to Cisco built-in copper and 9204 Finisar to Cisco built in copper:
> 
> Intra-9204 Finisar to OEM:
> Finisar shut down, OEM does not respond.
> OEM shut down, Finisar responds.
> 
> Intra-9204 OEM to OEM:
> OEM1 shut down, OEM2 does not respond.
> 
> 9204 OEM to Cisco built-in copper:
> 9204 shut down, Cisco responds.
> Cisco shut down, 9204 does not respond.
> 
> 9204 Finisar to Cisco built-in copper:
> 9204 shut down, Cisco responds.
> Cisco shut down, 9204 responds.
> 
> So based on these results, the Finisar seems to behave correctly, and if I physically disconnect the cable between the two Intra-9204 OEMs, the both sides in fact stay up.  So it looks like this is yet another case of what Graham reported below.
> 
> > On Jul 19, 2016, at 10:28 AM, Brian Ross <brain at brains-lans.com> wrote:
> >
> > Jason,
> >
> > What Vendor do your transceivers show up as in 'show chassis pic
> > fpc-slot <x> pic-slot <y>
> >
> > Ive had bad experiences with 3rd party copper trispeed spfs that don't
> > show up as 'Methode Electric.'
> >
> > Brian
> >
> >
> > On 19 July 2016 at 15:15, Jason Lixfeld <jason-jnsp at lixfeld.ca> wrote:
> >> Hi Graham,
> >>
> >> These are 3rd party.  I was told that by my SE that the platform fully supports 3rd party optics... not that that really means anything :)
> >>
> >>> On Jul 18, 2016, at 4:38 PM, Graham Brown <juniper-nsp at grahambrown.info> wrote:
> >>>
> >>> Hi Jason,
> >>>
> >>> Are these SFPs Juniper supplied or third party? Over the years there have been many documented issues with Base-T SFPs, where you lose physical and they report as being up.
> >>>
> >>> IIRC, the Juniper supplied SFPs are ok and I have tested third party ones that do work, but it's a little hit and miss.
> >>>
> >>> NB: I have not tested the EX9200.
> >>>
> >>> HTH,
> >>> Graham
> >>>
> >>> Graham Brown
> >>> Twitter - @mountainrescuer
> >>> LinkedIn
> >>>
> >>> On 19 July 2016 at 08:04, Jason Lixfeld <jason-jnsp at lixfeld.ca> wrote:
> >>> Hey there,
> >>>
> >>> I’m messing around with a lab EX9204 with a EX9200-40x1G-SFP running 14.2R4.9
> >>>
> >>> I’ve got two ports (on the same box) connected together with 10/100/1000T SFPs in each.
> >>>
> >>> ario at lab01.juniper# show interfaces | display set
> >>> set interfaces ge-0/1/0 unit 0
> >>> set interfaces ge-0/3/0 unit 0
> >>>
> >>> ario at lab01.juniper# run show lldp neighbors
> >>> Local Interface    Parent Interface    Chassis Id          Port info          System Name
> >>> ge-0/1/0           -                   30:7c:5e:96:ac:80   ge-0/3/0           lab01.juniper
> >>> ge-0/3/0           -                   30:7c:5e:96:ac:80   ge-0/1/0           lab01.juniper
> >>>
> >>> [edit]
> >>> ario at lab01.juniper#
> >>>
> >>> I’m noticing that if I disable either interface, it’s partner interface does not go down.  I’m not talking about Ethernet OAM, just simple layer 1 link detection with copper SFPs.  In my past experiences with various Cisco platforms, this works with no special configuration required.  One thing of interest is that the box thinks the media type is Fiber.
> >>>
> >>> ario at lab01.juniper# set interfaces ge-0/1/0 disable
> >>>
> >>> [edit]
> >>> ario at lab01.juniper# commit
> >>> commit complete
> >>>
> >>> [edit]
> >>> ario at lab01.juniper# Jul 18 15:56:42.333 2016  lab01.juniper mib2d[2006]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 558, ifAdminStatus down(2), ifOperStatus down(2), ifName ge-0/1/0
> >>>
> >>>
> >>> [edit]
> >>> ario at lab01.juniper# run show interfaces ge-0/1/0
> >>> Physical interface: ge-0/1/0, Administratively down, Physical link is Down
> >>>  Interface index: 149, SNMP ifIndex: 558
> >>>  Link-level type: Ethernet, MTU: 1514, MRU: 0, LAN-PHY mode, Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
> >>>  Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online, Media type: Fiber
> >>>  Device flags   : Present Running Down
> >>>  Interface flags: Hardware-Down Down SNMP-Traps Internal: 0x4000
> >>>  Link flags     : None
> >>>  CoS queues     : 8 supported, 8 maximum usable queues
> >>>  Current address: 30:7c:5e:96:a5:65, Hardware address: 30:7c:5e:96:a5:65
> >>>  Last flapped   : 2016-07-18 15:56:42 EDT (00:00:11 ago)
> >>>  Input rate     : 0 bps (0 pps)
> >>>  Output rate    : 0 bps (0 pps)
> >>>  Active alarms  : LINK
> >>>  Active defects : LINK
> >>>  Interface transmit statistics: Disabled
> >>>
> >>>  Logical interface ge-0/1/0.0 (Index 345) (SNMP ifIndex 570)
> >>>    Flags: Device-Down SNMP-Traps 0x4004000 Encapsulation: ENET2
> >>>    Input packets : 3
> >>>    Output packets: 4
> >>>    Protocol multiservice, MTU: Unlimited
> >>>
> >>> [edit]
> >>> ario at lab01.juniper# run show interfaces ge-0/3/0
> >>> Physical interface: ge-0/3/0, Enabled, Physical link is Up
> >>>  Interface index: 169, SNMP ifIndex: 526
> >>>  Link-level type: Ethernet, MTU: 1514, MRU: 0, LAN-PHY mode, Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
> >>>  Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online, Media type: Fiber
> >>>  Device flags   : Present Running
> >>>  Interface flags: SNMP-Traps Internal: 0x4000
> >>>  Link flags     : None
> >>>  CoS queues     : 8 supported, 8 maximum usable queues
> >>>  Current address: 30:7c:5e:96:a6:af, Hardware address: 30:7c:5e:96:a6:af
> >>>  Last flapped   : 2016-07-18 14:52:35 EDT (01:04:23 ago)
> >>>  Input rate     : 0 bps (0 pps)
> >>>  Output rate    : 0 bps (0 pps)
> >>>  Active alarms  : None
> >>>  Active defects : None
> >>>  Interface transmit statistics: Disabled
> >>>
> >>>  Logical interface ge-0/3/0.0 (Index 348) (SNMP ifIndex 544)
> >>>    Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2
> >>>    Input packets : 4
> >>>    Output packets: 4
> >>>    Protocol multiservice, MTU: Unlimited
> >>>
> >>> [edit]
> >>> ario at lab01.juniper#
> >>>
> >>> Am I missing something somewhere?
> >>>
> >>> Thanks in advance.
> >>> _______________________________________________
> >>> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >>>
> >>
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 



More information about the juniper-nsp mailing list