[c-nsp] ASR A9K-8T-L certain ports limited to 8 Gbps.
Dear All, We have a stubborn problem with one of our ASR9Ks. A couple of upstream ports are limited to 8Gbps egress traffic, while others are not affected. It is a 9010 chassis with two RSP-4Gs, and eight A9K-8T-L cards. Of every card the first three ports are used for upstream (egress traffic), and the following five ports are configured for downstream (ingress) There is no specific QoS configured on either side. The RSPs are running 4.2.3. We've swapped both RSPs, and several linecards, however nothing seems to change the behaviour. rrd graph here http://imgur.com/Td4KSGB Has anyone had experience with a situation like this? Thanks, Bas ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Possible split horizon issue with bgp signalled vpls
Hi Jason, CSCuh05321 says it is fixed in the S1 release so would that not mean that it is also in S1a? Nick On 19 Nov 2013, at 03:50, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Just be mindful of CSCuh05321 if you are going to try S1a. If you think you might hit that, I'd suggest moving to static vpls and skip that release until it's fixed. Also, with S1a, look at CSCtl54835 and verify or else your isis adjacencies will break. Sent from my iPhone On Nov 18, 2013, at 10:08 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Just found 1 switch on 15.3(2)S so may be worth a punt and upgrade Nick On 19 Nov 2013, at 02:02, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Issues I was having with BGP signalled VPLS a couple of months ago in 15.3(2)S1 resulted in filing CSCui46390. I'd otherwise suggest trying 15.3(3)S1a to see fix works, but that version seems to have introduced CSCuh05321, so I think that might end badly for you; it did for me :( On Nov 18, 2013, at 3:05 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: 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 AddressVE-ID Local Label Remote LabelS 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 AddressVE-ID Local Label Remote LabelS 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 AddressVE-ID Local Label Remote LabelS 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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] NTP Sources placement in MPLS network
Thanks Jared. I am planning deploy ntp source that will point to global NTP. I am curious to know where service provider with mpls network position the NTP? Any best practices ? Regards On Mon, Nov 18, 2013 at 5:57 PM, Jared Mauch ja...@puck.nether.net wrote: In this case you can sync to any other device or devices that are globally reachable. Typically you can just use some IP that doesn’t often change, e.g.: loopback. If you are running 100% of the network, you can also use the ‘ntp broadcast’ and similar interface commands to listen/send this data hop-by-hop. There’s lots of ways to do this, and not necessarily a ‘wrong’ way. - Jared On Nov 18, 2013, at 5:54 PM, Yham yhamee...@gmail.com wrote: 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 ja...@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 yhamee...@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-...@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] NTP Sources placement in MPLS network
We have servers in each location with NTP synced to local stratum 1 or 2 clocks. Customers are given an anycast ip that points to these for time sources. We configure routers to point at these local sources. Jared Mauch On Nov 19, 2013, at 6:53 AM, Yham yhamee...@gmail.com wrote: Thanks Jared. I am planning deploy ntp source that will point to global NTP. I am curious to know where service provider with mpls network position the NTP? Any best practices ? Regards On Mon, Nov 18, 2013 at 5:57 PM, Jared Mauch ja...@puck.nether.net wrote: In this case you can sync to any other device or devices that are globally reachable. Typically you can just use some IP that doesn’t often change, e.g.: loopback. If you are running 100% of the network, you can also use the ‘ntp broadcast’ and similar interface commands to listen/send this data hop-by-hop. There’s lots of ways to do this, and not necessarily a ‘wrong’ way. - Jared On Nov 18, 2013, at 5:54 PM, Yham yhamee...@gmail.com wrote: 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 ja...@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 yhamee...@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-...@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Possible split horizon issue with bgp signalled vpls
That's what I was about to ask as the CSCuh05321 is actually listed under 15.3(3)S caveats not under 15.3(3)S1a so I'd assume it is resolved in S1a already right? adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce Sent: Tuesday, November 19, 2013 12:14 PM To: Jason Lixfeld Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Possible split horizon issue with bgp signalled vpls Hi Jason, CSCuh05321 says it is fixed in the S1 release so would that not mean that it is also in S1a? Nick On 19 Nov 2013, at 03:50, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Just be mindful of CSCuh05321 if you are going to try S1a. If you think you might hit that, I'd suggest moving to static vpls and skip that release until it's fixed. Also, with S1a, look at CSCtl54835 and verify or else your isis adjacencies will break. Sent from my iPhone On Nov 18, 2013, at 10:08 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Just found 1 switch on 15.3(2)S so may be worth a punt and upgrade Nick On 19 Nov 2013, at 02:02, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Issues I was having with BGP signalled VPLS a couple of months ago in 15.3(2)S1 resulted in filing CSCui46390. I'd otherwise suggest trying 15.3(3)S1a to see fix works, but that version seems to have introduced CSCuh05321, so I think that might end badly for you; it did for me :( On Nov 18, 2013, at 3:05 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: 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 AddressVE-ID Local Label Remote LabelS 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 AddressVE-ID Local Label Remote LabelS 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 AddressVE-ID Local Label Remote LabelS 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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Catalyst 6500: IPv6-enabled SVIs
Hello, I apologize for talk with myself but I found the reason of that hardware TCAM label capacity issue was ipv6 multicast-routing: Cat6500#sh tcam counts ipv6 Used Free Reserved Labels:(in) 160 352 Labels:(eg) 5 507 Cat6500#conf t Enter configuration commands, one per line. End with CNTL/Z. Cat6500(config)#no ipv6 multicast-routing Cat6500(config)#end Cat6500#sh tcam counts ipv6 Used Free Reserved Labels:(in) 11 501 Labels:(eg) 5 507 There is the following statement in the Implementing IPv6 Multicast for IOS 15.0SYhttp://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-0sy/ip6-multicast.html : On Cisco Catalyst 6500 and Cisco 7600 series routers, the ipv6 multicast-routing also must be enabled in order to use IPv6 unicast routing. I disabled ipv6 multicast-routing on test box with 12.2 SXJ3 and did some quick tests - IPv6 works without any issues. May be I missed something or it will not work with 15.0. -- vetr ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR 901 EoMPLS
Hi folks Is the 901 that different form 903 As on 903 it is possible to accomplish the below config on 15.3(2)S1a (03.09.01a.S) adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Pshem Kowalczyk Sent: Monday, November 18, 2013 7:43 PM To: Fredrik Vöcks Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR 901 EoMPLS 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.vo...@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 6500: IPv6-enabled SVIs
Hi, On Tue, Nov 19, 2013 at 06:36:00PM +0600, Vladimir Troitskiy wrote: There is the following statement in the Implementing IPv6 Multicast for IOS 15.0SYhttp://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-0sy/ip6-multicast.html : On Cisco Catalyst 6500 and Cisco 7600 series routers, the ipv6 multicast-routing also must be enabled in order to use IPv6 unicast routing. What? None of my boxes has ipv6 multicast-routing enabled, and it's quite lucky they all do not know that this is a prerequisite for IPv6 unicast :-) (And I'm not enabling IPv6 multicast-routing because I don't like living that close to the edge - and nobody needs that over here anyway, we've just turned off our IPv4 multicast-routing after some 10 years of non-use) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpSokj8TmnCG.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Possible split horizon issue with bgp signalled vpls
Just found 1 switch on 15.3(2)S so may be worth a punt and upgrade Nick Is that device switch3 (veid 2)? As that seems to be the only one with issues adam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
Jeff, We have been running 6.2(2) since the summer. In the last six months, I had to return some third-party Cisco compatible twinax cables because they were Invalid on our M2s. And, I just had to swap out some official Cisco SFP-10G-LR because they were version 1 which also do not work with our M2 cards. As it has been awhile since we ran 6.1 so I do not know if the issue began with 6.2 or not. I do not know if this helps. But, I feel better after venting. :-) -- Christina Klam Network Engineer Institute for Advanced Study Email: ck...@ias.edu Einstein Drive Telephone: 609-734-8154 Princeton, NJ 08540 Fax: 609-951-4418 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Possible split horizon issue with bgp signalled vpls
I dunno. All I know is that after upgrading to S1a, I saw some odd L2 issues. The one I was able to track down was the ME3600 was unable to resolve ARP for hosts on a VLAN behind a directly connected port-channel. The other one that I didn't have time to track down was a host in a VFI was unable to reach hosts in the same VPLS instance on a remote VFI. It's possible that I mis-read the email, but I thought I was told it was due to CSCuh05321. Maybe what the email meant was that the fix for CSCuh05321 didn't work? Maybe the fix for CSCuh05321 caused another issue? All I know is both nodes where I tested this release had to be reverted. On Nov 19, 2013, at 7:33 AM, Adam Vitkovsky adam.vitkov...@swan.sk wrote: That's what I was about to ask as the CSCuh05321 is actually listed under 15.3(3)S caveats not under 15.3(3)S1a so I'd assume it is resolved in S1a already right? adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce Sent: Tuesday, November 19, 2013 12:14 PM To: Jason Lixfeld Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Possible split horizon issue with bgp signalled vpls Hi Jason, CSCuh05321 says it is fixed in the S1 release so would that not mean that it is also in S1a? Nick On 19 Nov 2013, at 03:50, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Just be mindful of CSCuh05321 if you are going to try S1a. If you think you might hit that, I'd suggest moving to static vpls and skip that release until it's fixed. Also, with S1a, look at CSCtl54835 and verify or else your isis adjacencies will break. Sent from my iPhone On Nov 18, 2013, at 10:08 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Just found 1 switch on 15.3(2)S so may be worth a punt and upgrade Nick On 19 Nov 2013, at 02:02, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Issues I was having with BGP signalled VPLS a couple of months ago in 15.3(2)S1 resulted in filing CSCui46390. I'd otherwise suggest trying 15.3(3)S1a to see fix works, but that version seems to have introduced CSCuh05321, so I think that might end badly for you; it did for me :( On Nov 18, 2013, at 3:05 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: 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 AddressVE-ID Local Label Remote LabelS 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 AddressVE-ID Local Label Remote LabelS 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 AddressVE-ID Local Label Remote LabelS 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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net
Re: [c-nsp] IPv6 filters
On Friday, November 15, 2013 02:56:39 PM Tony Tauber wrote: Depending on your OS, you may have to explicitly disable v6 routes being sent over a v4 session. That's possible to do but I don't know why one would want to in a truly dual-stack deployment. In v6 the only v4 artifact will be that the router ID is still a 32-bit number which is most commonly set to the v4 loopback or some such. This has been discussed a few times on this list. Some operators do it, others don't. I don't - I prefer to have my address families running over their own native transport. Some might see it as double work, but it's peace of mind and still looks neat :-). Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ME3600 BFD session to A9K breaks after upgrade to 15.3(3)S1a
On Thursday, November 14, 2013 07:39:14 PM Jason Lixfeld wrote: The root cause was due to a fix implemented in 15.3(3)S1a for CSCtl54835. Essentially, the CLNS mtu is now properly calculated from the L3 interface MTU whereas before, the CLNS MTU was always 1497 no matter what the L3 interface MTU was set to. This fix was not listed in the list of resolved caveats for that release, but it is now. Hmmh, interesting. I've always worked with the impression that the IS-IS MTU is inherited from the interface MTU, both on Cisco and Juniper (although if my ageing photographic memory is anything to go by, a show clns might be playing back sights of 1,497 bytes across ports that certainly had a higher physical MTU). There is a special case I've encountered on a Juniper where this is not the case, on some SDH ports on the MX104, i.e., all address families supported on an interface do not inherit the physical interface's MTU, and end up doing their own thing; workaround is to set the MTU at the address family/protocol level. I think this was a bug that is being fixed. Good to hear that Cisco have finally fixed this, although I'm not sure if this is specific to the ME3600X, or whether it affects other IOS-based platforms (might explain a few inconsistent things I've seen with IS-IS MTU, Hello Padding, e.t.c. over the years with IOS systems). Thanks for the tip, Jason. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IPv6 filters
So how do you keep IPv6 off of IPv4? if you are running dual stack shouldn't it just go out it's native protocol? Scott On Tue, Nov 19, 2013 at 6:42 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Friday, November 15, 2013 02:56:39 PM Tony Tauber wrote: Depending on your OS, you may have to explicitly disable v6 routes being sent over a v4 session. That's possible to do but I don't know why one would want to in a truly dual-stack deployment. In v6 the only v4 artifact will be that the router ID is still a 32-bit number which is most commonly set to the v4 loopback or some such. This has been discussed a few times on this list. Some operators do it, others don't. I don't - I prefer to have my address families running over their own native transport. Some might see it as double work, but it's peace of mind and still looks neat :-). Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] NTP Sources placement in MPLS network
On Tuesday, November 19, 2013 02:02:43 PM Jared Mauch wrote: We have servers in each location with NTP synced to local stratum 1 or 2 clocks. Customers are given an anycast ip that points to these for time sources. We configure routers to point at these local sources. Agree - better to put that on servers running than burdening routers with NTP functionality in addition to other daily tasks. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR 901 EoMPLS
On 19/11/2013 12:45, Adam Vitkovsky wrote: Is the 901 that different form 903 yes. asr901 == based on me3600 hardware and runs vanilla ios, asr903 == based on asr1k hardware and runs ios-xe, and can also act as an ASR9k nV satellite. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IPv6 filters
On 19/11/2013 15:23, Scott Voll wrote: So how do you keep IPv6 off of IPv4? if you are running dual stack shouldn't it just go out it's native protocol? unless you configured no bgp default ipv4-unicast on ios, older versions of ios will default to exchanging ipv4 prefixes over ipv6. I don't even know if this is still the default because I've been using no bgp default ipv4-unicast for several years. In any case, it's better to be explicit about what AFIs you want sent over what protocols. Except for one or two peculiar non-routing cases, I religiously keep them apart. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IPv6 filters
On Tuesday, November 19, 2013 05:48:56 PM Nick Hilliard wrote: unless you configured no bgp default ipv4-unicast on ios, older versions of ios will default to exchanging ipv4 prefixes over ipv6. I don't even know if this is still the default because I've been using no bgp default ipv4-unicast for several years. In any case, it's better to be explicit about what AFIs you want sent over what protocols. Except for one or two peculiar non-routing cases, I religiously keep them apart. I think I pray at the church more often that you do, Nick :-). Seriously, +1. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
On 19/11/2013 13:54, Christina Klam wrote: We have been running 6.2(2) since the summer. In the last six months, I had to return some third-party Cisco compatible twinax cables because they were Invalid on our M2s. And, I just had to swap out some official Cisco SFP-10G-LR because they were version 1 which also do not work with our M2 cards. Can't say I'm surprised. If Cisco is going to do stupid customer-hating stuff like locking transceivers, they ought to expect to shoot themselves in the foot from time to time. Pity that it's the customers who end taking the bullet though. I would love to condemn the product managers who make this sort of rage-inducing decision to an eternity of dealing with 02:00 maintenance windows where you're stuck in a data centre with severe time constraints, the network is down because of transceiver issues and you only have the wrong brand of transceiver to hand, and there's no reason it shouldn't work other than vendor politics. RAGE/ Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR 901 EoMPLS
You're right on the software part (901 = IOS classic, 903 = XE) but the hardware part isn't correct. The asr903 is based on the same forwarding asic as the me3600 and me3800 The asr901 is based on a different forwarding asic than the 903/3600/3800 The asr1k is based on the Cisco QFP network processor and is drastically different from the 901 and 903. On Tue, Nov 19, 2013 at 10:43 AM, Nick Hilliard n...@foobar.org wrote: On 19/11/2013 12:45, Adam Vitkovsky wrote: Is the 901 that different form 903 yes. asr901 == based on me3600 hardware and runs vanilla ios, asr903 == based on asr1k hardware and runs ios-xe, and can also act as an ASR9k nV satellite. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR 901 EoMPLS
Before XE 3.11 (15.3.4S) the behavior is: 1) On EVC-BD, if no L2CP configuration is done, then tagged BPDUs are dropped and untagged BPDUs are peered 2) On EVC-Xconnect, by default, the tagged BPDUs are dropped and untagged BPDUs are forwarded 3) On Port-Xconnect, the tagged BPDUs are dropped and untagged BPDUs are forwarded This is not documented clearly and I'll work to get the external documentation updated to reflect this and create a longer term goal to more clearly state the behavior of control traffic on xconnect ports in different configurations on different platforms. On Mon, Nov 18, 2013 at 8:11 AM, Fredrik Vöcks fredrik.vo...@bredband2.sewrote: 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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR 901 EoMPLS
ASR901 is Broadcom inside. On Tue, Nov 19, 2013 at 8:02 AM, Pete Lumbis alum...@gmail.com wrote: You're right on the software part (901 = IOS classic, 903 = XE) but the hardware part isn't correct. The asr903 is based on the same forwarding asic as the me3600 and me3800 The asr901 is based on a different forwarding asic than the 903/3600/3800 The asr1k is based on the Cisco QFP network processor and is drastically different from the 901 and 903. On Tue, Nov 19, 2013 at 10:43 AM, Nick Hilliard n...@foobar.org wrote: On 19/11/2013 12:45, Adam Vitkovsky wrote: Is the 901 that different form 903 yes. asr901 == based on me3600 hardware and runs vanilla ios, asr903 == based on asr1k hardware and runs ios-xe, and can also act as an ASR9k nV satellite. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
Hi, On Tue, Nov 19, 2013 at 03:59:06PM +, Nick Hilliard wrote: I would love to condemn the product managers who make this sort of rage-inducing decision to an eternity of dealing with 02:00 maintenance windows where you're stuck in a data centre with severe time constraints, the network is down because of transceiver issues and you only have the wrong brand of transceiver to hand, and there's no reason it shouldn't work other than vendor politics. RAGE/ Amen. (The service unsupported-transceiver thing used to be a reasonable compromise. It gave customers the freedom of choice, while making it clear that TAC could refuse to support issues with 3rd party transceivers. Sorry to hear that the Nexus BU is now competing with the Stupid BU for the most annoying BU CY2013 title...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpCJCKuNK0qX.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
Christina, are you running on sup-2E ? We are running many non-CISCO transceivers on nexus 7k running 6.1.3 but when I did the upgrade to 6.2.2a NO GOOD. We also ran across issue with 6.2.2a on sup-2E that you cannot overwrite slot0: file. Delete but no overwrite. TAC case open. Jeff On Nov 19, 2013, at 8:54 AM, Christina Klam ck...@ias.edu wrote: Jeff, We have been running 6.2(2) since the summer. In the last six months, I had to return some third-party Cisco compatible twinax cables because they were Invalid on our M2s. And, I just had to swap out some official Cisco SFP-10G-LR because they were version 1 which also do not work with our M2 cards. As it has been awhile since we ran 6.1 so I do not know if the issue began with 6.2 or not. I do not know if this helps. But, I feel better after venting. :-) -- Christina Klam Network Engineer Institute for Advanced Study Email: ck...@ias.edu Einstein Drive Telephone: 609-734-8154 Princeton, NJ 08540 Fax: 609-951-4418 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
I don’t see the “service unsupported-transceiver” command nor does it run (in case its hidden). That would imply its not there on 7k 6.1.3 or 6.2.2a. Can you imagine us doing an upgrade on one of our core 7k and having all the transceivers fail. Jeff On Nov 19, 2013, at 12:25 PM, Gert Doering g...@greenie.muc.de wrote: Hi, On Tue, Nov 19, 2013 at 03:59:06PM +, Nick Hilliard wrote: I would love to condemn the product managers who make this sort of rage-inducing decision to an eternity of dealing with 02:00 maintenance windows where you're stuck in a data centre with severe time constraints, the network is down because of transceiver issues and you only have the wrong brand of transceiver to hand, and there's no reason it shouldn't work other than vendor politics. RAGE/ Amen. (The service unsupported-transceiver thing used to be a reasonable compromise. It gave customers the freedom of choice, while making it clear that TAC could refuse to support issues with 3rd party transceivers. Sorry to hear that the Nexus BU is now competing with the Stupid BU for the most annoying BU CY2013 title...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
Jeff, They are plain ole N7K-SUP2 with N7K-M224XP-23L line cards. I just accepted the fact that we will have to pay the Cisco tax. Regards, Christina On 11/19/2013 02:45 PM, Jeffrey G. Fitzwater wrote: Christina, are you running on sup-2E ? We are running many non-CISCO transceivers on nexus 7k running 6.1.3 but when I did the upgrade to 6.2.2a NO GOOD. We also ran across issue with 6.2.2a on sup-2E that you cannot overwrite slot0: file. Delete but no overwrite. TAC case open. Jeff On Nov 19, 2013, at 8:54 AM, Christina Klam ck...@ias.edu wrote: Jeff, We have been running 6.2(2) since the summer. In the last six months, I had to return some third-party Cisco compatible twinax cables because they were Invalid on our M2s. And, I just had to swap out some official Cisco SFP-10G-LR because they were version 1 which also do not work with our M2 cards. As it has been awhile since we ran 6.1 so I do not know if the issue began with 6.2 or not. I do not know if this helps. But, I feel better after venting. :-) -- Christina Klam Network Engineer Institute for Advanced Study Email: ck...@ias.edu Einstein Drive Telephone: 609-734-8154 Princeton, NJ 08540 Fax: 609-951-4418 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Christina Klam Network Engineer Institute for Advanced Study Email: ck...@ias.edu Einstein Drive Telephone: 609-734-8154 Princeton, NJ 08540 Fax: 609-951-4418 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
Did you happen to try to overwrite a slot0:file , even though this is unrelated to the transceiver issue. In my case its just another bug with 6.2.2a on sup-2E. Jeff On Nov 19, 2013, at 2:59 PM, Christina Klam ck...@ias.edu wrote: Jeff, They are plain ole N7K-SUP2 with N7K-M224XP-23L line cards. I just accepted the fact that we will have to pay the Cisco tax. Regards, Christina On 11/19/2013 02:45 PM, Jeffrey G. Fitzwater wrote: Christina, are you running on sup-2E ? We are running many non-CISCO transceivers on nexus 7k running 6.1.3 but when I did the upgrade to 6.2.2a NO GOOD. We also ran across issue with 6.2.2a on sup-2E that you cannot overwrite slot0: file. Delete but no overwrite. TAC case open. Jeff On Nov 19, 2013, at 8:54 AM, Christina Klam ck...@ias.edu wrote: Jeff, We have been running 6.2(2) since the summer. In the last six months, I had to return some third-party Cisco compatible twinax cables because they were Invalid on our M2s. And, I just had to swap out some official Cisco SFP-10G-LR because they were version 1 which also do not work with our M2 cards. As it has been awhile since we ran 6.1 so I do not know if the issue began with 6.2 or not. I do not know if this helps. But, I feel better after venting. :-) -- Christina Klam Network Engineer Institute for Advanced Study Email: ck...@ias.edu Einstein Drive Telephone: 609-734-8154 Princeton, NJ 08540 Fax: 609-951-4418 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Christina Klam Network Engineer Institute for Advanced Study Email: ck...@ias.edu Einstein Drive Telephone: 609-734-8154 Princeton, NJ 08540 Fax: 609-951-4418 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
service unsupported-transceiver works for us on 6.2.2a. On Tue, Nov 19, 2013 at 2:49 PM, Jeffrey G. Fitzwater jf...@princeton.eduwrote: I don’t see the “service unsupported-transceiver” command nor does it run (in case its hidden). That would imply its not there on 7k 6.1.3 or 6.2.2a. Can you imagine us doing an upgrade on one of our core 7k and having all the transceivers fail. Jeff On Nov 19, 2013, at 12:25 PM, Gert Doering g...@greenie.muc.de wrote: Hi, On Tue, Nov 19, 2013 at 03:59:06PM +, Nick Hilliard wrote: I would love to condemn the product managers who make this sort of rage-inducing decision to an eternity of dealing with 02:00 maintenance windows where you're stuck in a data centre with severe time constraints, the network is down because of transceiver issues and you only have the wrong brand of transceiver to hand, and there's no reason it shouldn't work other than vendor politics. RAGE/ Amen. (The service unsupported-transceiver thing used to be a reasonable compromise. It gave customers the freedom of choice, while making it clear that TAC could refuse to support issues with 3rd party transceivers. Sorry to hear that the Nexus BU is now competing with the Stupid BU for the most annoying BU CY2013 title...) gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
What sup and what EPLD ver. Interesting ! Jeff On Nov 19, 2013, at 3:10 PM, Tim Durack tdur...@gmail.commailto:tdur...@gmail.com wrote: service unsupported-transceiver works for us on 6.2.2a. On Tue, Nov 19, 2013 at 2:49 PM, Jeffrey G. Fitzwater jf...@princeton.edumailto:jf...@princeton.edu wrote: I don’t see the “service unsupported-transceiver” command nor does it run (in case its hidden). That would imply its not there on 7k 6.1.3 or 6.2.2a. Can you imagine us doing an upgrade on one of our core 7k and having all the transceivers fail. Jeff On Nov 19, 2013, at 12:25 PM, Gert Doering g...@greenie.muc.demailto:g...@greenie.muc.de wrote: Hi, On Tue, Nov 19, 2013 at 03:59:06PM +, Nick Hilliard wrote: I would love to condemn the product managers who make this sort of rage-inducing decision to an eternity of dealing with 02:00 maintenance windows where you're stuck in a data centre with severe time constraints, the network is down because of transceiver issues and you only have the wrong brand of transceiver to hand, and there's no reason it shouldn't work other than vendor politics. RAGE/ Amen. (The service unsupported-transceiver thing used to be a reasonable compromise. It gave customers the freedom of choice, while making it clear that TAC could refuse to support issues with 3rd party transceivers. Sorry to hear that the Nexus BU is now competing with the Stupid BU for the most annoying BU CY2013 title...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/http://www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.demailto:g...@greenie.muc.de fax: +49-89-35655025tel:%2B49-89-35655025 g...@net.informatik.tu-muenchen.demailto:g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
My error. Yes it does exist. Not sure what I did wrong. i am going back and try new code with command. Thanks Jeff On Nov 19, 2013, at 3:10 PM, Tim Durack tdur...@gmail.commailto:tdur...@gmail.com wrote: service unsupported-transceiver works for us on 6.2.2a. On Tue, Nov 19, 2013 at 2:49 PM, Jeffrey G. Fitzwater jf...@princeton.edumailto:jf...@princeton.edu wrote: I don’t see the “service unsupported-transceiver” command nor does it run (in case its hidden). That would imply its not there on 7k 6.1.3 or 6.2.2a. Can you imagine us doing an upgrade on one of our core 7k and having all the transceivers fail. Jeff On Nov 19, 2013, at 12:25 PM, Gert Doering g...@greenie.muc.demailto:g...@greenie.muc.de wrote: Hi, On Tue, Nov 19, 2013 at 03:59:06PM +, Nick Hilliard wrote: I would love to condemn the product managers who make this sort of rage-inducing decision to an eternity of dealing with 02:00 maintenance windows where you're stuck in a data centre with severe time constraints, the network is down because of transceiver issues and you only have the wrong brand of transceiver to hand, and there's no reason it shouldn't work other than vendor politics. RAGE/ Amen. (The service unsupported-transceiver thing used to be a reasonable compromise. It gave customers the freedom of choice, while making it clear that TAC could refuse to support issues with 3rd party transceivers. Sorry to hear that the Nexus BU is now competing with the Stupid BU for the most annoying BU CY2013 title...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/http://www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.demailto:g...@greenie.muc.de fax: +49-89-35655025tel:%2B49-89-35655025 g...@net.informatik.tu-muenchen.demailto:g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
Just talked to my SE. He reports that, in previous versions, some 3rd party transceivers (mine included, apparently) work without service unsupported-transceiver. This was 'fixed' in 6.2(2)... Thanks for reporting this, Jeff. We'll be upgrading soon and this saved me from a big headache. -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeffrey G. Fitzwater Sent: Tuesday, November 19, 2013 2:33 PM To: Tim Durack Cc: Gert Doering; Christina Klam; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E My error. Yes it does exist. Not sure what I did wrong. i am going back and try new code with command. Thanks Jeff On Nov 19, 2013, at 3:10 PM, Tim Durack tdur...@gmail.commailto:tdur...@gmail.com wrote: service unsupported-transceiver works for us on 6.2.2a. On Tue, Nov 19, 2013 at 2:49 PM, Jeffrey G. Fitzwater jf...@princeton.edumailto:jf...@princeton.edu wrote: I don't see the service unsupported-transceiver command nor does it run (in case its hidden). That would imply its not there on 7k 6.1.3 or 6.2.2a. Can you imagine us doing an upgrade on one of our core 7k and having all the transceivers fail. Jeff On Nov 19, 2013, at 12:25 PM, Gert Doering g...@greenie.muc.demailto:g...@greenie.muc.de wrote: Hi, On Tue, Nov 19, 2013 at 03:59:06PM +, Nick Hilliard wrote: I would love to condemn the product managers who make this sort of rage-inducing decision to an eternity of dealing with 02:00 maintenance windows where you're stuck in a data centre with severe time constraints, the network is down because of transceiver issues and you only have the wrong brand of transceiver to hand, and there's no reason it shouldn't work other than vendor politics. RAGE/ Amen. (The service unsupported-transceiver thing used to be a reasonable compromise. It gave customers the freedom of choice, while making it clear that TAC could refuse to support issues with 3rd party transceivers. Sorry to hear that the Nexus BU is now competing with the Stupid BU for the most annoying BU CY2013 title...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/http://www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.demailto:g...@greenie.muc.de fax: +49-89-35655025tel:%2B49-89-35655025 g...@net.informatik.tu-muenchen.demailto:g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
In 6.1.3 I never had to add the command; but now with 6.2.2a I have to. Are we having fun yet.. Jeff On Nov 19, 2013, at 3:46 PM, James Slepicka (c-nsp) cisco-...@slepicka.net wrote: Just talked to my SE. He reports that, in previous versions, some 3rd party transceivers (mine included, apparently) work without service unsupported-transceiver. This was 'fixed' in 6.2(2)... Thanks for reporting this, Jeff. We'll be upgrading soon and this saved me from a big headache. -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeffrey G. Fitzwater Sent: Tuesday, November 19, 2013 2:33 PM To: Tim Durack Cc: Gert Doering; Christina Klam; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E My error. Yes it does exist. Not sure what I did wrong. i am going back and try new code with command. Thanks Jeff On Nov 19, 2013, at 3:10 PM, Tim Durack tdur...@gmail.commailto:tdur...@gmail.com wrote: service unsupported-transceiver works for us on 6.2.2a. On Tue, Nov 19, 2013 at 2:49 PM, Jeffrey G. Fitzwater jf...@princeton.edumailto:jf...@princeton.edu wrote: I don't see the service unsupported-transceiver command nor does it run (in case its hidden). That would imply its not there on 7k 6.1.3 or 6.2.2a. Can you imagine us doing an upgrade on one of our core 7k and having all the transceivers fail. Jeff On Nov 19, 2013, at 12:25 PM, Gert Doering g...@greenie.muc.demailto:g...@greenie.muc.de wrote: Hi, On Tue, Nov 19, 2013 at 03:59:06PM +, Nick Hilliard wrote: I would love to condemn the product managers who make this sort of rage-inducing decision to an eternity of dealing with 02:00 maintenance windows where you're stuck in a data centre with severe time constraints, the network is down because of transceiver issues and you only have the wrong brand of transceiver to hand, and there's no reason it shouldn't work other than vendor politics. RAGE/ Amen. (The service unsupported-transceiver thing used to be a reasonable compromise. It gave customers the freedom of choice, while making it clear that TAC could refuse to support issues with 3rd party transceivers. Sorry to hear that the Nexus BU is now competing with the Stupid BU for the most annoying BU CY2013 title...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/http://www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.demailto:g...@greenie.muc.de fax: +49-89-35655025tel:%2B49-89-35655025 g...@net.informatik.tu-muenchen.demailto:g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
Does the command exist in 6.1(3)? I don't have a box that I can test with. -Original Message- From: Jeffrey G. Fitzwater [mailto:jf...@princeton.edu] Sent: Tuesday, November 19, 2013 3:19 PM To: James Slepicka (c-nsp) Cc: Jeffrey G. Fitzwater; Tim Durack; Gert Doering; Christina Klam; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E In 6.1.3 I never had to add the command; but now with 6.2.2a I have to. Are we having fun yet.. Jeff On Nov 19, 2013, at 3:46 PM, James Slepicka (c-nsp) cisco-...@slepicka.net wrote: Just talked to my SE. He reports that, in previous versions, some 3rd party transceivers (mine included, apparently) work without service unsupported-transceiver. This was 'fixed' in 6.2(2)... Thanks for reporting this, Jeff. We'll be upgrading soon and this saved me from a big headache. -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeffrey G. Fitzwater Sent: Tuesday, November 19, 2013 2:33 PM To: Tim Durack Cc: Gert Doering; Christina Klam; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E My error. Yes it does exist. Not sure what I did wrong. i am going back and try new code with command. Thanks Jeff On Nov 19, 2013, at 3:10 PM, Tim Durack tdur...@gmail.commailto:tdur...@gmail.com wrote: service unsupported-transceiver works for us on 6.2.2a. On Tue, Nov 19, 2013 at 2:49 PM, Jeffrey G. Fitzwater jf...@princeton.edumailto:jf...@princeton.edu wrote: I don't see the service unsupported-transceiver command nor does it run (in case its hidden). That would imply its not there on 7k 6.1.3 or 6.2.2a. Can you imagine us doing an upgrade on one of our core 7k and having all the transceivers fail. Jeff On Nov 19, 2013, at 12:25 PM, Gert Doering g...@greenie.muc.demailto:g...@greenie.muc.de wrote: Hi, On Tue, Nov 19, 2013 at 03:59:06PM +, Nick Hilliard wrote: I would love to condemn the product managers who make this sort of rage-inducing decision to an eternity of dealing with 02:00 maintenance windows where you're stuck in a data centre with severe time constraints, the network is down because of transceiver issues and you only have the wrong brand of transceiver to hand, and there's no reason it shouldn't work other than vendor politics. RAGE/ Amen. (The service unsupported-transceiver thing used to be a reasonable compromise. It gave customers the freedom of choice, while making it clear that TAC could refuse to support issues with 3rd party transceivers. Sorry to hear that the Nexus BU is now competing with the Stupid BU for the most annoying BU CY2013 title...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/http://www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.demailto:g...@greenie.muc.de fax: +49-89-35655025tel:%2B49-89-35655025 g...@net.informatik.tu-muenchen.demailto:g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
It does accept the command in 6.1.3, but non CISCO transceivers still work without running it, and its NOT in the config even with the command “show run all” if I run the command “no service unsupported-transceiver” and do an interface SHUT NO SHUT the non CISCO still work. Hmmm…. So CISCO must have changed something in 6.2.2a to require the command for non CISCO transceivers. This makes me a little nervous running 6.2.2a with this caveat. Sure I can save it in config, but what happens in next release. I’ll discuss this with my SE and see what they say. Jeff On Nov 19, 2013, at 4:24 PM, James Slepicka (c-nsp) cisco-...@slepicka.net wrote: Does the command exist in 6.1(3)? I don't have a box that I can test with. -Original Message- From: Jeffrey G. Fitzwater [mailto:jf...@princeton.edu] Sent: Tuesday, November 19, 2013 3:19 PM To: James Slepicka (c-nsp) Cc: Jeffrey G. Fitzwater; Tim Durack; Gert Doering; Christina Klam; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E In 6.1.3 I never had to add the command; but now with 6.2.2a I have to. Are we having fun yet.. Jeff On Nov 19, 2013, at 3:46 PM, James Slepicka (c-nsp) cisco-...@slepicka.net wrote: Just talked to my SE. He reports that, in previous versions, some 3rd party transceivers (mine included, apparently) work without service unsupported-transceiver. This was 'fixed' in 6.2(2)... Thanks for reporting this, Jeff. We'll be upgrading soon and this saved me from a big headache. -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeffrey G. Fitzwater Sent: Tuesday, November 19, 2013 2:33 PM To: Tim Durack Cc: Gert Doering; Christina Klam; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E My error. Yes it does exist. Not sure what I did wrong. i am going back and try new code with command. Thanks Jeff On Nov 19, 2013, at 3:10 PM, Tim Durack tdur...@gmail.commailto:tdur...@gmail.com wrote: service unsupported-transceiver works for us on 6.2.2a. On Tue, Nov 19, 2013 at 2:49 PM, Jeffrey G. Fitzwater jf...@princeton.edumailto:jf...@princeton.edu wrote: I don't see the service unsupported-transceiver command nor does it run (in case its hidden). That would imply its not there on 7k 6.1.3 or 6.2.2a. Can you imagine us doing an upgrade on one of our core 7k and having all the transceivers fail. Jeff On Nov 19, 2013, at 12:25 PM, Gert Doering g...@greenie.muc.demailto:g...@greenie.muc.de wrote: Hi, On Tue, Nov 19, 2013 at 03:59:06PM +, Nick Hilliard wrote: I would love to condemn the product managers who make this sort of rage-inducing decision to an eternity of dealing with 02:00 maintenance windows where you're stuck in a data centre with severe time constraints, the network is down because of transceiver issues and you only have the wrong brand of transceiver to hand, and there's no reason it shouldn't work other than vendor politics. RAGE/ Amen. (The service unsupported-transceiver thing used to be a reasonable compromise. It gave customers the freedom of choice, while making it clear that TAC could refuse to support issues with 3rd party transceivers. Sorry to hear that the Nexus BU is now competing with the Stupid BU for the most annoying BU CY2013 title...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/http://www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.demailto:g...@greenie.muc.de fax: +49-89-35655025tel:%2B49-89-35655025 g...@net.informatik.tu-muenchen.demailto:g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
On Nov 19, 2013, at 10:59 AM, Nick Hilliard n...@foobar.org wrote: On 19/11/2013 13:54, Christina Klam wrote: We have been running 6.2(2) since the summer. In the last six months, I had to return some third-party Cisco compatible twinax cables because they were Invalid on our M2s. And, I just had to swap out some official Cisco SFP-10G-LR because they were version 1 which also do not work with our M2 cards. Can't say I'm surprised. If Cisco is going to do stupid customer-hating stuff like locking transceivers, they ought to expect to shoot themselves in the foot from time to time. Pity that it's the customers who end taking the bullet though. The failure of Cisco to support their own first party optics correctly is a significant problem we have faced. We’ve done many rounds with them on this topic and it’s not gone well for them. The optics folks have been borderline arrogant and ignorant of the software-side problems that exist. My suggestion: Speak with your wallet and discontinue purchasing them. You can save lots of $$$. When you type “show” commands on a device, make sure you map them back to the SFF-8472 MSA fields. If the software platform doesn’t display all of them, insist it’s basic support of the optics and their optics and software are substandard. Regarding Twinax cables. You really shouldn’t need these as the optics are fairly inexpensive via 3rd party, and you can use a fiber cable for “cheap” as well. Look at places like monoprice, champion one, osihardware and many others out there. Most places have better warranty support than Cisco with paid support in my experience. - Jared ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
Second that. The more people buy 3rd party (coded if you want) the better. Vendors only listen to sales. On Tuesday, November 19, 2013, Jared Mauch wrote: On Nov 19, 2013, at 10:59 AM, Nick Hilliard n...@foobar.orgjavascript:; wrote: On 19/11/2013 13:54, Christina Klam wrote: We have been running 6.2(2) since the summer. In the last six months, I had to return some third-party Cisco compatible twinax cables because they were Invalid on our M2s. And, I just had to swap out some official Cisco SFP-10G-LR because they were version 1 which also do not work with our M2 cards. Can't say I'm surprised. If Cisco is going to do stupid customer-hating stuff like locking transceivers, they ought to expect to shoot themselves in the foot from time to time. Pity that it's the customers who end taking the bullet though. The failure of Cisco to support their own first party optics correctly is a significant problem we have faced. We’ve done many rounds with them on this topic and it’s not gone well for them. The optics folks have been borderline arrogant and ignorant of the software-side problems that exist. My suggestion: Speak with your wallet and discontinue purchasing them. You can save lots of $$$. When you type “show” commands on a device, make sure you map them back to the SFF-8472 MSA fields. If the software platform doesn’t display all of them, insist it’s basic support of the optics and their optics and software are substandard. Regarding Twinax cables. You really shouldn’t need these as the optics are fairly inexpensive via 3rd party, and you can use a fiber cable for “cheap” as well. Look at places like monoprice, champion one, osihardware and many others out there. Most places have better warranty support than Cisco with paid support in my experience. - Jared ___ cisco-nsp mailing list cisco-nsp@puck.nether.net javascript:; https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Third party transceivers that fail only with new, NX-OS 6.2.2a on sup-2E
On 11/19/2013 5:51 PM, Tim Durack wrote: Second that. The more people buy 3rd party (coded if you want) the better. Vendors only listen to sales. +1 to that. We recently ran across some 3rd-party CODED DOM-supporting optics that have worked (thus far) in both Ciscos and Brocades. When you can issue a show int trans and get results from 3rd-parties while Ciscos remain silent, it speaks volumes :) We still keep branded spares for any surprise issues. But I don't think we would have enough to survive a software upgrade enforced transceiver refusal such as the one being discussed... so I remain skeptical, and disgruntled over the whole branded issue. Could you imagine if you could stick a vendor PROM in an ethernet cable? We don't tolerate such silliness with any other interfaces... Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] NTP Sources placement in MPLS network
Hi Mark, Jared, Do you really think enabling NTP service on routers can burdening them. I mean in hierarchical way where RR and directly connected with ntp sources and then all PEs use RR as ntp master and CEs further down use PEs as NTP master? Jared, Quick question, why you think anycast IP on NTP servers is better then configuring multiple individual servers on devices. One advantage of anycast i can think is since (i believe) device choose ntp that has better stratum and if its same it choose ntp who respond first if multiple ntp servers are configured so if anycast ip is used, device will reach only to closest device. I try to read about ntp with anycast ip and found a doc that talk about some risk that i couldn't understand. below is the snippet and source. can you please comment on this please? NTP will also normally work with Anycast. A small risk with NTP is that it generally requires at least two packets from both server and client to get a proper synchronization. If the server fails after the first packet, it will take an extra packet to synchronize with the next available NTP server. The Simple Network Time Protocol (SNTP) does not have this problem. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.6367rep=rep1type=pdf page-8 Regards Regards On Tue, Nov 19, 2013 at 10:31 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Tuesday, November 19, 2013 02:02:43 PM Jared Mauch wrote: We have servers in each location with NTP synced to local stratum 1 or 2 clocks. Customers are given an anycast ip that points to these for time sources. We configure routers to point at these local sources. Agree - better to put that on servers running than burdening routers with NTP functionality in addition to other daily tasks. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR A9K-8T-L certain ports limited to 8 Gbps.
What framing mode are you running and what is the underlying transmission? I have seen this before on 10G circuits running in wanphy mode and the only fix was to get better transmission (ie. not an STM-64c) and run lanphy :) McDonald On Tue, Nov 19, 2013 at 9:07 PM, bas kilo...@gmail.com wrote: Dear All, We have a stubborn problem with one of our ASR9Ks. A couple of upstream ports are limited to 8Gbps egress traffic, while others are not affected. It is a 9010 chassis with two RSP-4Gs, and eight A9K-8T-L cards. Of every card the first three ports are used for upstream (egress traffic), and the following five ports are configured for downstream (ingress) There is no specific QoS configured on either side. The RSPs are running 4.2.3. We've swapped both RSPs, and several linecards, however nothing seems to change the behaviour. rrd graph here http://imgur.com/Td4KSGB Has anyone had experience with a situation like this? Thanks, Bas ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Bad routes in MPLS
Hi all, We've been having an issue recently where we have routes on PE routers that look to be ok, but are not forwarding any traffic. Usually this can be resolved by doing clear ip route vrf vrf_name ip_prefix which causes the PE to re-learn the route and everything works again. This problem appears to be triggered by routing flap/changes. This can either be within a vrf (ie. PE-CE, BGP or OSPF) or our core IGP (PE-PE, OSPF). When it is a PE-CE route change it seems to only affect routes within that vrf, but when it is an IGP topology change it can affect pretty much any vrf. My initial though was that something is wrong in the stuff that is underlying the routing (eg. MPLS, LDP, CEF) and so I started looking, but can't see anything that is different from when it works and when it doesn't work. I've worked my way through most of show ip bgp vpnv4, show mpls forwarding-table, show mpls ip binding, etc. You can also work around the problem by adding a more specific route, which would bypass the dodgy route in question (but not fix the route, so that when the more specific route is removed it goes back to not working). I've also found that sometimes clearing the route (clear ip route ...) doesn't work, in which case the best way I've found to resolve that is to create a static route exactly the same on the PE but with a destination of null0, then remove this route again. This again causes the bad route to be flushed and replaced with one that now works. This has been happening for a couple of weeks, but was typically only affecting a prefix here or there and so we thought it just a bad quirk, but more recently we have had some occasions where it has caused widespread havoc affecting a good portion of routes on a single PE. The boxes in question are 7609 with dual sup720-3B and a variety of card (mostly SIP-400 + SPA-GE ES20+) running 12.2(33)SRD4. I'm aware the software is a bit out of date and we are looking to schedule a maintenance window for upgrading (at this stage a week away from now). The boxes are not heavily loaded from a CPU, memory or traffic perspective. Any thoughts on where I might look to try and see an actual error (ie. something corrupt) or any other troubleshooting that could be done. I have opened a case with TAC (and as per recent thread, OMFG was that PAINFUL !) and will see where that goes. I imagine their first response might be upgrade/reboot but I'm hoping not and they might have some sensible suggestions. Happy to post output of some of the troubleshooting I've already done, but thought that would just add a heap of extra information to this post and wuld just cause people's eye's to glaze over. Thanks, Tony. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] NTP Sources placement in MPLS network
On Nov 19, 2013, at 6:01 PM, Yham yhamee...@gmail.com wrote: Hi Mark, Jared, Do you really think enabling NTP service on routers can burdening them. I mean in hierarchical way where RR and directly connected with ntp sources and then all PEs use RR as ntp master and CEs further down use PEs as NTP master? Everything you ask a router to do burdens it, including adding new prefixes, increasing traffic through natural growth and other things. The actual impact will clearly depend on the platforms involved. As both Cisco Juniper-NSP are copied, it's hard to give you an accurate statement as each vendor does something different. Jared, Quick question, why you think anycast IP on NTP servers is better then configuring multiple individual servers on devices. One advantage of anycast i can think is since (i believe) device choose ntp that has better stratum and if its same it choose ntp who respond first if multiple ntp servers are configured so if anycast ip is used, device will reach only to closest device. There's many reasons why. I didn't say it was better, I said what we were doing. :) but here's a list of reasons: 1) If you're not already doing centralized control of devices/configs, using the same IP address will minimize the impact should the host change. 2) Most places don't do #1, infact they often find devices they have no access to, must password recover it, don't have SNMP stats, netflow, CPU usage, or any other useful data. I try to read about ntp with anycast ip and found a doc that talk about some risk that i couldn't understand. below is the snippet and source. can you please comment on this please? NTP will also normally work with Anycast. A small risk with NTP is that it generally requires at least two packets from both server and client to get a proper synchronization. If the server fails after the first packet, it will take an extra packet to synchronize with the next available NTP server. The Simple Network Time Protocol (SNTP) does not have this problem. Sure, this depends on how you operate your network. If you do per-packet load balancing this may happen if you don't have an ECMP path. The same is true if you improperly use a load balancer or other devices. Many technology can be used well, often it's used until it just works. I'm sure everyone on-list has a story of getting things to the point of just working then leave it alone without truly understanding what they fixed, or what was truly different. Perhaps you're perfect and using perfect software and didn't see anything like that, but I see it all the time. You just optimize based on what is deployable and feasible. If you have every device fully under your control, in configuration management and proper tools to audit and template then you can deploy something else. Whenever possible: Template, Automate and use existing tools to audit. - Jared http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.6367rep=rep1type=pdf page-8 Regards Regards On Tue, Nov 19, 2013 at 10:31 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Tuesday, November 19, 2013 02:02:43 PM Jared Mauch wrote: We have servers in each location with NTP synced to local stratum 1 or 2 clocks. Customers are given an anycast ip that points to these for time sources. We configure routers to point at these local sources. Agree - better to put that on servers running than burdening routers with NTP functionality in addition to other daily tasks. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco bug locator?
Does anyone have a current URL for the Cisco bug toolkit that works the right way around? The link on their website now only allows you to enter a bug ID. I am looking for the original bug tool that is actually useful, where you specify the IOS version, platform, and nature of the bug, and it then gives you the bug ID. This one is kind of useless. https://tools.cisco.com/bugsearch -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco bug locator?
On Tue, 19 Nov 2013, Jay Hennigan wrote: Does anyone have a current URL for the Cisco bug toolkit that works the right way around? The link on their website now only allows you to enter a bug ID. I am looking for the original bug tool that is actually useful, where you specify the IOS version, platform, and nature of the bug, and it then gives you the bug ID. This one is kind of useless. https://tools.cisco.com/bugsearch Cisco has over the past years made their public bug information more and more useless, mostly by not documenting their bugs publically in a useful manner. That they would then cripple the search function would be no surprise to me. I have numerous times had to ask people within Cisco who have access to their internal tools for clarification on bugs in order to actually gain useful knowledge about what the bug actually is. I also had to numerous times ask cisco to actually publish the bug at all, just to be able to evaluate if a SMU should be applied or not. Yes, they released SMUs without the bug ID the SMU fixed being publically available. This has happened several times. So complain to your account team and give feedback on their website. Only by customers complaining will we see improvement. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco bug locator?
On 11/19/2013 9:40 PM, Mikael Abrahamsson wrote: So complain to your account team and give feedback on their website. Only by customers complaining will we see improvement. Don't hold your breath. I've been bitching since they started the whole Web 2.0 / HTML5 / Java nonsense migration, and it's only getting WORSE with EVERY new version. Opening a TAC case now presents you with no less than FIVE Java authentication warning windows, if you have the latest Java. Jeff ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco bug locator?
I can't comment on the state of the new bug toolkit (vomit) but to Mikaels point: Yes, there are crappy bugs. I see them every day. They are written by humans with the information available at the time. TAC needs to do a better job of following up on bugs after they are resolved to ensure the information in the bug reflects the actual problem and symptom that customers can see. It's a work in progress and sadly will never be perfect (since again, it's written by humans). I would say you should ALWAYS open a TAC case to fix bugs that you worry you are hitting. TAC engineers have the resources to find further details and update the bug so it's readable (yes, this is a pain in the ass. why should you have to open a case to translate a bug to English? Again, bugs written by humans, generally with limited information at the time of writing). This won't always be an easy process but it's doable. Regards, Pete On Tue, Nov 19, 2013 at 9:40 PM, Mikael Abrahamsson swm...@swm.pp.sewrote: On Tue, 19 Nov 2013, Jay Hennigan wrote: Does anyone have a current URL for the Cisco bug toolkit that works the right way around? The link on their website now only allows you to enter a bug ID. I am looking for the original bug tool that is actually useful, where you specify the IOS version, platform, and nature of the bug, and it then gives you the bug ID. This one is kind of useless. https://tools.cisco.com/bugsearch Cisco has over the past years made their public bug information more and more useless, mostly by not documenting their bugs publically in a useful manner. That they would then cripple the search function would be no surprise to me. I have numerous times had to ask people within Cisco who have access to their internal tools for clarification on bugs in order to actually gain useful knowledge about what the bug actually is. I also had to numerous times ask cisco to actually publish the bug at all, just to be able to evaluate if a SMU should be applied or not. Yes, they released SMUs without the bug ID the SMU fixed being publically available. This has happened several times. So complain to your account team and give feedback on their website. Only by customers complaining will we see improvement. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Third party transceivers on NXOS
Finisar and Avago here in some cases we need more than a -25 dB sensitivity and 3rd party are the only way to go. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Bad routes in MPLS
Generally these kinds of problems are triggered by routing changes. The software that owns the routing table (show ip route/ show ip cef) needs to update the hardware TCAM (show mls cef). This is true of both IP prefixes and MPLS labels. When you issue clear ip route you for the software to hardware programming to happen again, generally avoiding whatever corner case happened previously. This is due to a bug nearly 100% of the time. Tracking down the bug you are hitting can be a huge hassle. I would strongly recommend you upgrade to the latest SRE code (make sure that SRE will support your SIP, I don't remember...) where there have been a ton of fixes in this area and go from there. -Pete On Tue, Nov 19, 2013 at 6:45 PM, Tony td_mi...@yahoo.com wrote: Hi all, We've been having an issue recently where we have routes on PE routers that look to be ok, but are not forwarding any traffic. Usually this can be resolved by doing clear ip route vrf vrf_name ip_prefix which causes the PE to re-learn the route and everything works again. This problem appears to be triggered by routing flap/changes. This can either be within a vrf (ie. PE-CE, BGP or OSPF) or our core IGP (PE-PE, OSPF). When it is a PE-CE route change it seems to only affect routes within that vrf, but when it is an IGP topology change it can affect pretty much any vrf. My initial though was that something is wrong in the stuff that is underlying the routing (eg. MPLS, LDP, CEF) and so I started looking, but can't see anything that is different from when it works and when it doesn't work. I've worked my way through most of show ip bgp vpnv4, show mpls forwarding-table, show mpls ip binding, etc. You can also work around the problem by adding a more specific route, which would bypass the dodgy route in question (but not fix the route, so that when the more specific route is removed it goes back to not working). I've also found that sometimes clearing the route (clear ip route ...) doesn't work, in which case the best way I've found to resolve that is to create a static route exactly the same on the PE but with a destination of null0, then remove this route again. This again causes the bad route to be flushed and replaced with one that now works. This has been happening for a couple of weeks, but was typically only affecting a prefix here or there and so we thought it just a bad quirk, but more recently we have had some occasions where it has caused widespread havoc affecting a good portion of routes on a single PE. The boxes in question are 7609 with dual sup720-3B and a variety of card (mostly SIP-400 + SPA-GE ES20+) running 12.2(33)SRD4. I'm aware the software is a bit out of date and we are looking to schedule a maintenance window for upgrading (at this stage a week away from now). The boxes are not heavily loaded from a CPU, memory or traffic perspective. Any thoughts on where I might look to try and see an actual error (ie. something corrupt) or any other troubleshooting that could be done. I have opened a case with TAC (and as per recent thread, OMFG was that PAINFUL !) and will see where that goes. I imagine their first response might be upgrade/reboot but I'm hoping not and they might have some sensible suggestions. Happy to post output of some of the troubleshooting I've already done, but thought that would just add a heap of extra information to this post and wuld just cause people's eye's to glaze over. Thanks, Tony. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Possible split horizon issue with bgp signalled vpls
I can confirm that CSCuh05321 is 100% fixed in 15.3.3S1a. If you are seeing problems similar to this it is a different issue. On Tue, Nov 19, 2013 at 7:33 AM, Adam Vitkovsky adam.vitkov...@swan.skwrote: That's what I was about to ask as the CSCuh05321 is actually listed under 15.3(3)S caveats not under 15.3(3)S1a so I'd assume it is resolved in S1a already right? adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce Sent: Tuesday, November 19, 2013 12:14 PM To: Jason Lixfeld Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Possible split horizon issue with bgp signalled vpls Hi Jason, CSCuh05321 says it is fixed in the S1 release so would that not mean that it is also in S1a? Nick On 19 Nov 2013, at 03:50, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Just be mindful of CSCuh05321 if you are going to try S1a. If you think you might hit that, I'd suggest moving to static vpls and skip that release until it's fixed. Also, with S1a, look at CSCtl54835 and verify or else your isis adjacencies will break. Sent from my iPhone On Nov 18, 2013, at 10:08 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Just found 1 switch on 15.3(2)S so may be worth a punt and upgrade Nick On 19 Nov 2013, at 02:02, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Issues I was having with BGP signalled VPLS a couple of months ago in 15.3(2)S1 resulted in filing CSCui46390. I'd otherwise suggest trying 15.3(3)S1a to see fix works, but that version seems to have introduced CSCuh05321, so I think that might end badly for you; it did for me :( On Nov 18, 2013, at 3:05 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: 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 AddressVE-ID Local Label Remote LabelS 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 AddressVE-ID Local Label Remote LabelS 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 AddressVE-ID Local Label Remote LabelS 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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Possible split horizon issue with bgp signalled vpls
Any idea why Switch 3 has remote label 28 instead of 48? Do you know if the issue is unidirectional or bidirectional? That is, can Sw2 send to Sw3 but Sw3 can't send back? On Mon, Nov 18, 2013 at 3:05 PM, Nick Ryce n...@fluency.net.uk wrote: 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 AddressVE-ID Local Label Remote LabelS 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 AddressVE-ID Local Label Remote LabelS 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 AddressVE-ID Local Label Remote LabelS 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 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco bug locator?
On Tue, 19 Nov 2013, Pete Lumbis wrote: Yes, there are crappy bugs. I see them every day. They are written by humans with the information available at the time. TAC needs to do a better That is not the problem. If I read a crappy bug description and then contact someone with access to internal cisco systems, the internal description is *much* better. The information is there, it's just not published to customers. (since again, it's written by humans). I would say you should ALWAYS open a TAC case to fix bugs that you worry you are hitting. TAC engineers have the resources to find further details and update the bug so it's readable (yes, this is a pain in the ass. why should you have to open a case to translate a bug to English? Again, bugs written by humans, generally with limited information at the time of writing). This won't always be an easy process but it's doable. 5-10 years ago it was possible to do bug scrubs based on information on CCO. This is no longer possible, now one needs to pay advanced services for their NOS service to be able to do it, just because the customer accessable information just isn't complete enough. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] raspberry pi
Hi Everyone, I'm curious: Does anyone use one or more raspberry pis in their network (for networking related stuff)? What kinds of things are they used for? Thanks, Preston Chilcote ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] raspberry pi
NTP servers out in a wireless network ;-) -- Chris On 20 Nov 2013 08:24, Preston Chilcote (pchilcot) pchil...@cisco.com wrote: Hi Everyone, I'm curious: Does anyone use one or more raspberry pis in their network (for networking related stuff)? What kinds of things are they used for? Thanks, Preston Chilcote ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Catalyst 6500: IPv6-enabled SVIs
My previous e-mail had a wrong subject, so it wasn't displayed in the web version of this thread in various mailing-list archives (e.g. gossamer). Sorry for dup but let me repeat the message. Hope it will be useful for someone who will face the same problem. The reason of that hardware TCAM label capacity issue was ipv6 multicast-routing: Cat6500#sh tcam counts ipv6 Used Free Reserved Labels:(in) 160 352 Labels:(eg) 5 507 Cat6500#conf t Enter configuration commands, one per line. End with CNTL/Z. Cat6500(config)#no ipv6 multicast-routing Cat6500(config)#end Cat6500#sh tcam counts ipv6 Used Free Reserved Labels:(in) 11 501 Labels:(eg) 5 507 I disabled ipv6 multicast-routing on test box with 12.2 SXJ3 and did some quick tests - IPv6 works without any issues. -- vetr ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
