[j-nsp] Interfaces with copper SFPs not getting torn down when partner is disabled (not correctly recognizing Media type?)
Graham Brown
juniper-nsp at grahambrown.info
Tue Jul 19 15:43:35 EDT 2016
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 <https://twitter.com/#!/mountainrescuer>
LinkedIn <http://www.linkedin.com/in/grahamcbrown>
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