[c-nsp] MAC-to-IP script on IOS
Gents, Have anyone come across a script that could yield the IP address of a given mac-address when invoked on a Layer 3 Router? I would assume that you would have to select the given interface (as it could be any interface) and the router should start arp-ing all hosts on a given subnet returning the result when finished executing the script? Assumptions is that you know the logical subnet where the mac-address reside or maybe it could be invoked with a "all" interface command to run the script on all logical interfaces. Anyone seen it? With best regards, Ulrich Vestergaard B. Hansen ___ 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 Nexus 5548UP w/Fibre Channel
Reset/reload of N5K is very fast right? Regards, Alexander Lim On May 25, 2012, at 5:21 AM, Asbjorn Hojmark - Lists wrote: > On Thu, 24 May 2012 20:30:40 +, you wrote: > >> I'm wondering if anyone has any experience/tips/advice when running >> Fibre Channel on the Nexus 5548UP platform. > > Yeah, we have customers doing that and do that ourselves. > >> I've done a little bit of research, and understand that the FC ports >> have to start at the back end of the chassis, and that to switch a >> port from Ethernet mode over to FC mode, you need to reload the whole >> switch. > > Yeah, currently the ports have to be contiguous, and with FC at the > high end. If you use a module, you don't have to reload the whole > switch when changing the configuration. You can just reset the module. > When running FCoE, you don't have to reset/reload anything. > > To me, FC and FCoE on the N5000s is pretty mature and absolutely > production ready. > > -A > > ___ > 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 Nexus 5548UP w/Fibre Channel
On Thu, 24 May 2012 20:30:40 +, you wrote: > I'm wondering if anyone has any experience/tips/advice when running > Fibre Channel on the Nexus 5548UP platform. Yeah, we have customers doing that and do that ourselves. > I've done a little bit of research, and understand that the FC ports > have to start at the back end of the chassis, and that to switch a > port from Ethernet mode over to FC mode, you need to reload the whole > switch. Yeah, currently the ports have to be contiguous, and with FC at the high end. If you use a module, you don't have to reload the whole switch when changing the configuration. You can just reset the module. When running FCoE, you don't have to reset/reload anything. To me, FC and FCoE on the N5000s is pretty mature and absolutely production ready. -A ___ 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 Nexus 5548UP w/Fibre Channel
Hello, I'm wondering if anyone has any experience/tips/advice when running Fibre Channel on the Nexus 5548UP platform. I've done a little bit of research, and understand that the FC ports have to start at the back end of the chassis, and that to switch a port from Ethernet mode over to FC mode, you need to reload the whole switch. However, I'm wondering if there are any other operational issues anybody has run into (IOS bugs, issues with certain SFPs, things to test/watch out for, etc). We've always had a separate storage fabric from the main data fabric, so it's a new thing to have them both living on the same switch. Thanks and best regards, Christoph Blecker ___ 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] Rapid-PVST and RSTP compatibility
No it's not compatible, there will be problems! Will work only with MSTP, but MSTP is hard to manage: synchronize all VLANs, INSTANCES and Revisions on all Switches ... Important: test the MSTP before in a lab! Gregor > -Original Message- > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- > boun...@puck.nether.net] On Behalf Of Covalciuc Piotr > Sent: Wednesday, May 23, 2012 5:16 PM > To: cisco-nsp@puck.nether.net > Subject: [c-nsp] Rapid-PVST and RSTP compatibility > > Hello, > > We have a network built on CISCO switches with Rapid-PVST. > Now, we want to integrate in the network the DELL PowerConnect > switches, which supports RSTP only. > > Does the Rapid-PVST compatible with RSTP? > > Thank you, > Peter > ___ > 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] Frustration with XR "show interface" and pipe commands
Seems like improved lexical parsing to me actually. Both these worked the same way: sh int | include "up|rate" sh int | utility egrep "up|rate" Where everything enclosed in the quotes is passed to the command. You could also add a trailing space to "up" so that you don't match words like "supressed" sh int | utility egrep "up |rate" ^ Tony On Thu, May 24, 2012 at 10:19 AM, John Neiberger wrote: > Someone asked me how to do something very simple and I'm finding it > very difficult! He wants to do a "show interface" command and show > only lines with "up" or "rate" in it. In IOS, this was simply "show > int | i up|rate". That second pipe for OR does not seem to work in XR > and we can't figure out how to do something this simple. I even tried > piping the command to egrep and frgrep, but couldn't figure out how to > do an OR in a way that XR understands. > > Any ideas how to pipe the output of a command through an "include" > that has an OR operator? > ___ 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] Frustration with XR "show interface" and pipe commands
Hi John, On Thu, 24 May 2012, John Neiberger wrote: > Someone asked me how to do something very simple and I'm finding it > very difficult! He wants to do a "show interface" command and show > only lines with "up" or "rate" in it. In IOS, this was simply "show > int | i up|rate". That second pipe for OR does not seem to work in XR > and we can't figure out how to do something this simple. I even tried > piping the command to egrep and frgrep, but couldn't figure out how to > do an OR in a way that XR understands. > > Any ideas how to pipe the output of a command through an "include" > that has an OR operator? sh interface | i "up|rate" -Ronan ___ 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] Lot of input errors on a NPE-G1 interface
Think about the buffering on a chassis like a 7200 like this. You have 2 buffers on input, the RX ring (a hardware buffer), and the input queue (a software buffer) A packet comes in on the wire, and goes into the RX ring. That generates a CPU interrupt. The CPU needs to finish its current task then go address the interrupt. It takes the packet off the RX ring and puts it into the input queue. The CPU then takes the packet from the input queue, applies ACLs/NAT/etc to it before deciding if/how to forward it. Now, keep in mind that a 7200 only has an RX ring of *128*. Worst-case at 64 byte packets that's only 8192 bytes of hardware buffer space. At 1gb/sec (say a small burst) that only gives the CPU about 60 *Microseconds* to finish what it's doing and grab that first packet off the RX ring before the queue fills up and you get an overrun. The only real fixes to this are 1) Even out the traffic to remove the bursts (traffic shaping upstream) 2) Decrease the CPU to let it better handle the bursts 3) Get a bigger box that does the hardware-software transfers via hardware, not on the CPU. You can see how much of the CPU is being taken up by a 'show proc cpu' (the %x/%y portion) %x shows the CPU utilization, the %y shows how much is interrupt traffic. Ken Matlock Network Analyst 303-467-4671 matlo...@exempla.org *** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice *** ___ 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] Frustration with XR "show interface" and pipe commands
show interfaces | include "(up|down)" /F On 24 May 2012 16:19, John Neiberger wrote: > Someone asked me how to do something very simple and I'm finding it > very difficult! He wants to do a "show interface" command and show > only lines with "up" or "rate" in it. In IOS, this was simply "show > int | i up|rate". That second pipe for OR does not seem to work in XR > and we can't figure out how to do something this simple. I even tried > piping the command to egrep and frgrep, but couldn't figure out how to > do an OR in a way that XR understands. > > Any ideas how to pipe the output of a command through an "include" > that has an OR operator? > ___ > 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] Frustration with XR "show interface" and pipe commands
On Thu, 24 May 2012 08:19:40 -0600, you wrote: > Someone asked me how to do something very simple and I'm finding it > very difficult! He wants to do a "show interface" command and show > only lines with "up" or "rate" in it. Put your regex in quotes: sh int | i "up|rate" -A ___ 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] Frustration with XR "show interface" and pipe commands
Someone asked me how to do something very simple and I'm finding it very difficult! He wants to do a "show interface" command and show only lines with "up" or "rate" in it. In IOS, this was simply "show int | i up|rate". That second pipe for OR does not seem to work in XR and we can't figure out how to do something this simple. I even tried piping the command to egrep and frgrep, but couldn't figure out how to do an OR in a way that XR understands. Any ideas how to pipe the output of a command through an "include" that has an OR operator? ___ 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] Lot of input errors on a NPE-G1 interface
On (2012-05-24 14:37 +0200), Gert Doering wrote: > I do not run MST anywhere, so I'm not sure how portfast and MST interact. MST with single instance is same as RSTP from this perspective. If you don't configure non-MST participating port as edge port (or cisco term portfast) then you are waiting 30s for permission from that port. When all ports in switch have given permission, then the switch will give permission to upstream. So any non-edge port, will delay this permission for 30s. (You knew this as you know RST, this is benefit of other). -- ++ytti ___ 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] Lot of input errors on a NPE-G1 interface
Hi, > After the port-fast discussion back to your original question. The first > thing to look is the interface controller (show controller , show ip > interface) and the logging to make sure I don't have speed/duplex or > flow-control problems. router2#show controller ... Interface GigabitEthernet0/1 (idb 0x65C58CDC) Hardware is BCM1250 Internal MAC (Revision B2/B3) Network connection mode is AUTO network link is up Config is 1Gbps, Full Duplex Selected media-type is GBIC GBIC type is 1000BaseSX ... ... PHY says Link is UP, Speed 1000Mbps, Full-Duplex [AUTONEG Done] Physical Interface - GBIC AUTONEG - Our ability is 1000M/FD Pause Capable (Asymmetric) AUTONEG - Partner ability is 1000M/HD 1000M/FD router2#sh ip int Gi0/1 GigabitEthernet0/1 is up, line protocol is up Internet address is x.x.x.x/28 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is disabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is enabled IP fast switching on the same interface is disabled IP Flow switching is disabled IP CEF switching is enabled IP Feature Fast switching turbo vector IP Feature CEF switching turbo vector IP multicast fast switching is enabled IP multicast distributed fast switching is disabled IP route-cache flags are Fast, CEF Router Discovery is disabled IP output packet accounting is disabled IP access violation accounting is disabled TCP/IP header compression is disabled RTP/IP header compression is disabled Policy routing is disabled Network address translation is disabled BGP Policy Mapping is disabled WCCP Redirect outbound is disabled WCCP Redirect inbound is disabled WCCP Redirect exclude is disabled Next step is to disable autonegotiation and set speed/duplex hardcoded on both sides. BTW, disabling netflow decreases the CPU utilization dramatically :-) After increase the hold-queue from 100 to 150 and disabling netflow the input errors are still alive: (clearing the counter nearly 8 hours before) sh int Gi0/1 GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0006.52f4.d81b (bia 0006.52f4.d81b) Internet address is 94.103.161.235/28 MTU 1500 bytes, BW 100 Kbit/sec, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, link type is autonegotiation, media type is SX output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 07:47:20 Input queue: 0/150/2026/2 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 6191000 bits/sec, 1385 packets/sec 5 minute output rate 7266000 bits/sec, 2079 packets/sec 40892419 packets input, 1638492851 bytes, 0 no buffer Received 773 broadcasts, 0 runts, 0 giants, 0 throttles 880 input errors, 0 CRC, 0 frame, 880 overrun, 0 ignored 0 watchdog, 14448 multicast, 0 pause input 0 input packets with dribble condition detected 53498590 packets output, 3784646524 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 467 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out Regards On Thu, May 24, 2012 at 11:13 AM, Erich Hohermuth wrote: > Hi > > After the port-fast discussion back to your original question. The first > thing to look is the interface controller (show controller , show ip > interface) and the logging to make sure I don't have speed/duplex or > flow-control problems. > > Second you get "unknown protocol drops" this happens mostly from cdp > packets. You send cdp from your switch but drop them on your router. > > I my case I had to enable flow-control on my 3560 switch and allow pause > frames from the npe-g1. Hint: Sometimes it is more reliable to turn the > auto-neg feature off > > Regards > Erich > >> >> NPE-G1: >> >> GigabitEthernet0/1 is up, line protocol is up >> Hardware is BCM1250 Internal MAC, address is 0006.52f4.d81b (bia >> 0006.52f4.d81b) >> Internet address is x.x.x.x/28 >> MTU 1500 bytes, BW 100 Kbit/sec, DLY 10 usec, >> reliability 255/255, txload 1/255, rxload 1/255 >> Encapsulation ARPA, loopback not set >> Keepalive set (10 sec) >> Full-duplex, 1000Mb/s, link type is autonegotiation, media type is SX >> output flow-control is XON, input flow-
Re: [c-nsp] Rapid-PVST and RSTP compatibility
Thank you All for your replies! That I found in INTERNET: "To allow Cisco switches running rapid PVST+ or PVST+ to form a common spanning tree with others switches running RSTP, MSTP, or STP, vlan1 (the native VLAN) must be configured as untagged on the Cisco ports connected to the others switches." So, I'll try this... Thanks again, Peter On Wed, May 23, 2012 at 7:15 PM, Brandon Ewing wrote: > On Wed, May 23, 2012 at 09:42:48AM -0600, Steven Raymond wrote: >> On May 23, 2012, at 9:15 AM, Covalciuc Piotr wrote: >> >> > We have a network built on CISCO switches with Rapid-PVST. >> > Now, we want to integrate in the network the DELL PowerConnect >> > switches, which supports RSTP only. >> > >> > Does the Rapid-PVST compatible with RSTP? >> >> From what I understand, the Ciscos will still run Rapid-PVST, not fall back >> to "RSTP". Rapid-PVST will interwork with the Dells' RSTP, however. On the >> cisco you can say "spanning-tree mode [ pvst | rapid-pvst | mst ]" without a >> "plain" RSTP option. >> >> PVST & R-PVST has limitations in the total number of vlans you can run, >> however, I think it is 128. >> >> You may want to look at running MSTP, which should be somewhat less Cisco >> proprietary, and the dells will do MSTP as well. MSTP then overcome the >> PVST vlan count limits. >> > > The last time I looked at this, mapping vLANS to an MST instance on a > Powerconnect created that vLAN on the switch. Since we were pre-mapping the > entire 4K vlan range on our Cisco devices, this blew up the first > Powerconnect we tried it on. > > Note: This was 2+ years ago, on a 53xx-class device. > > -- > Brandon Ewing (nicot...@warningg.com) > > ___ > 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] Lot of input errors on a NPE-G1 interface
Regarding that IPTV issue, there is a Cisco switch option to not flush IGMP table mappings when a TCN goes out, that accomplishes the same thing as portfast, but without the (slight) risk of using that: http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/configu ration/guide/multi.html#wp1049520 Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Thursday, May 24, 2012 5:38 AM To: adam vitkovsky Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface Hi, On Thu, May 24, 2012 at 12:38:49PM +0200, adam vitkovsky wrote: > What do you think about enabling port-fast on trunks between switches > that are connected in a star topology (no redundant links) and running > MST I do not run MST anywhere, so I'm not sure how portfast and MST interact. OTOH, if you connect switches with *RSTP* together, the links will be up and forwarding in very short time anyway, so portfast won't make much difference. > I'm asking because we have problems with TCN and following CAM table > flushes when ports flap We suspect that the CAM table flushes have > negative effects on IPTV streams There was the idea of enabling > port-fast on trunks since the topology is a cascaded star and when a > segment goes offline there's no other way to get to it -so no need for > the whole instance/domain to suffer from topology change And in case > the someone creates an artificial loop MST should take care of it as > soon as it hears the first bpdu right Well, if you are *sure* your topology has no loops, then just turn off spanning tree. No TCNs. 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/
Re: [c-nsp] Lot of input errors on a NPE-G1 interface
On Thursday, May 24, 2012 02:54:03 PM Gert Doering wrote: > If I'm not mistaken, the other 3 GE ports are directly > connected to the CPU on the SoC - so "no bus at all". That's right. > The difference would be "... if compared to a PA-GE > sitting on the classic PCI bus". Agree, but given the overall throughput of the box is just under 1Gbps, I suppose it all works out considering not lal 4x ports were full at any one time :-). 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] Lot of input errors on a NPE-G1 interface
Hi, On Thu, May 24, 2012 at 02:44:42PM +0200, Mark Tinka wrote: > On Thursday, May 24, 2012 02:39:20 PM Gert Doering wrote: > > > Well, I'd interpret that as "it is not connected to the > > PCI bus, so won't eat bandwidth points from there". Not > > as "will do distributed anything". > > Right, that was my interpretation too, but for me, each port > performed the same, so it was a non-starter. If I'm not mistaken, the other 3 GE ports are directly connected to the CPU on the SoC - so "no bus at all". The difference would be "... if compared to a PA-GE sitting on the classic PCI bus". 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 pgpJdLmH3ia9C.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] Lot of input errors on a NPE-G1 interface
On Thursday, May 24, 2012 02:39:20 PM Gert Doering wrote: > Well, I'd interpret that as "it is not connected to the > PCI bus, so won't eat bandwidth points from there". Not > as "will do distributed anything". Right, that was my interpretation too, but for me, each port performed the same, so it was a non-starter. 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] Lot of input errors on a NPE-G1 interface
On Thursday, May 24, 2012 02:37:47 PM Gert Doering wrote: > OTOH, if you connect switches with *RSTP* together, the > links will be up and forwarding in very short time > anyway, so portfast won't make much difference. Aye - which is why we run RSTP everywhere we need STP anyway. 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] Lot of input errors on a NPE-G1 interface
Ha! So that 1 port can do line rate to. the CPU? :) And I can see getting that linerate out of the box. It's things like QoS and Netflow that really have to involve the CPU much more than simple packet forwarding. Once you get most of those services established (such as ISIS) there's really not much for the CPU to do to maintain the table. Ken From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Thu 5/24/2012 6:30 AM To: cisco-nsp@puck.nether.net Cc: Matlock, Kenneth L; gal.9...@googlemail.com Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface On Thursday, May 24, 2012 02:19:39 PM Matlock, Kenneth L wrote: > I recently had a similar issue with a 7201 (which is > effectively a NPE-G2). Keep in mind that a 7200 series > platform is 100% software-based. Except for the part where they said the 4th Gig-E port is a PCI-X connection to the board and can run at line rate independently. Never did quite figure that one out :-). > And NPE-G2 is rated for 1024Mb/sec. This is aggregate > throughput, meaning you can do 1024mb/sec in one > direction, or 512mb/sec each direction before > overrunning the box. This is with no services running, > static routes, etc. Talked to my SE and found out that > performance with QoS drops to 512mb/sec aggregate, and > with Netflow it dropped to 256mb/sec. (aggregate). We used the NPE-G2 as a core router many, many years ago, and extratced 950Mbps from it (aggregate) with 0% packet loss at 91% CPU utilization. v6, v6, MPLS, IS-IS, LDP, RSVP. Mark. *** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice *** ___ 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] Lot of input errors on a NPE-G1 interface
Hi, On Thu, May 24, 2012 at 02:30:59PM +0200, Mark Tinka wrote: > > I recently had a similar issue with a 7201 (which is > > effectively a NPE-G2). Keep in mind that a 7200 series > > platform is 100% software-based. > > Except for the part where they said the 4th Gig-E port is a > PCI-X connection to the board and can run at line rate > independently. > > Never did quite figure that one out :-). Well, I'd interpret that as "it is not connected to the PCI bus, so won't eat bandwidth points from there". Not as "will do distributed anything". 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 pgp8kjgbS8GKY.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] Lot of input errors on a NPE-G1 interface
Hi, On Thu, May 24, 2012 at 12:38:49PM +0200, adam vitkovsky wrote: > What do you think about enabling port-fast on trunks between switches that > are connected in a star topology (no redundant links) and running MST I do not run MST anywhere, so I'm not sure how portfast and MST interact. OTOH, if you connect switches with *RSTP* together, the links will be up and forwarding in very short time anyway, so portfast won't make much difference. > I'm asking because we have problems with TCN and following CAM table flushes > when ports flap > We suspect that the CAM table flushes have negative effects on IPTV streams > There was the idea of enabling port-fast on trunks since the topology is a > cascaded star and when a segment goes offline there's no other way to get to > it -so no need for the whole instance/domain to suffer from topology change > And in case the someone creates an artificial loop MST should take care of > it as soon as it hears the first bpdu right Well, if you are *sure* your topology has no loops, then just turn off spanning tree. No TCNs. 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/
Re: [c-nsp] Lot of input errors on a NPE-G1 interface
On Thursday, May 24, 2012 02:19:39 PM Matlock, Kenneth L wrote: > I recently had a similar issue with a 7201 (which is > effectively a NPE-G2). Keep in mind that a 7200 series > platform is 100% software-based. Except for the part where they said the 4th Gig-E port is a PCI-X connection to the board and can run at line rate independently. Never did quite figure that one out :-). > And NPE-G2 is rated for 1024Mb/sec. This is aggregate > throughput, meaning you can do 1024mb/sec in one > direction, or 512mb/sec each direction before > overrunning the box. This is with no services running, > static routes, etc. Talked to my SE and found out that > performance with QoS drops to 512mb/sec aggregate, and > with Netflow it dropped to 256mb/sec. (aggregate). We used the NPE-G2 as a core router many, many years ago, and extratced 950Mbps from it (aggregate) with 0% packet loss at 91% CPU utilization. v6, v6, MPLS, IS-IS, LDP, RSVP. 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] Lot of input errors on a NPE-G1 interface
Ahh, Netflow I recently had a similar issue with a 7201 (which is effectively a NPE-G2). Keep in mind that a 7200 series platform is 100% software-based. And NPE-G2 is rated for 1024Mb/sec. This is aggregate throughput, meaning you can do 1024mb/sec in one direction, or 512mb/sec each direction before overrunning the box. This is with no services running, static routes, etc. Talked to my SE and found out that performance with QoS drops to 512mb/sec aggregate, and with Netflow it dropped to 256mb/sec. (aggregate). Now, officially the NPE-G2 is twice as fast as an NPE-G1, So extrapolating that out means best-case you can expect peak performance of 512mb/sec, 256mb/sec with QoS, and 128mb/sec with just Netflow enabled. And with the input RX ring on those boxes being only 128 deep they are VERY sensitive to CPU spikes/latencies (such as when enabling services such as Netflow or QoS). Unfortunately that's not configurable and a hardware limitation of the chassis. In our case we wound up replacing the 7201's with ASR1k's to get the throughput we needed. Netflow is very handy, but a big performance hit on the 7200 line. Hope this points you in the right direction! Ken From: gal.9...@googlemail.com [mailto:gal.9...@googlemail.com] Sent: Wed 5/23/2012 11:53 PM To: Matlock, Kenneth L Cc: Edward Salonia; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface I don't run QoS on this box but Netflow. Will disable the flows and see what happens. On Thu, May 24, 2012 at 1:13 AM, Matlock, Kenneth L wrote: > The problem with a 1 minute interval is that you can EASILY be bursting well > above that for short periods of time. remember that 80-100Mbps is an average > over the entire 1 minute. > > Are you running QoS or Netflow on this box? > > Ken > > > > From: cisco-nsp-boun...@puck.nether.net on behalf of gal.9...@googlemail.com > Sent: Wed 5/23/2012 3:24 PM > To: Edward Salonia > Cc: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface > > > >> Are you getting bursts of traffic that might not register on traffic graphs >> polling at 5 minute intervals? > > No, I don't think so. Burst traffic never exceeds 80-100 Mbps. We're > polling in a 1 min interval. > > > On Wed, May 23, 2012 at 11:16 PM, Edward Salonia > wrote: >> Drops and overruns... Sounds like you are overloading your port buffer. Are >> you getting bursts of traffic that might not register on traffic graphs >> polling at 5 minute intervals? >> >> - Ed >> >> -Original Message- >> From: cisco-nsp-boun...@puck.nether.net >> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of >> gal.9...@googlemail.com >> Sent: Wednesday, May 23, 2012 5:00 PM >> To: Sigurbjörn Birkir Lárusson >> Cc: cisco-nsp@puck.nether.net >> Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface >> >>> Is this the only traffic going through this 7200? >> >> No. Gi0/1 is connected via 2960G to another router (iBGP). Gi0/2 is >> connected to an eBGP peer >> who sends a full table. >> >>> How is your scheduler allocate set on the 7200... >> >> Default value, not changed. >> >>> ...have you tried a new cable and cleaning the optics? >> >> New cable: yes >> Cleaning the optics: no >> >> >> >> On Wed, May 23, 2012 at 10:40 PM, Sigurbjörn Birkir Lárusson >> wrote: >>> Is this the only traffic going through this 7200? >>> >>> How is your scheduler allocate set on the 7200, have you tried a new cable >>> and cleaning the optics? >>> >>> Kind regards, >>> Sibbi >>> >>> On 23.5.2012 19:33, "gal.9...@googlemail.com" >>> wrote: >>> Hi, thanks all for the input. Increasing the hold-queue (from default to 100) doesn't seem to help at all: GigabitEthernet0/1 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0006.52f4.d81b (bia 0006.52f4.d81b) Internet address is x.x.x.x/28 MTU 1500 bytes, BW 100 Kbit/sec, DLY 10 usec, reliability 255/255, txload 1/255, rxload 2/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, link type is autonegotiation, media type is SX output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 02:17:11 Input queue: 0/100/742/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 10536000 bits/sec, 1824 packets/sec 5 minute output rate 6813000 bits/sec, 2121 packets/sec 11770910 packets input, 2922271410 bytes, 0 no buffer Received 215 broadcasts, 0 runts, 0 giants, 0 throttles 341 input errors, 0 CRC, 0 frame, 341 overrun, 0 ignored 0 watchdog, 4242 multicast, 0
Re: [c-nsp] Lot of input errors on a NPE-G1 interface
On 24.5.2012 09:28, "Saku Ytti" wrote: >On (2012-05-24 10:56 +0200), Peter Rathlev wrote: > >> connecting to anything that does not create a L2 loop, i.e. a bridge. We >> use Portfast and BPDU Guard on all links towards routers. That also > >This is incredibly dangerous. Leak one BPDU from one customer EVPN >somewhere, and all customers are down in PE facing that metro. >PE<->Metro definitely should be BPDUfilter. > >On customer ports, BPDUguard is apt, which you can enable per default for >edge/portfast ports, so you only need to configure porfast. We're in complete agreement Kind regards, Sibbi > ___ 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] Lot of input errors on a NPE-G1 interface
On (2012-05-24 10:56 +0200), Peter Rathlev wrote: > connecting to anything that does not create a L2 loop, i.e. a bridge. We > use Portfast and BPDU Guard on all links towards routers. That also This is incredibly dangerous. Leak one BPDU from one customer EVPN somewhere, and all customers are down in PE facing that metro. PE<->Metro definitely should be BPDUfilter. On customer ports, BPDUguard is apt, which you can enable per default for edge/portfast ports, so you only need to configure porfast. -- ++ytti ___ 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] Lot of input errors on a NPE-G1 interface
Hi After the port-fast discussion back to your original question. The first thing to look is the interface controller (show controller , show ip interface) and the logging to make sure I don't have speed/duplex or flow-control problems. Second you get "unknown protocol drops" this happens mostly from cdp packets. You send cdp from your switch but drop them on your router. I my case I had to enable flow-control on my 3560 switch and allow pause frames from the npe-g1. Hint: Sometimes it is more reliable to turn the auto-neg feature off Regards Erich > > NPE-G1: > > GigabitEthernet0/1 is up, line protocol is up > Hardware is BCM1250 Internal MAC, address is 0006.52f4.d81b (bia > 0006.52f4.d81b) > Internet address is x.x.x.x/28 > MTU 1500 bytes, BW 100 Kbit/sec, DLY 10 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation ARPA, loopback not set > Keepalive set (10 sec) > Full-duplex, 1000Mb/s, link type is autonegotiation, media type is SX > output flow-control is XON, input flow-control is XON > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 00:00:00, output 00:00:00, output hang never > Last clearing of "show interface" counters never > Input queue: 0/75/1321/1 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 5 minute input rate 4264000 bits/sec, 871 packets/sec > 5 minute output rate 5859000 bits/sec, 1597 packets/sec > 27479327 packets input, 343489 bytes, 0 no buffer > Received 941 broadcasts, 0 runts, 0 giants, 0 throttles > 989 input errors, 0 CRC, 0 frame, 989 overrun, 0 ignored > 0 watchdog, 17119 multicast, 0 pause input > 0 input packets with dribble condition detected > 43616309 packets output, 2243854018 bytes, 0 underruns > 5 output errors, 0 collisions, 4 interface resets > 561 unknown protocol drops > 0 babbles, 0 late collision, 0 deferred > 5 lost carrier, 0 no carrier, 0 pause output > 0 output buffer failures, 0 output buffers swapped out ___ 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] Lot of input errors on a NPE-G1 interface
On Wed, 2012-05-23 at 13:15 -0500, Chris Gotstein wrote: > It's probably not going to address the overrun issue, but from a best > practices stand point, it should not be enabled on interfaces that > connected to other connected devices, ie a router or switch. To recap what others have said: Portfast is IMO always a good idea when connecting to anything that does not create a L2 loop, i.e. a bridge. We use Portfast and BPDU Guard on all links towards routers. That also covers trunks toward a 6500 swouter if it's a "no switchport" with subinterfaces. Not using Portfast means that many failover situations take forever to converge. On the other hand we never use Portfast unless we can also enable BPDU Guard. Otherwise you're not protected from someone accidentally connecting the port to a switch. BPDU Filter is IMO almost always a bad thing. There are some very special circumstances where it's warranted, but they are few and far between. -- Peter ___ 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] Lot of input errors on a NPE-G1 interface
On 05/24/2012 06:16 AM, David Farrell wrote: On 23/05/2012 20:27, Phil Mayers wrote: If you don't enable portfast, you have to suffer the STP state transitions, which lead to delays in traffic forwarding after link-up. I wondered what people's feelings/experiences were with respect to completely disabling STP where appropriate? I have 100% control over topology and some PtP dotq trunk links, I thought of placing 'spanning-tree bpdufilter enable' rather than 'portfast trunk' on these ports. I have no need to to send or receive STP BPDUs on these ports, even though the underlying technology is Ethernet. Hosts are a mixture of L3 switches and routers, but configuration should limit the extent of the broadcast domains in question to exist only on the PtP link. We run PVST, and do indeed disable STP completely on VLANs which are used for directed routed ptp links i.e. are only on one port, and only make one hop. We don't disable it on the whole port because often the port is carrying other vlans which are PVST enabled (e.g. between an HSRP master&slave / STP primary&secondary root switch pair). We do have some links which carry a routed p2p only, but even then we just disable STP on the vlan, not the port. Obviously if you're running MST or classic STP this per-vlan approach isn't available, and you can only do per-port. ___ 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/
