[c-nsp] Third party transceivers that fail only with new NX-OS 6.2.2a on sup-2E (Jeffrey G. Fitzwater)
Josh
jastrckl at gmail.com
Mon Nov 18 18:16:28 EST 2013
Have you tried "service unsupported-transceiver"?
-Josh
On Mon, Nov 18, 2013 at 4:55 PM, <cisco-nsp-request at puck.nether.net> wrote:
> Send cisco-nsp mailing list submissions to
> cisco-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> or, via email, send a message with subject or body 'help' to
> cisco-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
> cisco-nsp-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cisco-nsp digest..."
>
>
> Today's Topics:
>
> 1. NTP Sources placement in MPLS network (Yham)
> 2. Re: [j-nsp] NTP Sources placement in MPLS network (Jared Mauch)
> 3. Re: Etherchannel Issue (Jeyamurali Sivapathasundaram)
> 4. Re: ASR 901 EoMPLS (Fredrik V?cks)
> 5. Possible split horizon issue with bgp signalled vpls (Nick Ryce)
> 6. Third party transceivers that fail only with new NX-OS 6.2.2a
> on sup-2E (Jeffrey G. Fitzwater)
> 7. Re: Third party transceivers that fail only with new NX-OS
> 6.2.2a on sup-2E (Justin M. Streiner)
> 8. Re: ASR 901 EoMPLS (Pshem Kowalczyk)
> 9. Re: [j-nsp] NTP Sources placement in MPLS network (Yham)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 18 Nov 2013 14:33:04 -0500
> From: Yham <yhameed81 at gmail.com>
> To: cisco-nsp at puck.nether.net, juniper-nsp at puck.nether.net
> Subject: [c-nsp] NTP Sources placement in MPLS network
> Message-ID:
> <CAJEaoj-sT1RGTtH9JEhfAS32YRL+21JbBRBkWv8=
> SdGiMtdZYA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Guys,
>
>
> In a SP environment where there are hundreds of PEs and P devices that got
> hundreds of customers VRFs, what is the best place to connect NTP sources.
> The place i can think of is connecting with VPNv4 Route Reflectors because
> they exist on top of hierarchy and so clock can travel downward from RR to
> PEs and P and from PEs to CEs and further down if required.
>
> Any thoughts on this please.
>
> Regards
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 18 Nov 2013 14:52:16 -0500
> From: Jared Mauch <jared at puck.nether.net>
> To: Yham <yhameed81 at gmail.com>
> Cc: "juniper-nsp at puck.nether.net List" <juniper-nsp at puck.nether.net>,
> "cisco-nsp at puck.nether.net NSP" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] [j-nsp] NTP Sources placement in MPLS network
> Message-ID: <FCAD506A-F034-4BBB-9668-B04AE70C24F6 at puck.nether.net>
> Content-Type: text/plain; charset=us-ascii
>
> This all depends on what you need the clocking for.
>
> If you want just generic time for accurate logs?
>
> Depending on what you want to do, there's cheap NTP clocks like this:
>
> http://www.netburnerstore.com/product_p/pk70ex-ntp.htm
>
> For about $350 (including S/H in the US) you get a GPS clock. With the
> right location/antenna you can get signal through some roofs.
>
> There's a variety of higher-end timing options depending on what you need.
>
> - Jared
>
> On Nov 18, 2013, at 2:33 PM, Yham <yhameed81 at gmail.com> wrote:
>
> > Hi Guys,
> >
> >
> > In a SP environment where there are hundreds of PEs and P devices that
> got
> > hundreds of customers VRFs, what is the best place to connect NTP
> sources.
> > The place i can think of is connecting with VPNv4 Route Reflectors
> because
> > they exist on top of hierarchy and so clock can travel downward from RR
> to
> > PEs and P and from PEs to CEs and further down if required.
> >
> > Any thoughts on this please.
> >
> > Regards
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 18 Nov 2013 19:58:39 +0000
> From: Jeyamurali Sivapathasundaram <sjeyamurali at gmail.com>
> To: M K <gunner_200 at live.com>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Etherchannel Issue
> Message-ID: <-2299382920471725940 at unknownmsgid>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Have you tried to remove all portchannel config.
>
> Shutdown all ports. Then only enable the ports you got a problem with ?
>
> Or try with the ports that work and then add the other ports and check
> the logs ??
>
> Jey S.
> Network Engineer
>
> Sent from my iPhone
>
> > On 18 Nov 2013, at 12:27, M K <gunner_200 at live.com> wrote:
> >
> > I have Cisco CISCO7606-S (R7000) with 48 SFM-capable 48 port
> 10/100/1000mb RJ45 moduleNow , I have 5 ports connected to my WiMAX ASN
> gateway via two vlans one to the access side and the other one connected to
> the core sideThe issue am facing now is some of the ports are into
> errdisable state by itself
> > Module diagnostics output 3 Pass
> > Group Port-channel Protocol
> Ports------+-------------+-----------+-----------------------------------------------10
> Po10(SU) - Gi3/3(D) Gi3/11(D) Gi3/19(D)
> Gi3/27(P) Gi3/35(P) 20 Po20(SU) -
> Gi3/4(D) Gi3/12(D) Gi3/20(D)
> Gi3/28(P) Gi3/36(P)
> > CR2.KJ-Building#sh int Gi3/3 | inc lineGigabitEthernet3/3 is down, line
> protocol is down (err-disabled)
> > interface GigabitEthernet3/3 description ASN LBPA0 C6 P5 (Po10)
> (CORE_VLAN) switchport switchport access vlan 10 switchport mode access no
> logging event link-status load-interval 30 speed 1000 duplex full
> flowcontrol receive on flowcontrol send on channel-group 10 mode on
> > CR2.KJ-Building#sh run int vlan 10Building configuration...
> > Current configuration : 242 bytes!interface Vlan10 description CORE VLAN
> ip address 10.40.2.3 255.255.255.240 no ip redirects no ip unreachables
> load-interval 30 standby 10 ip 10.40.2.1 standby 10 priority 120 standby 10
> preempt standby 10 name CORE_VLAN_HSRP
> > The configuration for the physical port is identical for all ports , no
> log messages give a clue that there is a problemNow , if i enabled those
> interfaces again , I lose the device until I restart the module again
> > No spanning-tree issues were noticed , I have checked everything !
> > What could cause this?
> > Thanks
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 18 Nov 2013 21:04:48 +0100
> From: Fredrik V?cks <fredrik.vocks at bredband2.se>
> To: Pshem Kowalczyk <pshem.k at gmail.com>
> Cc: "<cisco-nsp at puck.nether.net>" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] ASR 901 EoMPLS
> Message-ID:
> <
> CAMkPpBbh69jCcdmMQuCzP-1meXzxdyZgf2O76OcRF0ekjKxorw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> Im trying to do this on Version 15.3(3)S but the xconnect is rejected if I
> enable l2protocol forward.
>
> Which version are you succesfully doing this on?
>
>
> (config-if-srv)# l2protocol forward
> (config-if-srv)#xconnect x.x.x.x 1730 encapsulation mpls
> Layer2 protocol tunnel/forward/peer configured. Command rejected
>
> /F
>
>
>
>
> On 18 November 2013 19:43, Pshem Kowalczyk <pshem.k at gmail.com> wrote:
>
> > Hi,
> >
> > The only way we could get the L2 forwarding going on ASR901 was using
> > a single service instance with encapsulation default (this only works
> > in newest software):
> >
> > interface GigabitEthernet0/8
> > no ip address
> > negotiation auto
> > no keepalive
> > service instance 1 ethernet
> > encapsulation default
> > l2protocol forward
> > xconnect 10.123.129.3 34322 encapsulation mpls
> > mtu 9000
> >
> >
> > kind regards
> > Pshem
> >
> >
> > On 19 November 2013 02:11, Fredrik V?cks <fredrik.vocks at bredband2.se>
> > wrote:
> > > Hi all,
> > >
> > > We are having a customer who says he can't forward BPDU packets over an
> > > portbased EoMPLS using an ASR 901.
> > >
> > > Is this something known or am I missing something? Relevant
> > configuration;
> > >
> > > interface TenGigabitEthernet0/1
> > > description c_customer433231
> > > no keepalive
> > > xconnect x.x.x.x 1730 encapsulation mpls
> > >
> > > /F
> > > _______________________________________________
> > > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 18 Nov 2013 20:05:46 +0000
> From: Nick Ryce <nick at fluency.net.uk>
> To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] Possible split horizon issue with bgp signalled vpls
> Message-ID: <7313A3D7-5A1F-46D7-A9AA-159BC7AC4595 at fluency.net.uk>
> Content-Type: text/plain; charset="Windows-1252"
>
> Hi,
>
> I?m tearing my hair out with this one and can?t figure out how to resolve
> it.
>
> I have 3 switches that have a BGP signalled VPLS with customer routers
> hanging off the end of all 3 ( one switch has 2 cpe )
>
> All have the RD 56595:4 and RT 56595:4
>
> All pseudo wires are up between the switches with config snippets below:-
>
> Switch 1
>
> VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP
> VPN ID: 4, VE-ID: 3, VE-SIZE: 10
> RD: 56595:4, RT: 56595:4, 56595:4
> Bridge-Domain 903 attachment circuits:
> Vlan903
> Neighbors connected via pseudowires:
> Interface Peer Address VE-ID Local Label Remote Label S
> pseudowire100033 46.226.0.9 2 402 39 Y
> pseudowire100037 46.226.0.14 1 401 49 Y
>
> This switch has 1 cpe with any vlan tags stripped and can ping all devices
> on the other switches
>
>
> Switch 2
>
> VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP
> VPN ID: 4, VE-ID: 1, VE-SIZE: 10
> RD: 56595:4, RT: 56595:4, 56595:4
> Bridge-Domain 11 attachment circuits:
> Vlan11
> Neighbors connected via pseudowires:
> Interface Peer Address VE-ID Local Label Remote Label S
> pseudowire100015 46.226.0.12 3 49 401 Y
> pseudowire100018 46.226.0.9 2 48 37 Y
>
> This switch has 2 cpe?s with any vlan tags stripped. They can ping each
> other and the device connected to switch 1 but cannot ping device on switch
> 3
>
> Switch 3
>
> VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP
> VPN ID: 4, VE-ID: 2, VE-SIZE: 10
> RD: 56595:4, RT: 56595:4, 56595:4
> Bridge-Domain 4 attachment circuits:
> Vlan4
> Neighbors connected via pseudowires:
> Interface Peer Address VE-ID Local Label Remote Label S
> pseudowire100028 46.226.0.12 3 39 402 Y
> pseudowire100027 46.226.0.14 1 37 28 Y
>
> This switch has 1 cpe device connected with any vlan tags stripped and can
> only ping the device on switch 1
>
>
> Each switch can see all the correct mac addresses.
>
> It sounds like split horizon but I assumed this was only to do with the
> local switch?
>
> All devices are running 15.3(3)S
>
> Any help much appreciated.
>
> Nick
>
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 18 Nov 2013 20:24:23 +0000
> From: "Jeffrey G. Fitzwater" <jfitz at Princeton.EDU>
> To: "<cisco-nsp at puck.nether.net>" <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] Third party transceivers that fail only with new
> NX-OS 6.2.2a on sup-2E
> Message-ID:
> <5E76A4E2-663D-4E43-BAC0-8BB2BE48177C at exchange.princeton.edu>
> Content-Type: text/plain; charset="Windows-1252"
>
>
> Since CISCO TECH will probably not touch this because its not CISCO, I see
> if anybody has solution.
>
>
>
> We are running nx-os 6.1.3 on 7k with sup-2E on a new chassis that will go
> into production soon. We wanted to run the 6.2.2a to fix some other issues
> with logging and found out the channel ports failed to come up due to
> transceiver Invalid.
>
> ??????-
>
> ( Eth1/1 #### core-ns ch xcvrInval trunk auto auto
> 10Gbase-LR)
>
> ??????-
>
> Backing out to 6.1.3 and all comes back to life.
>
>
> Has anybody else sent his issue with third party transceivers?
>
> I?ll probably open a TAC case just to see what they say anyway.
>
>
>
> Thanks for any help.
>
>
>
>
> Jeff Fitzwater
> OIT Network System
> Princeton University
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 18 Nov 2013 12:00:00 -0500 (EST)
> From: "Justin M. Streiner" <streiner at cluebyfour.org>
> To: "<cisco-nsp at puck.nether.net>" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Third party transceivers that fail only with new
> NX-OS 6.2.2a on sup-2E
> Message-ID: <Pine.LNX.4.64.1311181150230.31342 at whammy.cluebyfour.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Mon, 18 Nov 2013, Jeffrey G. Fitzwater wrote:
>
> > Since CISCO TECH will probably not touch this because its not CISCO, I
> > see if anybody has solution.
> >
> > Backing out to 6.1.3 and all comes back to life.
> >
> > Has anybody else sent his issue with third party transceivers?
>
> I don't know if Cisco's stance on running third-party optics changed
> between NX-OS 6.1 and 6.2, but that's certainly possible. I'm running
> NX-OS 6.2.2 in production on a few of our 7Ks, but we don't have any
> non-Cisco optics to test with.
>
> jms
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 19 Nov 2013 07:43:15 +1300
> From: Pshem Kowalczyk <pshem.k at gmail.com>
> To: Fredrik V?cks <fredrik.vocks at bredband2.se>
> Cc: "<cisco-nsp at puck.nether.net>" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] ASR 901 EoMPLS
> Message-ID:
> <CAEaZiRXiwDF5tVA5sd6nJyh45RMkkjT3nA8z4EZTTjg=
> Efk5Ww at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> The only way we could get the L2 forwarding going on ASR901 was using
> a single service instance with encapsulation default (this only works
> in newest software):
>
> interface GigabitEthernet0/8
> no ip address
> negotiation auto
> no keepalive
> service instance 1 ethernet
> encapsulation default
> l2protocol forward
> xconnect 10.123.129.3 34322 encapsulation mpls
> mtu 9000
>
>
> kind regards
> Pshem
>
>
> On 19 November 2013 02:11, Fredrik V?cks <fredrik.vocks at bredband2.se>
> wrote:
> > Hi all,
> >
> > We are having a customer who says he can't forward BPDU packets over an
> > portbased EoMPLS using an ASR 901.
> >
> > Is this something known or am I missing something? Relevant
> configuration;
> >
> > interface TenGigabitEthernet0/1
> > description c_customer433231
> > no keepalive
> > xconnect x.x.x.x 1730 encapsulation mpls
> >
> > /F
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 18 Nov 2013 17:54:59 -0500
> From: Yham <yhameed81 at gmail.com>
> To: Jared Mauch <jared at puck.nether.net>
> Cc: "juniper-nsp at puck.nether.net List" <juniper-nsp at puck.nether.net>,
> "cisco-nsp at puck.nether.net NSP" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] [j-nsp] NTP Sources placement in MPLS network
> Message-ID:
> <
> CAJEaoj_cTYaksxi4ktvVWRYVNdvxBcvpfiqn2azJOi8sbs-_sA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Thank Jared,
>
> NTP is only needed to synchronize the logs so on event of failure, logs
> from related devices can be correlated.
>
> Thanks
>
>
>
> On Mon, Nov 18, 2013 at 2:52 PM, Jared Mauch <jared at puck.nether.net>
> wrote:
>
> > This all depends on what you need the clocking for.
> >
> > If you want just generic time for accurate logs?
> >
> > Depending on what you want to do, there's cheap NTP clocks like this:
> >
> > http://www.netburnerstore.com/product_p/pk70ex-ntp.htm
> >
> > For about $350 (including S/H in the US) you get a GPS clock. With the
> > right location/antenna you can get signal through some roofs.
> >
> > There's a variety of higher-end timing options depending on what you
> need.
> >
> > - Jared
> >
> > On Nov 18, 2013, at 2:33 PM, Yham <yhameed81 at gmail.com> wrote:
> >
> > > Hi Guys,
> > >
> > >
> > > In a SP environment where there are hundreds of PEs and P devices that
> > got
> > > hundreds of customers VRFs, what is the best place to connect NTP
> > sources.
> > > The place i can think of is connecting with VPNv4 Route Reflectors
> > because
> > > they exist on top of hierarchy and so clock can travel downward from RR
> > to
> > > PEs and P and from PEs to CEs and further down if required.
> > >
> > > Any thoughts on this please.
> > >
> > > Regards
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> cisco-nsp mailing list
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
> ------------------------------
>
> End of cisco-nsp Digest, Vol 132, Issue 56
> ******************************************
>
More information about the cisco-nsp
mailing list