Re: [c-nsp] Frequent crashes of snmpd on IOS XR 4.3.4 on ASR9k
We have been running the fix since the beginning of this week with no issues. Would recommend you check out the other available SMUs for 4.3.4 proactively. tv On 9/5/2014 7:56 AM, Praveen Sharma (psharma) wrote: Do you have the 434 SMU for CSCum44940 (AA08480) installed on the device? Thanks Praveen -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rimestad, Steinar Sent: Friday, August 22, 2014 3:29 AM To: Mathieu Paonessa; Richard Hartmann; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Frequent crashes of snmpd on IOS XR 4.3.4 on ASR9k Hi. We have hit the same issue, most likely this bug: CSCum44940 https://tools.cisco.com/bugsearch/bug/CSCum44940 Cisco released a hitless SMU for it on 22/7/2014: asr9k-px-4.3.4.CSCum44940 SNMPD crash with backend polling. Recommended Hitless SNMP22/ 7/ 2014 Steinar -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mathieu Paonessa Sent: 21. august 2014 17:37 To: Richard Hartmann; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Frequent crashes of snmpd on IOS XR 4.3.4 on ASR9k Hi Richard, On 21/08/14 17:19, Richard Hartmann wrote: we are seeing frequent crashes and subsequent reloads of snmpd on IOS XR 4.3.4 on ASR9k. I am not sure how much TAC cares as this is not service impacting (ha. ha.). Is anyone else seeing those issues? We had the same issue and it's fixed on SP3. Regards, Mathieu ___ 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/ ___ 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] 4500X weird issue...
On 12/6/2013 10:25 PM, Jeff Kell wrote: We received our first pair of 4500X switches, and proceeded to try to prepare them for deployment. They came up OK on console access, we got a very basic configuration setup, linked them together, and did an initial VSS pairing. With that successful, we put in a management IP address for the management port, saved everything, and proceeded to move them to the server room. Upon power-up at the new location, they won't boot... * * * Rom Monitor NVRAM configuration is being initialized to * * default values. This may be because it was never initialized.* * * Writing to Primary Region failed Writing to Backup Region failed Rommon (G) Signature verification PASSED flash0:/codesign/rm1.dat open failure Rommon (P) Signature verification PASSED flash0:/codesign/rm2.dat open failure * * * Rom Monitor NVRAM configuration is being initialized to * * default values. This may be because it was never initialized.* * * Writing to Primary Region failed Writing to Backup Region failed FPGA (P) Signature verification PASSED flash0:/codesign/fpga.dat open failure * * * Welcome to Rom Monitor forWS-C4500X-16 System. * * Copyright (c) 2008-2013 by Cisco Systems, Inc. * * All rights reserved. * * * Rom Monitor (P) Version 15.0(1r)SG10 CPU Rev: 2.2, Board Rev: 9, Board Type: 108 CPLD Mobat Rev: 2.0x549a.0x59a4 Chassis: WS-C4500X-16 MAC Address : e4-c7-22-**-**-** Ip Address : Not set. Netmask : Not set. Gateway : Not set. TftpServer : Not set. Non-Redundant system or peer not running IOS System Uplinks Linecards have been reset!! * The system will autoboot in 5 seconds * Type control-C to prevent autobooting. . . . . Management Ethernet Link Up: 1Gb Full Duplex . The system will autoboot now config-register = 0x102 Writing to Primary Region failed Writing to Backup Region failed Autobooting using BOOT variable specified file. Could not find a valid file in BOOT environment variable. BOOT variable can be set from IOS. To find currently set Rom Monitor variables, please type 'set' command. For help on choosing a boot method, type 'confreg' command. Writing to Primary Region failed Writing to Backup Region failed Writing to Primary Region failed Writing to Backup Region failed Writing to Primary Region failed Writing to Backup Region failed rommon 1 boot Writing to Primary Region failed Writing to Backup Region failed ExtX super block invalid signature No bootable image found ! boot: can not determine first file name on device flash1:/USER rommon 2 What the heck??? Jeff I thought you were running into the confreg issue but it appears you have the upgraded rom in which this is fixed. Odd. http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/release/note/OL_24829.html#wp196197 What's the normal commands show in rommon (dev, dir flash:, etc)? Everything there? tv --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.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/
Re: [c-nsp] 6500, 7600 or ASR
On 8/29/2013 9:12 AM, Mark Tinka wrote: Same here - the RP2 in the ASR1001 will scale well when you run as many full feeds as you want. It's not an RP2...more of a RP2 lite :) Also note the memory restriction on the 1001 compared to a RP2 system. As a general thought, stay away from RP1 systems (such as a 1002). I'd go with 2x units if all you need is a handful of Gig-E ports and no SONET/SDH or other non-Ethernet requirements. This +1. tv ___ 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] 1.1.1.0/24 and Cisco WLCs
On 3/11/2013 7:05 AM, Andrew Miehs wrote: Hi all, Was just doing a little bit of reading and had a look at http://rs2.swissix.ch/cgi-bin/bgplg?cmd=show+ip+bgp+source-asreq=15169 Specifically: flags destination gateway lpref med aspath origin *1.1.1.0/24 91.206.52.74 100 0 15169 i I never thought that Cisco using 1.1.1.1 was a good idea - but now looking that Google is announcing it - I think it is considerably worse. IIRC changing the virtual IP address on the Cisco WLCs is also strongly not recommended - so lets hope Google doesn't use this address for anything useful... Or have I missed something? Cisco doesn't use this. It's a configurable item. Any wireless engineer worth their salt does not use this. tv ___ 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] 1.1.1.0/24 and Cisco WLCs
On 3/11/2013 9:37 AM, Phil Mayers wrote: On 11/03/13 13:42, Tony Varriale wrote: engineer worth their salt does not use this. Maybe. But a lot of people *have* used it, because I've seen it when doing webauth logins e.g. in airports, train networks, etc. And by definition, the people unwise enough to use it are also likely to be the people unwise enough to return and fix things up in the installations they did. Yes, very unfortunate. But, I know of a lot of installs that have not. :) Cisco wrote docs suggesting that people did this: Enter the IP address of the controller's virtual interface. You should enter a fictitious, unassigned IP address, such as 1.1.1.1. http://www.cisco.com/en/US/docs/wireless/controller/2100/quick/guide/ctrl206q.html (amongst others) This was always terrible, very naughty advice. That sentence should have read: You should enter an IP address from a range you control, such as public IPs owned by your organisation or RFC 1918 space e.g. 10.1.1.1 Bad cisco! Bad! No treats for you! Yes, definitely a doc issue. Unfortunately, not fixed :( tv ___ 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] 1.1.1.0/24 and Cisco WLCs
On 3/11/2013 9:49 AM, Sandy Breeze wrote: On 11/03/13 14:37, Phil Mayers wrote: Cisco wrote docs suggesting that people did this: Enter the IP address of the controller's virtual interface. You should enter a fictitious, unassigned IP address, such as 1.1.1.1. http://www.cisco.com/en/US/docs/wireless/controller/2100/quick/guide/ctrl206q.html (amongst others) Unfortunately, WLC documentation is littered with references to 1.1.1.1. http://www.cisco.com/en/US/docs/wireless/controller/7.0/configuration/guide/c70users.html - even goes as far as to suggest administrators create a cert with CN=1.1.1.1 ! I hope you do not do everything Cisco suggests. :) tv ___ 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] Next step-up from 7206VXR
On 2/19/2013 2:57 PM, Jon Lewis wrote: On Tue, 19 Feb 2013, Eric A Louie wrote: I've run out of port capacity on my 7206VXR and need to go to the next router or put in another 7206VXR side-by-side. Any recommendations on what to use if I were to replace my existing 7206VXR with another chassis? (it's limited to 5 GB interfaces, and we need 7 or 8) You've got to say more about what the router is doing and what you need from it. If it's routing for 8 1gb ethernets and doing full BGP routes, and nothing special, then a 6500 is an attractive option bang for your buck-wise. They're made for ethernet and comparitively cheap to keep adding ports to. Except when said 6500 sup CPU is asked to do BGP intensive stuff :) tv ___ 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] All multicast punting to CPU on 6500
On 12/16/2012 5:59 AM, Robert Williams wrote: Hi, I'll try to go into some additional detail on the traffic and other router config elements now. The traffic is basically made up of a randomly generated packet which is almost identical to the below. The 'random' element is that the source port is different every time. This packet was 10.0.5.200 (00:50:56:a6:00:23) - 10.0.5.88 (01:00:5e:7f:05:77) The test interface on the 6500 is currently on 10.0.5.123. The below packet was captured on the control-plane going towards the Route-Processor CPU. -- -- No. TimeSourceDestination Protocol Length Info 23985 2023.684297 10.0.5.20010.0.5.88 TCP 60 config-port 0 [None] Seq=1 Win=512 Len=0 Frame 23985: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Arrival Time: Dec 16, 2012 11:36:32.951556000 UTC Epoch Time: 1355657792.951556000 seconds [Time delta from previous captured frame: 0.00030 seconds] [Time delta from previous displayed frame: 0.00030 seconds] [Time since reference or first frame: 2023.684297000 seconds] Frame Number: 23985 Frame Length: 60 bytes (480 bits) Capture Length: 60 bytes (480 bits) [Frame is marked: True] [Frame is ignored: False] [Protocols in frame: eth:ip:tcp] [Coloring Rule Name: TCP] [Coloring Rule String: tcp] Ethernet II, Src: Vmware_a6:00:23 (00:50:56:a6:00:23), Dst: IPv4mcast_7f:05:77 (01:00:5e:7f:05:77) Destination: IPv4mcast_7f:05:77 (01:00:5e:7f:05:77) Address: IPv4mcast_7f:05:77 (01:00:5e:7f:05:77) ...1 = IG bit: Group address (multicast/broadcast) ..0. = LG bit: Globally unique address (factory default) Source: Vmware_a6:00:23 (00:50:56:a6:00:23) Address: Vmware_a6:00:23 (00:50:56:a6:00:23) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Type: IP (0x0800) Trailer: Internet Protocol Version 4, Src: 10.0.5.200 (10.0.5.200), Dst: 10.0.5.88 (10.0.5.88) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 00.. = Differentiated Services Codepoint: Default (0x00) ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 40 Identification: 0x7b6e (31598) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (6) Header checksum: 0xe042 [correct] [Good: True] [Bad: False] Source: 10.0.5.200 (10.0.5.200) Destination: 10.0.5.88 (10.0.5.88) Transmission Control Protocol, Src Port: config-port (3577), Dst Port: 0 (0), Seq: 1, Len: 0 Source port: config-port (3577) Destination port: 0 (0) [Stream index: 3651] Sequence number: 1(relative sequence number) Acknowledgement number: Broken TCP. The acknowledge field is nonzero while the ACK flag is not set Header length: 20 bytes Flags: 0x000 (None) 000. = Reserved: Not set ...0 = Nonce: Not set 0... = Congestion Window Reduced (CWR): Not set .0.. = ECN-Echo: Not set ..0. = Urgent: Not set ...0 = Acknowledgement: Not set 0... = Push: Not set .0.. = Reset: Not set ..0. = Syn: Not set ...0 = Fin: Not set Window size value: 512 [Calculated window size: 512] [Window size scaling factor: -1 (unknown)] Checksum: 0xd021 [validation disabled] [Good Checksum: False] [Bad Checksum: False] -- -- As for the multicast configuration on the box - it doesn't run any end-user multicast services, other than VRRP/HSRP between itself and a partner 6500 (for gateway resilience). As such there is no multicast configuration. In fact, if anything it would be ideal if the box dropped all multicast traffic apart from the HSRP/VRRP to be honest. The reason I think this may be causing issues is because it is destined to a non-multicast IP, but with a multicast MAC? I also tried the suggestion of disabling CoPP and the traffic was still hitting the CPU at the same rate. To answer the other questions, the TTL
Re: [c-nsp] All multicast punting to CPU on 6500
On 12/16/2012 10:49 AM, Robert Williams wrote: Hi, I'm sensing a lot of frustration / anger / hatred for NLB, having never really used it myself I'll just back away from that quietly :) Unfortunately the test is valid because the situation actually arose when a Windows NLB cluster went offline and there was a load of DDoS traffic heading to it. The whole reason I'm even working on this is because it 'did' happen, unfortunately... It's not valid if you are randomly selecting many multicast addresses. If you read the link I posted, it explains the issue and the work around. If you do not have the work around as part of your use case and test, your test is invalid if you expect a reasonable outcome. Again, we can all come up with corner cases that crush boxes. Not that I need to tell you this, but making corporate standards that do not follow general networking common sense are not standards. MS is notorious of making up their own networking solutions without consulting or referencing the rest of the world. With that said, there are many many cost effective load balancing solutions in the market place. However, aside from cough NLB, what stops a compromised device from being used to emit such traffic maliciously? Power button. Or host security. In the colocation world we have seen examples where the attacker just rents a couple of VPS instances with the same provider as their target and uses it to take down the target from the 'inside' by messing with the providers' infrastructure. External and internal DDoS protection are, although they may use the same tactics, are 2 separate beasts. The (two lines in linux) example I was testing with would be a nice way to do this, at least until the provider tracks it down and pulls it. Which in itself could be tricky if the CPU is maxed out and/or your traffic graphing shows only 'unicast' traffic PPS, thus is blind to multicast. I assumed that there was just a configuration I was missing but it's now sounding like it's just a limitation, which is a real shame. Although it's partially possible with 15M it seems. Oh well, time to move on, so thanks again for all the input everyone :) Cheers! Robert Williams Custodian Data Centre Email: rob...@custodiandc.com http://www.CustodianDC.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/
Re: [c-nsp] sup2t XL with non XL linecards
On 11/22/2012 2:11 PM, . . wrote: Hi, http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_item09186a00809a7673.shtml Thanks, that link helps a bit, but still a bit unclear on things. =) Assuming I don't need the performance and the 30 Mpps of sup2t is fine for a centralized forwarding system, and happy to have linecards send packets over the fabric for forwarding by the supervisor, do I need XL at all, or if full tables with ~400k routes are required, I must get the XL version of sup2t? Thanks! You'll need XL. Non-XL FIB is 256k raw. XL FIB is 1M raw. FYI 30 mpps is IPv6 in Sup2T land. tv ___ 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] Is FWSM have a local security zone concept
On 11/3/2012 8:31 AM, zhangyongshun wrote: I find a problem thatunable to ping internet(for example 8.8.8.8) form FWSM(I have been ssh to FWSM) recently.But any business is worked fine through FWSMtraffic. and I can ping direct interface with FWSM outside interface. If FWSM have local security conceptand the local security zone unable ping outside?or other cause. ___ 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/ Look at icmp command. tv ___ 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] Multicast packets dropping at 6509
On 10/30/2012 7:48 AM, Matthew Huff wrote: Do you have pim or igmp snooping turned on? Without a layer 3 multicast router configured, the 6509 will probably shunt the traffic. Setup a SVI interface on that vlan and enable pim dense mode. If you don't want multicast to pass the layer 3 boundry, you can setup a multicast boundry command on the vlan. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ambedkar Sent: Tuesday, October 30, 2012 2:23 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Multicast packets dropping at 6509 Hi, Phil Mayers: 1. Data rate:4 kbps 2. Line cards: 1000BaseX supervisor WS-X6K-S2U-MSFC2 1000BaseX Ethernet, WS-X6408A-GBIC CatOS 8.3 Matthew: 1). As we are in the same VLAN, the data is not going to Lyaer-3 2). we are using, pim-dense Null: we are not observing such kind of behaviour. what we are observing is that one of the switch is not creating any multicast table, when we see in the mac-address table multicast, there is no multicast table. when we replace Cisco 6509 with cisco 2950 switch it is working fine. thank you On Mon, Oct 29, 2012 at 11:08 PM, null zeroroute nullzero.ro...@gmail.comwrote: I'm familiar with a bug CSCsk07136 that was found about 4 years ago that causes the multicast table to dump on a hybrid 6500 (catos) every time a port in the same VLAN went down/up. Basically, all members of a group would lose access to the group every time a port in the same VLAN, on the same 6500, dropped. I believe the problem was fixed in a later release, however we upgraded to native and no longer experienced the issue. The only workaround was to statically assign hosts to the required groups. On Mon, Oct 29, 2012 at 6:18 AM, Ambedkar p.ambed...@gmail.com wrote: Hi, I am facing a problem in multicast.. The scenario is like this, 2 layer-2 switches(2950) and 1 Layer-1 switch(cisco 6509). These three switches are connected in series, L2-L3-L2. The problem is the packets are dropping at L3(Cisco 6509) switch using catOS. The multicast data is flowing in SAME vlan, means eventhough L3 is there in between, the data is flowing at layer-2 only. Please help me... Thanks, Ambi Have a look at this. Take some time to understand your options. http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008059a9df.shtml If you must stay layer 2, I would suggest IMGP querier and then static mrouter port. If you are not familiar with multicast please understand what the implications of doing the above are before you get on the CLI. tv ___ 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] LX GBIC at half duplex?
On 10/24/2012 1:23 AM, Saku Ytti wrote: On (2012-10-23 22:06 -0500), Tony Varriale wrote: None of GBIC will do half duplex IIRC. And, they won't do subrate. The negotiate is there to appease the other end if it tries. This is painfully common misconception. So some, even serious SPs tend to have standard of disabling autonego and forcing links. Actually, it's not. This conversation was in reference to the media converter. I should have been more clear. Most are dumb devices that don't do much other than create headaches. See the OP for an example. Autonego gives other benefits than agreeing on duplex. Like it is used for RFI (remote fault indication) signalling, which will prevent issues where one side is up and another side is up. See above. Also autonego can communicate that remote end was shutdown administratively, even hardware today supports this, but I've not seen any vendor implement it in software. I think it would be kinda nice to see in syslog, if remove has been shutdown operationally or not. Typically, you will not have that benefit through a media converter. It's shame 802.3 is so very very hard to follow, some professional from industry who knows the standard and has built devices which interoperate should do some write up in wikipedia to clear up on what ethernet can do and specifically why autonego is good. Sounds like you are off to a great start! I would like to see a media converter section, too :) Especially since they do not follow anything other than rough interface shapes. tv ___ 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] LX GBIC at half duplex?
On 10/23/2012 1:40 PM, Jason Lixfeld wrote: Hi all, Running up against an odd issue where we have a 3550 with an LX GBIC trying to talk to a copper port on an ME3600 with a media converter in the middle. The ME3600 side always shows as up; we disabled fault passthrough on the MC. The LX GBIC on the 3550 side shows down/down with negotiation enabled, so with negotiation disabled, it shows up/up, but at half duplex(?!). Anyone seen this before? I didn't think an LX GBIC at half duplex was possible, even with negotiation disabled as there is still no way to force the duplex in that state. Bad GBIC? Media converter borked? Gremlins? I'd be grateful for any insight gleaned from prior experiences.. Thanks in advance. For completeness: Model number: WS-C3550-24-SMI System image file is flash:c3550-ipservicesk9-mz.122-35.SE5.bin TOYF-1.10-1.A920#show int g0/1 GigabitEthernet0/1 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 0014.6aa4.0c00 (bia 0014.6aa4.0c00) Description: Facing gi0-24.pe01.171EastLibertySt01.YYZ Internet address is 1.1.1.1/30 MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not set Half-duplex, 1000Mb/s, link type is force-up, media type is 1000BaseLX input flow-control is off, output flow-control is on ARP type: ARPA, ARP Timeout 04:00:00 Last input 23:14:46, output 00:00:02, output hang never Last clearing of show interface counters 06:02:06 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 144492 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 326 packets output, 122306 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 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 TOYF-1.10-1.A920#sh run int g0/1 Building configuration... Current configuration : 167 bytes ! interface GigabitEthernet0/1 no switchport ip address 1.1.1.1 255.255.255.252 speed nonegotiate end TOYF-1.10-1.A920#show mac address-table int g0/1 Mac Address Table --- VlanMac Address TypePorts --- - TOYF-1.10-1.A920# . TOYF-1.10-1.A920#sh int g0/1 GigabitEthernet0/1 is down, line protocol is down (notconnect) Hardware is Gigabit Ethernet, address is 0014.6aa4.0c00 (bia 0014.6aa4.0c00) Description: Facing gi0-24.pe01.171EastLibertySt01.YYZ Internet address is 1.1.1.1/30 MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not set Auto-duplex, Auto-speed, link type is auto, media type is 1000BaseLX input flow-control is off, output flow-control is on ARP type: ARPA, ARP Timeout 04:00:00 Last input 23:18:01, output 00:00:18, output hang never Last clearing of show interface counters 00:00:32 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 4 packets output, 1210 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 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 TOYF-1.10-1.A920#sh run int g0/1 Building configuration... Current configuration : 148 bytes ! interface GigabitEthernet0/1 description Facing gi0-24.pe01.171EastLibertySt01.YYZ no switchport ip address 1.1.1.1 255.255.255.252 end TOYF-1.10-1.A920# None of GBIC will do half duplex IIRC. And, they won't do subrate. The negotiate is there to appease the other end if it tries. Can you try with a normal connect? My first thought is the converter. I have not met many over the years that I like (and that like me). tv ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at
Re: [c-nsp] VS-S720-10G alternative
On 6/13/2012 8:01 AM, Reuben Farrelly wrote: I have a requirement for a 1G/10G access switch also for a meet-me room project I am working on, and the 4500-X ticks all the boxes - except for the MPLS capability. The lack of this feature means I will likely have to backhaul data back to an MPLS capable switch or an ASR1k in another location. I don't need a unit which can handle 24x10G (240G) of sustained throughput but I do need to plan for a handful of 10G handoffs which may do 2 or 3 Gbps in the near future. Two 10G uplink ports isn't enough, and the 7600 platform looks to be ridiculously expensive for this sort of thing (not to mention space and power requirements). A cross between a 4500-X and ME3600X/ME3800X would be an absolutely killer box. Then again, I guess that would involve Enterprise and Service Provider BU's within Cisco talking (Gert?) ;) Reuben On 13/06/2012 10:44 PM, Andrew Miehs wrote: Sent from a mobile device On 13/06/2012, at 22:00, scott owens scottowen...@gmail.com wrote: for those of you looking at the sup720-10G or 7k ( I have sets of both of them as well ), take a look at Ciscos new 4500X 1U 10G/1G switch/router. With an SFP+ ZR optic this can do just about anything an X2 or XenPak 6704/6708/6716 could do. Except mpls :( ___ Nexus 7004? :) tv ___ 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] Stacking 3750X vs diverse 4948E
On 5/20/2012 3:36 AM, Saku Ytti wrote: On (2012-05-19 22:25 -0500), Tony Varriale wrote: If you follow the rules, those are the easiest, most non-eventful events ever. I've done over 100 and had no issues. This is curious statement, it implies that if you are operating devices as per documentation, nothing ever goes wrong. But I'm sure this really wasn't what you mean. I typically operate networks as to what works. Any manufacturers documentation is never 100% or what works best in the field. For example, on 3750s I manually upgrade IOS to existing stack code rev. I can't explain why they've been uneventful for you, but eventful for us, See above. Maybe your set of features configured in your 3750 in your IOS release is better match. It would be arrogant to assume that non of our problems were caused by operator mistakes, I'm sure some field-techs have done it wrong. Arrogant of you? Or me? I wasn't implying anything. I was giving you an opinion and my experience with 3750s. Now I'm not sure if our failure rate in stacking/destacking is 1% (1 in 100) it is probably less, all I'm saying they fail lot more often than our non-stacked switches. Which part of the switches are failing? Quick bugtool search for 'stack 3750' gives 743 bugs. 569 if these have been modified in last 6 months. 122 have been modified in last 3 months. Do you have NOS service? Or, do you/your team do bug scrubs? How about any type of testing prior to going into production? tv ___ 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] Stacking 3750X vs diverse 4948E, 5K/VSS/ ....
On 5/20/2012 2:49 PM, chris stand wrote: The ability to reboot a 5K by itself, in fact you can upgrade hardware this way, vs 3750x stack is a worthwhile positive point. The ability to separate by distance ... say 100 feet if needed a 5K from its peer ... another positive point. What about 6500 eFSU vs N7K ISSU? What about what happens during a card insert or removal on 6500 vs N7K? IMO if you are doing easy to medium complexity or 10G there is no reason to pick up a 6500 anymore. And, the N7K will probably be cheaper (1G density is cheaper). tv ___ 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] 4500-E EOL?
On 5/20/2012 9:25 PM, Keegan Holley wrote: Browsing cisco.com I found EOS/EOL notices for a few of the 4500E chassis. Someone correct me if I'm wrong but weren't these released in 2010? http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/eol_c51-706059.html Nah. They are 5-6 years old IIRC. tv ___ 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] Stacking 3750X vs diverse 4948E
On 5/19/2012 6:21 AM, Saku Ytti wrote: On (2012-05-18 14:55 -0400), David Coulson wrote: Does anyone have any solid experience with 3750X switches, or stacking in a datacenter in general? I've seen plenty of stacks for We've had quite many 3750 stacks, and we do see more problems in them than in other 3750 stacks. Particularly dangerous events are adding or removing members from stack. If you follow the rules, those are the easiest, most non-eventful events ever. I've done over 100 and had no issues. tv ___ 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] Stacking 3750X vs diverse 4948E
On 5/18/2012 1:55 PM, David Coulson wrote: In a datacenter environment, we typically deploy 4948 top-of-rack switches with L2 uplinks to our 6500 core - Systems get connections into two different switches and rely on OS NIC bonding (mostly Linux) to support switch failures. Switches running STP and in the last four years we've had no issues with this design (including failures of systems connected to diverse switches). A new proposed configuration utilizes stacked 3750X switches, where servers would be connected to multiple switches within the same stack. I have next to no experience in the low-end switches that do stacking, but from a general risk management perspective, it seems like a many eggs and single basket configuration. Does anyone have any solid experience with 3750X switches, or stacking in a datacenter in general? I've seen plenty of stacks for closets/end-users, but I don't see many in a top-of-rack config. Is Cisco stacking typically 'reliable', in that when a switch fails it will leave the remainder of the stack functional? What about a software issue? Does the whole stack crap out and reload, or does the master just fail and a new one get elected? I realize it's a pretty broad question, but it boils down to - Is a stacked switch config significantly less reliable/resilient/available than two TOR switches? David The first and most important question is: Is this a real datacenter? If so, 3750xyz is not for you. Also, the regular 4948s are not much better. tv ___ 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] Stacking 3750X vs diverse 4948E
On 5/19/2012 6:47 AM, Lee wrote: On 5/19/12, Saku Yttis...@ytti.fi wrote: On (2012-05-18 14:55 -0400), David Coulson wrote: Does anyone have any solid experience with 3750X switches, or stacking in a datacenter in general? I've seen plenty of stacks for We've had quite many 3750 stacks, and we do see more problems in them than in other 3750 stacks. Particularly dangerous events are adding or removing members from stack. Also we've seen software defects which only affect stacks, like memory leakage on SNMP polling. Generally, do not add software complexity to the network if you have any practical alternative. STP while PITA, is tried and true and it actually does work in CSCO when configured right. So unless you absolutely need the extra interconnect capacity, go with STP. How about VSS? We're considering it mainly because it would eliminate STP VSS doesn't eliminate STP. Neither does vPC. So, you may want to reconsider. tv ___ 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] Stacking 3750X vs diverse 4948E
On 5/19/2012 7:03 PM, scott owens wrote: How about Nexus 5010s. ^ +10 other than a missing odd feature. The Nexus 55xx are purty nice boxen and have HA features that the 375x only dream about. tv ___ 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] Tuning HSRP timers for BGP routers
On 5/9/2012 8:45 AM, Matthew Huff wrote: We have a pair of Cisco 7204VXR with NPE-G2 running 15.1(4)M3. We are using default timers for the HSRP interfaces, and we are seeing nightly HSRP state changes. Not a lot, but 1-2 a night. This appears to only have started recently. We are looking at logs, but I assume it's due to BGP cpu exhaustion. We don't see any L2 errors on the VLAN where the HSRP is running, so I don't think it's a physical problem. What timers do people use for HSRP on BGP routers as a practice? Obviously we want the smallest timers that would be possible. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff| Fax: 914-460-4139 That's the symptom. I wouldn't recommend changing those timers until you understand what is causing the issue. Sometimes (especially in STP, BGP, etc) changing how the protocol works makes things worse. tv ___ 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] Will the Cisco 2911 push GigE with NAT enabled ?
On 4/30/2012 11:10 AM, Matthew Huff wrote: If you need the full 1GB for VPN, yes, the 5585-X with SSP10 will be the best bet. It will probably be on the close order of 20k though. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff| Fax: 914-460-4139 Keep in mind, Cisco quotes that performance in 1 direction as well. If you need 1gbps in both directions, I would look at the SSP40 as it is rated at 2.5gbps-ish of VPN traffic. ___ 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] FWSM Throughput
On 2/16/2012 1:16 PM, Justin M. Streiner wrote: There are a lot of gotchas with the FWSM that would make them less than ideal for a new deployment (10Gb/s throughput, poor IPv6 performance, ACL/memory partition limits that are not always well documented and fun to deal with at 3 AM, etc). That and typically people aren't deploying 10 year old technology in their new shiny dcs/environments. tv ___ 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] FWSM Throughput
On 2/17/2012 4:22 AM, Peter Boekelaar wrote: We noticed with 40K + ace entries, changes are becoming rather slow 4, 5 minutes wait before de rules are downloaded to de network processors. That's ACE or ACL? Either way, that's a very convoluted security policy. Or, the blade is in a poor network design. tv ___ 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 6k no power enable module
On 12/1/2011 3:52 PM, Mark Mason wrote: We also just labbed a VS-S720-10G running 122-33.SXJ1 and were able to shut a slot down without a module installed. Unfortunately we ALSO were able to incorrectly install a WS-X6748-GE-TX and cause the 3 second bus disruption. Anyone else run into this? 6509-v-e-test(config)#no power enable module 6 %FRU Absent. Power admin state updated 6509-v-e-test(config)#no power enable module 6 % slot is already disabled and not yet enabled 6509-v-e-test(config)#no power enable module 7 %FRU Absent. Power admin state updated 6509-v-e-test(config)#no power enable module 7 % slot is already disabled and not yet enabled 6509-v-e-test(config)#no power enable module 8 %FRU Absent. Power admin state updated 6509-v-e-test(config)#no power enable module 8 % slot is already disabled and not yet enabled 6509-v-e-test(config)#no power enable module 9 %FRU Absent. Power admin state updated 6509-v-e-test(config)# 6509-v-e-test(config)#no power enable module 9 % slot is already disabled and not yet enabled 6509-v-e-test(config)# *Dec 1 21:14:36.304: %C6KPWR-SP-4-DISABLED: power to module in slot 8 set off (admin request) 6509-v-e-test(config)# *Dec 1 21:15:07.123: %OIR-SP-6-REMCARD: Card removed from slot 8, interfaces disabled *Dec 1 21:15:11.027: %C6KERRDETECT-SP-2-SWBUSSTALL: The switching bus is experiencing stall for 3 seconds *Dec 1 21:15:16.063: %C6KERRDETECT-SP-2-SWBUSSTALL_RECOVERED: The switching bus stall is recovered and data traffic switching continues *Dec 1 21:15:18.283: %C6KPWR-SP-4-DISABLED: power to module in slot 8 set off (admin request) Mark From: Mark Mason Sent: Thursday, December 01, 2011 2:38 PM To: 'cisco-nsp@puck.nether.net' Subject: Cisco 6k no power enable module Anyone know why Cisco doesn't allow for you to shut power down to a slot/module unless a FRU is installed in it? We can reproduce 100% multiple times in the lab WS-X6748-GE-TX installation's that causes the bus to stall 3 seconds. It has to do with the force you apply to the card during installation. %C6KERRDETECT-SP-2-SWBUSSTALL: The switching bus is experiencing stall for 3 seconds %C6KERRDETECT-SP-2-SWBUSSTALL_RECOVERED: The switching bus stall is recovered and data traffic switching continues Router(config)#no power enable module 8 %FRU Absent. Power admin state updated Mark The bus stall HAS to occur (and will occur) as to not corrupt data on insert and removal. This is why it is imperative that a) you do this during maintenance windows b) use DFCs. You may not get the message all the time but it still occurs. So, I would say you installed in correctly. If you would have installed it incorrectly, the box would have crashed. As for powering down a slot with no card, I never tried that. Interesting :) tv ___ 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] Three ISPs - Three Edge Routers - iBGP Mesh
On 11/22/2011 8:41 AM, Mark Mason wrote: iscussions. I expect that packets leaving the DC will hit the HSRP active, perform the route lookup and exit via the best path BGP has selected (and/or the best path my PfR setup has installed). Does anyone see any gotcha What does the network look like in the down direction? Firewalls? And I wouldn't use 1.1.1.1. I'd recommend something like 2.2.2.2. It's more...therefore better :) tv ___ 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] 6k Netflow To Be or Not To Be...
On 11/14/2011 1:01 PM, Peter Rathlev wrote: On Mon, 2011-11-14 at 11:15 -0600, Mark Mason wrote: Question of the day... Why turn on netflow in a 6k w/ SUP720-10G if netflow in 6k (minus the SUP2T) is notoriously not good? Because it's better than nothing? :-) Ever use a GPS that takes you to the wrong place? :) tv ___ 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] 6k Netflow To Be or Not To Be...
On 11/14/2011 4:57 PM, Nick Hilliard wrote: e a GPS that takes you to the wrong place?:) pfc3 netflow is fine if you need to measure traffic ratios or protocol spread. Its, uh, built-in sampling mechanism means that although it's unsuitable for some purposes, it's completely fine for others. Netflow is great for many things including telemetry and security. Doesn't mean you can't try to put a 1000hp motor in a Yugo. It will probably be a decent drag car but please don't bring it out to Monza. tv ___ 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] WARNING: Netflow Data Export Hardware assisted NAT not supported on 76xx/65xx on the same interface
On 8/29/2011 8:58 AM, Jeff Bacon wrote: It's un-called-for, certainly. Unfortunate to hear that. It was brief and to the point. If a 6500 NAT knowledgeable person would have been hired, they would have steered clear of it. Design around it. It's the problem of some smaller firms, especially in this business niche. We can't afford to do RFPs for everything, What do RFPs have to do with it? RFPs are typically SUPER counter productive and would have been 100% useless to the OP's issue. and while we have talented staff, If by we you mean the trading industry, yes you have some serious talent pools there. I've done my fair business in the trading business and there are some top notch talent in that industry. sometimes we're just stuck doing a attempt to do it and hope it works because that's the speed the business is moving at, and since your guess is right 80% of the time, you take that bet because better that than slow down the entire process 100% of the time. True. I've been there. But I know as well as you do there is a lot of money running across these networks. IMO the talent and knowledge is there, you just have to find it. Whether it's a referral or searching, that diligence is up to the purchaser/owner of the equipment. On the other hand, if you've been using the platform for about so long, it should be fairly obvious at this point that not everything works as described and just because it's documented - or not-documented - doesn't mean it will work. That's exactly my point. I explicitly stay far away from NAT on the 6500s. Just because a feature is there at your disposal doesn't mean you should use it. The reality, as I can determine, is that not even Cisco really knows what does and does not work when it comes to the 6500. They have a good handle on it. But, some don't. And, a lot of people don't have experience in the trading vertical. So, how can you assume they understand their business and what their needs are? tv ___ 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] WARNING: Netflow Data Export Hardware assisted NAT not supported on 76xx/65xx on the same interface
On 8/29/2011 12:05 PM, Matthew Huff wrote: It took 3 weeks with TAC including a network sniffer trace file to prove to the tech it didn't work. When he escalated it to backline BU engineering, he found out it wasn't supported. It isn't even well known within Cisco. A lot of these things aren't. That really isn't their business model. I could give you 1000s of examples. I really don't think a consultant or TME would have found this limitation either. The whole purpose of this thread is just to have it documented in the nsp archives/google, not to start an argument. I think if you look for someone that has extensive experience in your vertical you would have/will find that person. TMEs are great resources but if they haven't run into this before then they probably wouldn't know. And, I'm not sure how many you will find with trading experience. As far as configuring in a lab, that would be nice, but we hardly have the time for that including setting up a test netflow collector and sending through test data, just to confirm a feature that Cisco market literature advertises. Well I would always recommend it in a lab. But, in general avoid NAT on the 6500. Just design around it. It works but it's really a work around to get a feature into the device that has been requested too many times. It would be nice to spend the time setting up RFP and test labs to verify vendor claims, See my previous post. RFPs are essentially the worst thing you could do. Reaching out in your industry would have been the first thing I would have done. The talent pool is there. but there is no way I can spend the resources to do such at the firm where I work. My time is devoted to actual implantation (we are a algorithmic trading firm). Ahh, I suspected you were more of a manager hence my previous comment of hiring talent. I am sure there are some good consultants out there, but ones that understand market data issues well and the network designs that support them are few and far between. Yes that is very true. But, they are out there. And, you have more than enough talent in your vertical. and this is the first time I've run into a feature limitation with not so much as a caveat or hint of possible limitations. That's an amazing statement. I've run into tons of issues in your vertical across many product lines (6500, 4900M, Nexus, etc). But, that is to be expected. There is no perfect product. You just have to find the right products and design for your business. tv ___ 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] WARNING: Netflow Data Export Hardware assisted NAT not supported on 76xx/65xx on the same interface
likely we will either replace the entire hardware or leave it the way it is. Having to increase latency to add monitoring is the tail wagging the dog. Do you have the tools in place to comment on the latency it will generate and the impact and loss of revenue to your customers? As far as requirements, on the marketing literature for the 7600/RSP720 the hardware assisted nat and NDE are both prominent features advertised. There are no disclaimers stating they won't work together. And there are no promises that every feature will work in every combination. This is applicable for all manufacturers in this space. In fact, I've yet to see any published documentation, internal or external from Cisco that states that it won't work. Just a good explanation from TAC why it won't (The NAT inserts a special Netflow entry that doesn't follow the mls aging timeout, so NDE doesn't work). This goes back to my comment that it's very important to understand what you are buying. It's painfully obvious this is your first time buying and designing networking gear. We have been promised a formal statement from Cisco in regards to this. Once we have that, we will had it over to our legal department and see where it goes from there. ROFL! I can tell you it will go nowhere. tv ___ 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] WARNING: Netflow Data Export Hardware assisted NAT not supported on 76xx/65xx on the same interface
On 8/27/2011 4:31 PM, Matthew Huff wrote: If it was made apparent, could you point to any public documentation that states that? I've scoured Cisco's site, google, and mail archives, and can't find any mention (other than specific caveats) that state that NDE and hardware assisted nat are not supported on the same interface. In fact, it took TAC almost two weeks of escalation before anyone would state it wasn't supported and they couldn't find any documentation that stated that. As far as speaking to a TME, I work in small trading firm. We don't have the luxury of long, involved RFP with detailed descriptions or time to work with a TME to discuss every detail of every configuration we use. We expect if a vendor advertise features, that they should work, except when they are documented (like caveats). Having two major features (and they are both listed as major features in Cisco's marketing literature for the RSP720) that won't coexist should be pointed out very obviously in their literature. Then hire someone that knows what they are doing. tv ___ 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] WARNING: Netflow Data Export Hardware assisted NAT not supported on 76xx/65xx on the same interface
On 8/26/2011 11:25 AM, Matthew Huff wrote: We fully expected to be able to use hardware assisted NAT and NDE to monitor the traffic. Why? The netflow output we get is random, sporadic and very incomplete. This is a very well known limitation. After dealing with our Sales team and TAC, we have finally got them to admit that it doesn't work when NAT and NDE are configured on the same interface. Keep in mind, not a lot of people, even within Cisco, really understand the limitations. Nowhere in the Cisco marketing literature, That's marketing. Marketing doesn't list, describe or otherwise details hardware limitation or caveats. Cisco Documentation, or even Cisco bug lists does it mention this. See above. But, I'm sure someone has come across this on this list. There are some caveats listed regarding NDE and NAT (flow mask conflicts, and fragments), but even given that, the caveats imply that it will work if the caveats don't apply or the flowmask conflicts are resolved. Also, there are no warnings when configuring it. The feature manager shows no errors or conflicts, etc... The platform (and related 6500) are VERY well known to have serious limitation around netflow. NAT is a netflow assisted feature. At every step, in my opinion, cisco has been reluctant to admit that it doesn't work. See my above comment. I know people with 10 years of 6500 experience that don't know some of the limitations. Had we known of this limitation, Was that part of your requirements previous to purchasing it? Are you working with knowledgeable people? It's unfortunate that the platform doesn't meet your requirement. I hope you can find some knowledgeable Cisco people in the future to help you with your design and purchasing. tv ___ 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] remote location voice qos with switches
On 8/16/2011 8:47 PM, Dan Letkeman wrote: Hello, I have a remote location, where I have a 3560 which connects to our main location via a wireless bridge and goes into a 3560G. The wireless bridge has approximately 70mbps throughput. This remote location has about 12 7962 phones, and for the most part everything works fine, except when some of our I.T. staff are doing large backups or copying images across the link. What would be the most simple qos config to solve the data transfers from hogging the link? Or maybe not qos, maybe just policing? Thanks, Dan. ___ 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/ You'll need to implement QoS on the radios for that to work out for you. tv ___ 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] best way to get around IPSEC subnet Conflicts.
On 8/15/2011 4:38 PM, -Hammer- wrote: Not sure about what everyone else is recommending but our solution (with several hundred B2B tunnels now) was simply to make it policy NEVER to run 1918 address space in the tunnel. We usually tell peers that they must provide public IP space which will then be NATted on our side. We also have a block of our own ARIN space that we sometimes use. Either way, it's always tunneled and NATted and never seen anywhere else. Extra config? Yes. Sanity? A little. -Hammer- I was a normal American nerd -Jack Herer On 08/12/2011 02:53 PM, Brent Roberts wrote: I am looking for the best way to get around IP conflicts (On the Far Side) in fully redundant Hardware solution. I am working in a large Scale Hosted application environment and every 5th or so customer has the same RFC1918 Address that every other small shop has. I have a Pair of ASA 5520's (SEC-K9 8.2(2) in A/S) and it seems that I am either missing something or it may not be possible due to IPSEC priority. I typically use the SET-Reverse Router and redistribute static via OSPF to the L3 Core. I was thinking about moving to a 6509 with redundant sup720's and using IPSEC AWARE VRF's (1x 7600-SSC-400/2xSPA-IPSEC-2G) to get around this limitation. Any feedback on this idea. Negative/Positives of this setup? I am only looking to move about 100 meg aggregate of IPSec Traffic. Thoughts welcome on and off list. ___ 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/ That's it. Public space. It pushes all the nasty stuff out to the edge companies. tv ___ 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] half duplex question
On 8/3/2011 3:56 PM, Nick Hilliard wrote: Nonsense. With half-duplex, you'll get about 7-8 megs of traffic on the link before it starts petering out. Collisions are a normal part of half duplex operation, so if you see a bunch of collisions in the interface counters, there's nothing to worry about. It's excessive collisions that cause the problem. Nick I was thinking he'd get about 12mbps full duplex out of that. 10mb (half duplex) x 2 (each way, half duplex) x 60% efficient = 12mbps. The half duplexes cancel each other out. tv ___ 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] Is Performance Routing, PfR a dead duck?
On 7/24/2011 6:29 PM, Eric Hileman wrote: Is Performance Routing, PfR a dead duck? Did they stop developing it? Or does it suck so bad no one uses it... I'm speaking in the context of a multihomed content provider optimizing wan traffic. But any info is welcome :) ___ 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/ It's not dead and I've actually seen it in use a couple of times. Look up OER. I believe Dana Blair was/is the principle engineer. tv ___ 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] Number of route reflectors, best practice?
On 7/23/2011 3:01 PM, Peter Rathlev wrote: On Thu, 2011-07-21 at 22:22 +0200, Gert Doering wrote: Just because everybody else does it is a no-go in my book :-) - we currently have a design similar to your current design, that is, all core routers (8) are full-meshed, and all edge routers in a given POP use the core as RRs. Edges have only edge-routes plus default, so the computational effort on the RRs is not that bad. And we don't need extra boxes... If both cores fail in a POP, that POP is down anyway, and I don't need to worry about RR reachability either. Those are compelling arguments, though I'm not sure we're big enough for that. The network is physically partial mesh, and the dozen PoPs aren't geographically hierarchical in relation to the main datacenters. Furthermore, we currently have a very collapsed design where the current RRs are also terminating customer (internal) networks. This has worked well for us, but it does present some interesting problems regarding scale and potential DoS. (Oh, and we were advised by expensive consultants to introduce seperate RRs. And buy Nexus.) Assuming your network is of decent size I get the dedicated RRs. But, I'm a little more curious as to the Nexus pitch. :) Your consultants/partner not work with a lot of ISPs? Or, thinking of doing something interesting with FabricPath? tv ___ 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] sup2T software release notes have hit
On 7/19/2011 1:11 AM, Phil Mayers wrote: On 07/19/2011 02:25 AM, Tony Varriale wrote: Well I had the pleasure of watching one boot last night and I'm not very optimistic as to my original statement. No word back from Cisco yet to confirm. How long did it take to boot? Was it faster than the glacial 300 second average for a sup720? Honestly I didn't time it but it seemed much faster. I'll see if I can get access and time it. tv ___ 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] sup2T software release notes have hit
On 7/19/2011 1:36 AM, Phil Mayers wrote: On 07/19/2011 02:23 AM, Tony Varriale wrote: Well, neither of those (I'm sure of the 6708 and almost 100% on the 6716) actually have a CFC and the DFC is not a FRU. Hence, the issue. You're correct that both the 6708 and 6716 do not come with / cannot use a CFC, but they differ w.r.t. DFC4 upgradeability: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Config_Notes/OL_24918.html WS-X6716-10GE DFC3A, DFC3B, DFC3BXL, DFC3C, or DFC3XL Upgradeable? Yes. With either a WS-F6K-DFC4-E or a WS-F6K-DFC4-EXL This matches what Cisco told me in a very specific response to a very explicit question; the 6716 is upgradeable, the 6708 is not. Note it's a DFC4-E, which is different to the rest of the 67xx cards, which take a DFC4-A. I assume this is form-factor related. ___ Sorry for the confusion here. Yes, the DFC is upgradable to XL. But, what I didn't explain well is that there is no CFC option on the 6708/16. The 6708 and 6716 don't have a dbus or rbus connection and therefore cannot be used in CFC mode. And, due to the above statement, I'm confused on why the 6708 is not moving forward but the 6716 IS. tv ___ 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] sup2T software release notes have hit
On 7/20/2011 2:09 PM, Asbjorn Hojmark - Lists wrote: On Wed, 20 Jul 2011 17:28:46 +0100, you wrote: Well... just because something is easy for Cisco doesn't mean they would do it. They might believe that IOS XE on the ISRs would eat into the market for ASR, so they don't do it. The ISR G2s will Eventually(TM) get IOS-XE too. -A No one cares as much as it is a software platform :) tv ___ 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] sup2T software release notes have hit
On 7/18/2011 5:39 AM, Phil Mayers wrote: On 12/07/11 00:25, Saku Ytti wrote: I don't see any reason why technically you couldn't just rip out DFC from 6708 and run it as centralized card. Maybe the DFC itself is soldered in making this unpractical or maybe centralized performance was deemed by BU unmarketable. My understanding was it's a fairly trivial physical issue which the 6716 doesn't have. I didn't investigate further because we don't have any 6708. ___ 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/ Well, neither of those (I'm sure of the 6708 and almost 100% on the 6716) actually have a CFC and the DFC is not a FRU. Hence, the issue. tv ___ 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] sup2T software release notes have hit
On 7/17/2011 5:10 AM, Gert Doering wrote: Hi, On Sun, Jul 17, 2011 at 10:12:32AM +0100, Nick Hilliard wrote: It's unlikely to be based on NX-OS. However, XE == IOS running as process on linux and -modular == IOS running as process on QNX, so it could relatively easily be a variety of one of these, if it's not IOS running on bare metal. From all I was able to gather, -modular / ION is dead. Lack of progress, lack of buy-in from other BUs, short-sighted management. XE is what the rumors told me the Sup2T would be based upon, but IOS versions like 12.2(50)SY very much sound like IOS-trains. gert Well I had the pleasure of watching one boot last night and I'm not very optimistic as to my original statement. No word back from Cisco yet to confirm. tv ___ 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] sup2T software release notes have hit
On 7/11/2011 1:26 PM, Gert Doering wrote: mmh. Is this IOS? Or IOS XE? I thought the Sup2T was supposed to ship with something modularish? I suspect that the new software will be further away from IOS and closer to NX-OS and/or IOS-XE. I mean, what would the point given all the new stuff? :) tv ___ 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] sup2T software release notes have hit
On 7/11/2011 5:00 PM, Robert Hass wrote: The 6708 card isn't mentioned elsewhere on the page. Specifically not in Table 6. DFC4 Field Upgradable Linecard. Anybody know what that means? Do we have to buy new 6908 cards instead? Or will there be a field upgrade? As 6708 is DFC-only (same as 6716) and cannot work in CFC due to lack of some bus ASICs. You cannot it use with 2T due to incompability DFC4 to DFC3. DFC4 is not supported at all at 67xx linecards. But there is special TMP program for 6708 linecards for upgrade them to 6908. Talk to your account team for details. Robert ___ That's not true. The 6724/48s will be field upgradable to DFC4. 67xx + DFC4 = 68xx. tv ___ 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] sup2T software release notes have hit
On 7/11/2011 5:00 PM, Robert Hass wrote: The 6708 card isn't mentioned elsewhere on the page. Specifically not in Table 6. DFC4 Field Upgradable Linecard. Anybody know what that means? Do we have to buy new 6908 cards instead? Or will there be a field upgrade? As 6708 is DFC-only (same as 6716) and cannot work in CFC due to lack of some bus ASICs. You cannot it use with 2T due to incompability DFC4 to DFC3. DFC4 is not supported at all at 67xx linecards. But there is special TMP program for 6708 linecards for upgrade them to 6908. Talk to your account team for details. Robert Although I agree with you regarding the CFC, I'm confused why the 6708 is not moving forward but the 6716 is. I'll have to probe Cisco. tv ___ 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] sup2T software release notes have hit
On 7/11/2011 5:21 PM, Peter Rathlev wrote: On Tue, 2011-07-12 at 00:00 +0200, Robert Hass wrote: The 6708 card isn't mentioned elsewhere on the page. Specifically not in Table 6. DFC4 Field Upgradable Linecard. Anybody know what that means? Do we have to buy new 6908 cards instead? Or will there be a field upgrade? As 6708 is DFC-only (same as 6716) and cannot work in CFC due to lack of some bus ASICs. You cannot it use with 2T due to incompability DFC4 to DFC3. DFC4 is not supported at all at 67xx linecards. But there is special TMP program for 6708 linecards for upgrade them to 6908. Talk to your account team for details. What puzzles me is that the 6716 card is field upgradable (to DFC4) according to the white paper. But the 6708 isn't. I though they had the same limitations regarding CFC. We probably can't afford any of these this year anyway. If they appear this year at all. :-) Yeah I've looked at the block diagrams that they are similar from the backplane to the FIREs. tv ___ 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 5K software upgrade
On 7/15/2011 9:15 PM, Renelson Panosky wrote: I have 6x Nexus 5k. I have been upgrading the NX-OS in all of them. I've done all of the using TFTP with no issues but there is one of the that keep giving me the same error over and over. Here is the error.(TFTP get operation failed:Undefined error code (2) ) have anyone of you seen this before if so how did you fix it..? Now remember i've done five same setup same software ___ 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/ The only time I've seen this is when I type in the wrong path or filename. tv ___ 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] GRE tunnel to do span vlan across two datacenters?
On 7/6/2011 11:08 AM, Jason Gurtz wrote: A firm has proposed creating a GRE tunnel between two datacenters (using a 3750X stack at each) to create the spanned vlans needed for VMWare failover application. Clearly there is tunnel overhead but I sense there are other failure modes here that aren't so clear to me--I am familiar in concept with GRE tunnels but don't have a heck of a lot of opex. Can anyone share more insight on the merit (or lack of) with this proposed design? I am aware (via this list, thanks!) of several shortcomings surrounding 3750 based stacks, but cisco alternatives seem pricier still or too big. There is dark fiber available, what about VPLS w/ LDP or L2TP solution? Current network is L3 at the access layer w/ OSPF (4507-sup6 access, 4900M cores): A1 /\ /\ C1--C2 \/ \/ A2 Maybe it is better to just overlay stp back on to the network w/root and alt-root at C1/C2 (V1 and V2 are the proposed 3750X stacks)? Scary to me, but an an argument can be made for less complexity -vs.- tunnling/vpn based approach. A1 .V1 /\ . ' / /. ' \ / C1--C2 \` . / \ \/ ' . \ A2 'V2 OTOH, by the time this actually gets done maybe TRILL will be out ;) Hopefully this enterprisy topic is not too OT! ~JasonG ___ 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/ I do not believe that GRE is supported on 3750x. It wasn't on 3560/3750. Previously you were able to config it but about 500pps would send the box to 100% CPU. tv ___ 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] OT: Console cables on new platforms
On 6/28/2011 3:55 AM, Nikolay Shopik wrote: Hey everyone, We just received our 3560X and no console cables included at all, is this new policy for new platforms? I mean no RS-232-RJ45 or new mini-usb console cable at all. Yes. That is an orderable part number now. And, it's not free. I'm glad because the last thing I need to do it throw out one more cable. tv ___ 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] ISSU on VSS
On 6/21/2011 12:31 PM, ryanL wrote: there is indeed ISSU for VSS, even with single supervisor models. There is indeed no ISSU on 6500. What you are referencing is FSU or eFSU. I would suggest you get a product brief from your Cisco team or your preferred vendor/reseller. i recently upgraded from sxi2a to sxi6 with no noticeable impact if you do it right. ISSU has the ability to have 0 impact. that said, you do lose 50% of your cluster capacity. so i guess it depends on your interpretation/requirement for ISSU ;-) This isn't an interpretation, unless it's yours. The rest of the world that is familiar with the 6500 will tell you the same. That's FSU or a variant. on the flip, i can attest that sometimes ISSU doesn't work for various reasons, If you are referring to the 6500, it doesn't work because it doesn't exist. tv ___ 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] VSS - Horror stories, show-stoppers, other personal experience?
Btw - i would recommend using both 10g ports on the sup720 10g for the vss links. Yes, this is super recommended. There is more than the obviously benefit of using these links. tv ___ 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] VSS - Horror stories, show-stoppers, other personal experience?
On 6/17/2011 1:51 PM, Murphy, William wrote: We are running VSS for distribution layer switching in a campus environment and have been quite pleased with it... Benefits for us are simplification, faster convergence and better performance (distribution of traffic)... No more STP blocking ports, MCE to access-layer so both links are utilized, faster convergence, no need for HSRP, also our two 10G uplinks are equal-cost even though they are connected to separate chassis... It's worked quite well except for ISSU... We have attempted using ISSU to do hitless IOS upgrades with maybe 20% success rate... There is no ISSU on the 6500 platform and never will be. tv ___ 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] VSS - Horror stories, show-stoppers, other personal experience?
The new software should now support dual supervisor per chasis and soon with the sup 2t 4 chasis! Please make sure you understand the failure scenarios and how the dual sups actually work. It probably doesn't work as you think it should. We are only running IPv4 on our boxes - (entereprise environment). The Sup2T will fix most of the IPv6 problems as it is EARL8 based. So, if you want to stick with 6500 and you need IPv6 it's highly recommended you move to the Sup2T. tv ___ 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] VSS - Horror stories, show-stoppers, other personal experience?
On 6/16/2011 5:05 PM, Mike G wrote: Hey all, We're looking at implementing VSS between our distribution/core switches, which are currently in a high-availability configuration using HSRP. From my research so far, the system is straight-forward and the limitations and requirements are fairly well documented. Has anyone had personal experience with a VSS deployment? If so, do you have any horror stories, caveats, and/or recommendations? I'm also interested in people's experience with IPv6 implementation in a VSS environment. If this is your first go at it, I'd recommend getting a really good brief on it and also do acceptance/failure/etc testing before production. This will really help you understand how it works and how to troubleshoot in the event something goes wrong in production. Depending on your time frame, if you can I would wait for the Sup2Ts to come out. With that said, I've had very good experiences with VSS. tv ___ 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] cat6500/fwsm performance
On 6/3/2011 3:30 PM, Jeff Bacon wrote: I am, however, left with one mystery. How can the Cisco docs on a FWSM claim a 30-usec latency when clearly it isn't capable of that, at least not in any configuration that I'm aware of? Granted that it's all lies, damn lies, and marketing material, but putting that number in the main data sheet on the main product page for the card is a pretty ballsy lie even for Cisco. From: David White, Jr. (dwhitejr) [mailto:dwhit...@cisco.com] Sent: Friday, June 03, 2011 12:04 AM To: Jeff Bacon Cc: Pete Templin; Peter Rathlev; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] cat6500/fwsm performance And here is a great doc TAC wrote up on single flow TCP performance which should answer all your questions: https://supportforums.cisco.com/docs/DOC-12668 Sincerely, David. ___ 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/ How are you calculating that number? Right before it, it says 30ms. What about that? Ever think it may be a typo? The way that stated that sentence looks very ambiguous. Typically Cisco is correct on the numbers, but how they calculate that number isn't always obvious. How do you calculate the Sup720 throughput? tv ___ 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] cat6500/fwsm performance
On 6/2/2011 3:09 PM, Jeff Bacon wrote: Hi folks - So, in an attempt to address some fun issues with NAT I'm having with my 6500s, I'm considering resorting to the use of an FWSM as a fancy specialized NAT device - call it a complicated hairpin, if you will (one VRF is on one side of the FWSM, one is on the other, the VRFs communicate with each other via VLANs set to pass through the FWSM, which is in transparent mode). I'm not seeing the NAT or fancy hairpinning in your config below. This doesn't seem like it would be such a terribly difficult project, but... I'm seeing round-trip latencies of approx 250us pushing data through the 250 us? I assume you mean ms. FWSM, and a relatively ridiculously high rate of packet loss. This is just with having the firewall in transparent mode, two hosts on one vlan and two hosts on another VLAN bridged via the FWSM, with all inspection turned off. Are these cards _really_ that bad? Or am I missing something really dumb and obvious here? Generally no, they aren't that bad. But it's hard to say what's going on with the data you presented so far. tv ___ 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 CSS 11501 Load Balancers
1. Do you know if this is all the attributes that a CSS's can route traffic based on? From the CSS config guide exert below i.e. L3, L4 and L5 * destination IP * destination port * protocol * domain * context path There are more. 2. What about other methods: * source IP * source port * server certificates? * client certificates? * any others? Yes, there are others. All of them are described and detailed configuration guide(s). You should start here: http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_installation_and_configuration_guides_list.html Look for the balance command. 3. Do they support SSL client authentication rather than server authentication? Yes. See the SSL configuration guide from the above main link. 4. If 3) is true, do you know how many client certificates can they host? I do not remember the limitations as it's been a while. It may be in the docs. And, I don't have them up in my lab yet to verify for you. 5. Are the load balancers capable of probing a service to determine if there are packet delays on a network or a server resource is very high, then make a decision based on certain criteria i.e. route traffic to another server or network? Yes. In Ciscoland with CSS, these are called keepalives. See the Load-Balancing configuration guide. 6. If a service is configured to forward to tcp portany (not www traffic), http keepalive is used and a 200 OK status is not returned, the server (xx) is then assumed down and therefore any new traffic is sent to another server in a group. If server (xx) is not actually down just http/443, will any traffic that was established when the load balancer saw the (xx) http keepalive go down, continue to flow back via tcp portany to the load balancer and to whence it came from? Or will it be dropped / lost as the load balancer will lose any translations? I'm not sure I'm following your example. Just because a server does not use the standard HTTP port does not mean it works differently on the CSS. You just specify the port for the service and the keepalive. Sam Hall Senior Network Engineer tv ___ 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] Is a 6500 still the best choice?
On 4/26/2011 9:23 AM, Leigh Harrison wrote: Main feature we use is MPLS Which MPLS feature(s)? and we need 10G port density How dense? What's your business? Is a 6500 still the best bang for your buck or does the lack of anything over 10G ports hold it back? If you need truly dense 10g, the 6500 isn't going to cut it. It appears the Sup2T will be out this year sometime (yeah yeah I know I've heard it too for the last 3 years). That will get you 80g/slot. Also, what's your timeframe for eval to implementation? tv ___ 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] disabling GigE negotiation on NX-OS
On 4/15/2011 1:07 PM, Gert Doering wrote: Hi, yesterday, one of our customers tried to move two GigE-on-fiber circuits from a Catalyst 4507 to a new Nexus 5548. The other end terminates on some carrier gear (and is then multiplexed in whatever ways across the city). After moving the circuit, the link didn't come up on the Nexus, but the carrier gear *did* show link. I wasn't on-site, so I couldn't investigate myself, but it smells very much like GigE link negotiation being disabled on the carrier gear - carriers love that. Of course we do not have access to either the Catalyst nor the Nexus, but it's our duty to make it work (after all, we provide the fiber patches!). So I'd like him to test disabling link negotiation on the Nexus, but don't know how to do that - no access to any NX-OS gear yet. On CatOS, this is set port negotiation x/y disable. On IOS, it's int giga x/y / speed nonegotiate. -- How to do it on NX-OS? http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli_rel_4_0_1a/BasicEthernet.html refers to Layer 1 autonegotiation, but no word on turning it off... gert ___ 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/ Hmmm interesting. Force it? speed 1000. ___ 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] disabling GigE negotiation on NX-OS
On 4/15/2011 4:24 PM, quinn snyder wrote: dug through some kit -- found sfp-ge-s and a 62.5um cable. same interfaces being used. link came up for me. again -- this is with n5000, not n5500, but i wouldn't think too great of a difference? Although the UPCs/ASICs are different (gatos vs carmel) I suspect they will be similar in approach to this issue. I have not come across this in any of my experience or docs. Then again I haven't tried to do this type of connection with the Nexusen. Maybe the requisite Cisco peeps will comment. tv ___ 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] Understanding 10G line card oversubscription
On 3/23/2011 3:57 AM, Phil Mayers wrote: The N7k is a nice platform in many ways. Far higher performance, better software and some interesting features like mcLAG. It would be a great fit for us, *if* it had the MPLS feature set. It doesn't == a shame (for us) Phil, looks like Cisco is launching (has launched) their marketing for MPLS phase 1 on N7K. http://www.cisco.com/en/US/prod/switches/ps9441/ps9402/nexus_7000.html#~MPLS tv ___ 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] FWSM upgrade
On 3/31/2011 1:29 PM, John Snow wrote: Hi I am fairly new to fwsm, but what I need to do is upgrade from 3.1 to a 3.2 release. I don't have a spare blade to test this on so I will be upgrading on prod on the fly. I am putting a plan together before I make the change to avoid as much downtime as possible. I would like to boot into cf:5, load the image and config, make sure everything is working as expected and then either load new image and config into cf:4 or copy the image and config from cf:5 into cf:4 and then boot from cf:4 again. 1. Configure vlan1 on msfc interface Vlan1 description **in shutdown mode normally** li1 ten-193-9 10.193.9.0 /24 rsvd fwsm rom-boot cf:1 vlan 1 ip gw - ftp relay.sait ip address 10.193.9.254 255.255.255.0 end 2.Boot into maintenance partition #hw-module module 9 reset cf:1 3. Console session into fw sess slot 9 proc 1 4. Configure ip address/sm/gw root@localhost.localdomain#ipmailto:root@localhost.localdomain#ip address 10.193.9.1 255.255.255.0 root@localhost.localdomain#ipmailto:root@localhost.localdomain#ip gateway 10.193.9.254 make sure I can ping ftp server root@localhost.localdomain#pingmailto:root@localhost.localdomain#ping 142.110.254.131 5. ftp image into flash cf:5 partition root@localhost.localdomain#upgrademailto:root@localhost.localdomain#upgrade ftp://user:pw@142.110.254.131/C6SVC-FWM-K9-3-1-1.BIN cf:5 Application image upgrade complete. You can boot the image now. root@localhost.localdomain#exitmailto:root@localhost.localdomain#exit 6. boot into cf:5 #hw-module module 9 reset cf:5 7. load avtivation key FWSM(config)# activation-key df9f1b5a 38203d9f 1a65ca81 3920ba83 Now at this point I have an image in cf:5, but no configuration yet. This is where I am a bit stuck. I need to load/copy image into cf:5 - test - then move the image and config back into cf:4. Any help would be appreciated. I would save my config, load the software then reload. 3.1x to 3.2x isn't anything big. If you are already on 3.1 you have the correct maintenance software. http://www.cisco.com/en/US/docs/security/fwsm/fwsm31/upgrade/guide/fwsm31up.html#wp2070189 tv ___ 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] 3845 maxing out at 400 Mbps
On 3/28/2011 11:05 PM, Frank Bulk wrote: Packet sizes are believed to be roughly equivalent between both 3845's because our upstream is just preffing some subnets toward one path than another. I checked everything CEF/interface related on both routers and it all appears to be correct and healthy. Thanks, Frank Well they definitely are not. You have roughly the same throughput and almost double the packet rate on the second box. Also as someone else said I'm guessing you are using the gig card and that's the one that bounces off of 400mbps? The 3825/45s come with 2 built in gig ports only. What's your expectation on throughput on these boxes? Quite frankly, I think you are doing very well. tv ___ 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] Fabricpath on Nexus
On 3/28/2011 3:09 PM, Tim Stevenson wrote: For one thing you could provide up to 256 10G links between two boxes, something you could not do with STP. Is this 16 links active per path? If so, what's the LACP game being played? Tim and/or Lincoln, I was hoping you could comment on a couple of other things. 1) The configuration guide recommends that all L2 FP gateways be configured as 8192 priority but do not specify them needing to be root. I'm guessing the docs want the gateways to be root. I think that would have some design implications (FHRP, as well as having to actively take root away from your existing bridge(s)). Would you comment on why this is? All ports need to be designated? I assumed it was an optimal traffic flow to/from the FP domain and the ability to proactively stop loops. 2) In the docs, it states that the FP network automatically presents a single bridge to all CE devices. I assume when you enable FP on the gateways, it plays a vPC peer switch game of the single bridge ID presentation. Or, something similar? 3) In the docs it recommends not to use the vPC peer switch feature. Is this because of the multipath calc in the FP domain? Any implications from a STP role change here? 4) QoS? 5) PLVAN type feature? Thanks! tv ___ 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] 3845 maxing out at 400 Mbps
On 3/28/2011 9:14 PM, Frank Bulk wrote: We have two 3845's as border routers, each with three GigE interfaces (one facing upstream, the other downstream, the third facing the other 3845). The first 3845 has a typical packet-size mix (residential/business Internet) is consistently maxing out at 400 Mbps (predominately ingress because of asymmetric routing) running at about 43 kpps and 40% CPU. It's flat-lines very evenly, uncannily so. We checked and double-checked transport and it's set much higher, the same as the second 3845. The second 3845, which has a mix of both ingress and egress traffic at a combined 82 kpps (35 kpps ingress/50 kpps egress) but lower combined 360 Mbps operates at a higher CPU (presumably because there's also egress traffic) with no flatlining. The ACLs are BCP 38-oriented with eBGP; no rate-limiting. We're running 124-11.XW2. Any ideas? The numbers are well below Cisco's router spec sheet. Frank The first idea is pretty obvious: different packet sizes. Why so? The second idea would be to make sure you are staying in the CEF path as much as possible. Verify that yet? tv ___ 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] How to use multiple virtual web servers with one 1 public IP address?
On 3/28/2011 8:22 PM, Bayasgalan Bayantur wrote: I'm working on a solution where we will be setting up 40 virtual web servers on a single server using Linux Redhat and VMWare . Unfortunately, we only have 3 free public IP addresses to use, so I need to have a basically a single public IP which would route a request to the appropriate server. All web server using TCP 80 port. which kind of solution in cisco router and switch ? No Cisco solution. Talk to your web server admin. He'll know what to do. tv ___ 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] Understanding 10G line card oversubscription
On 3/23/2011 3:57 AM, Phil Mayers wrote: Why would I bother listening to details/timelines from them? They've been wildly, wildly inaccurate in the past. True. Some things (like Sup2T) are worse than others. At this point, Cisco could tell me it's out next week and I wouldn't base purchasing decisions on it ;o) LOL! Yeah I wouldn't do that either. The N7k is a nice platform in many ways. Far higher performance, better software and some interesting features like mcLAG. It would be a great fit for us, *if* it had the MPLS feature set. It doesn't == a shame (for us) Some people are more plugged into the beta and release process for the Nexus line. I've been fortunately enough to do that for a number of features across N7K, N5K and the N1010. When those features were solid during the beta phase, they were released appropriately and fairly quickly. So, that's all I can say right now :) What do you expect me to do? Give them a round of applause? They do get *paid* to do this after all. And let's face it - fairly good job is not exactly a ringing endorsement. Congratulations! You're not doing badly! ;o) LOL! No. But, I would say given the past with the 6500, I much prefer the N7K and think it's been a much more positive process. Bug free? Absolutely not. At the end of the day, I'm sure the nexus range will sell fine without weirdo edge-case UK universities as a customer. But for me, it's a shame that, where the 6500 was a swiss army knife, the new platforms seem to be less so. It worked well for us, giving us great performance at relatively low cost and ease of sparing, testing and deployment. I'm not sure that edge N7K deployments are weird. But, if you are interested I'm always willing to listen/learn about things people are doing with their equipment (or where new ones may fit). Feel free to contact me off list if you want to chat. tv ___ 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] Understanding 10G line card oversubscription
I've heard very shortly from Cisco before. Frankly, they've got no belief credits with me. Unless and until I see it, it's vapour. We all have. If you are considering the platform and need those features, get a hold of your partner and/or Cisco account team. Unfortunately I can't share those details/timelines. As for features - full parity with the feature set on 6500, so: L3VPN including 6vPE EoMPLS FRR Autotunnel And although this isn't on 6500, on a newer platform I expect VPLS for good measure. I heard that the feature will be there. Now, the chipset inside the N7k may be capable of a bunch of wondrous things, but without the software it's just so much expensive fused sand. I find it *extraordinarily* hard to believe they'll reach MPLS feature parity with the (current) 6500 in any timescale less than 2 years. Considering it's a 3 year old platform, you are asking for a lot IMO. The n7k wasn't really meant for what's it's doing and going to do. Oh, the 6500 platform is 11 years old this year. But, there are other platforms that meet your requirements. Which is a shame, because a lot of the Nexus features look great; NX-OS certainly seems to have a better, newer structure and both the control and forwarding plane are a lot faster on the N7k. I'm not sure I get the shame part. Which part is a shame? I would love to be proven wrong. Maybe NX-OS is built in such a way as to permit speedy feature development. But unless and until it's shipping, and the bugs are ironed out... Any software development cycle is going to be that. As stated above, Nexus wasn't really expecting to support service modules, MPLS other whiz bang features initially. But, it will. So, I think they are doing a fairly good job considering. tv ___ 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] N5K with Generic Copper sfp
On 3/21/2011 6:22 PM, Thomason, Simon wrote: Hey All, Was just wondering if anyone has had much luck using generic copper sfp in a nexus 5020? I have run into an issue with a generic SFP will not bring the port up on my 5k but a Cisco one work first time. I do know that Cisco will say to use a Cisco sfp but there is a rather big price difference between generic and cisco :( log--- EMP31D12NEXUS# sh interface ethernet 1/16 transceiver Ethernet1/16 sfp is present name is OEM type is 10Gbase-(unknown) part number is GLC-T-CRB revision is A1 serial number is TT1209160022 nominal bitrate is 1200 MBits/sec Link length supported for copper is 100 m(s) cisco id is -- cisco extended id number is 4 ! Eth1/16TBA - 10.53.109.x/ down 314 full10001/10g EMP31D12NEXUS# sh interface ethernet 1/16 transceiver Ethernet1/16 sfp is present name is CISCO-AVAGO type is 10Gbase-(unknown) part number is ABCU-5710RZ-CS4 revision is serial number is AGM1327260K nominal bitrate is 1300 MBits/sec Link length supported for copper is 100 m(s) cisco id is -- cisco extended id number is 4 ! Eth1/16TBA - 10.53.109.x/ up 314 full10001/10g log--- ---config--- interface Ethernet1/16 description TBA - 10.53.109.x/24 switchport access vlan 314 speed 1000 storm-control broadcast level 0.50 udld aggressive channel-group 18 mode active ---config--- $50 off vehicle inspections An RACQ vehicle inspection is great for new car buyers, or to check for any faults before your warranty expires. Members get $50 off the retail price. For more info visit http://www.racq.com.au/motoring/cars/car_advice/vehicle_inspections Please Note: If you are not the intended recipient, please delete this email as its use is prohibited. RACQ does not warrant or represent that this email is free from viruses or defects. If you do not wish to receive any further commercial electronic messages from RACQ please e-mail unsubscr...@racq.com.au or contact RACQ on 13 19 05. ___ 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/ The unsupported-transceiver used to work but it's been a long while. I suspect it's turned off now. tv ___ 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] Understanding 10G line card oversubscription
On 3/21/2011 6:33 PM, Mack McBride wrote: The 6500 is still quite good if you don't have high throughput requirements (80G). Between that and the many times delay of the Sup2T, Nexus is a $1B business now. The newer Cisco platforms don't do full routing and switching well. Which ones? The Nexus 7K is working on the routing side of things but lacks features (MPLS). I suspect that's coming very shortly. Which MPLS features are important to you? tv ___ 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] Understanding 10G line card oversubscription
It's entirely possible that we just have a very weird mix of requirements... Care to share a couple of them? Having said that, I won't be sorry to see the back of the crappy CPU and 12.2S IOS train ;o) Can I add to your list: eFSU, OIR, fabs and sups living together and punting to CPU on 3rd down? :) tv ___ 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] Non-disruptive ISSU for Nexus 5000
On 3/14/2011 11:25 PM, Brad Hedlund (brhedlun) wrote: Hi Chuck, The switch not being upgraded will keep the vPC connections UP, just as you witnessed when your switch rebooted due to fan issues. However... Prior to the recent 5.0(2) release, IF your vPC connections were reset for some other reason (server rebooting) while you had one of your Nexus 5000s down for maintenance, your server vPC would not come back up. This is because the default behaviour is for the vPC primary switch to first check the vPC interface configuration is in sync with the secondary switch before allowing it come UP. If the secondary switch was down for maintenance you were SOL. In 5.0(2) a new feature was introduced called vPC Peer Config Check Bypass, which if configured, allows the vPC member ports to come UP even if the secondary switch is unavailable. The config check will happen after the secondary switch comes online, and if there is a mismatch only the new leg will be prevented while the existing leg continues to forward. Cheers, Brad Hedlund http://bradhedlund.com -- We waited a long time for this. Previous to 5.0(2) it caused a lot of headaches. tv ___ 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] Opinions about the next 6500/7600
On 2/4/2011 10:22 AM, Mack McBride wrote: The most comparable for the 7600 is the ASR 9K but the cost differential is significant. The Nexus 7000 is supposed to replace the 6500 for an aggregation switch but the cost On a gigabit basis, the N7K is cheaper and has many more working enterprise features (ISSU, troubleshooting tools, netflow, etc) that most shops would appreciate over the 6500. and other issues (bugs and lack of XL card) has slowed adoption. As for bugs, it's like any Cisco product/software these days. Just plan to reduce risk as much as possible. I think we've all seen some surprisingly horrible bugs on the mature 6500 platform. How's modular and real ISSU working out there? XL cards are now standard/priced the same as the non-XL. Done. But, what is your requirement for such large tables? The other issues are getting sorted out which should help the 7K. Such as? Cisco seems committed to the 6500 as a services platform. Yes, it appears they have extended the platform. Sort of like the SUP2T release (for 3-4 years). From my field chats, most concerns have been centered around PoE (and lack thereof on Nexus). So it is likely to be around for a long time. Yeah it will be a good legacy platform moving forward and has it's place. Our company tends to stay away from the bleeding edge so we are still using the 6500/7600. The N7K is 3 years old this year. Hardly what I'd call bleeding edge in technology. In 3 years your servers went through 2 CPU updates. tv ___ 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] Opinions about the next 6500/7600
On 2/4/2011 11:23 AM, Daniel Holme wrote: I wouldn't say Nexus is bleeding edge, it's been around for a while now! Then main drawback for me is MPLS support, but I believe it's coming. --Daniel Holme Yup, probably the single most requested feature that I see at this point. tv ___ 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] Router Upgrade Path
On 2/4/2011 2:40 PM, Rhino Lists wrote: I am currently running a Cisco 7206vxr with NPE-G2 and 2GB. I am peaking at 200M of Internet traffic on one of the GigE ports with 40K pps aggregate. CPU over the last 72 hours looks like the following: 554433333344453233345545545444322232334454545454 31539957549588345596604710877357359813778970060630195538160717382727 100 90 80 70 60 50 *** ** * * * 40 *** * *#**##* 30 # ### ###*## 20 ###*###* 10 051122334455667.. 0505050505050 CPU% per hour (last 72 hours) * = maximum CPU% # = average CPU% I am running BGP and taking 2 Full Routes from 2 different providers. I also have 3 OC-3's and 1 DS3 connected to the router. I am looking for what router I should look at upgrading to or if there is plenty of beef left in this one? -K You definitely have some room but it really depends on your environment. Do you plan on turning on more features? Plan on 50% increase on bandwidth or pps? Really hard to say. But, if you are not familiar with platforms that are considered replacemements/bumps up, start looking before you get buried. tv ___ 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] Opinions about the next 6500/7600
On 2/4/2011 4:27 PM, Mack McBride wrote: The cost per gigabit is not at parity yet for low gigabit rates. If you are talking about 6500 vs N7K (which is what I thought we were discussing), then the N7K is cheaper. And, so is the service. Just simple math. The requirement for full IPv4 tables is governed by multi-homed bgp customers connected at the aggregation layer. I wouldn't try to turn the N7K into an edge peering platform. As for the maturity level, we have a number of bug cases open on every platform we use. Again, this goes for the 6500 as well. I have a handful of bugs open on the N7K myself. I don't notice the bug volume difference as long as you know what you are getting into. I have stable N7K and 6500. And I have wobbly too. We have customers that recently deployed N7K gear and were less than happy with the number of bugs encountered. Yeah see above. I suspect they are not working with a knowledgeable and experienced partner that is familiar with the ins and outs. We would rather not expose our customers to the less mature (and it is less mature) code. In what manner? Out in the street mature? Sure. Mature as in enterprise data center features? Highly debatable. Curiously the ASR 1K which is a newer platform was very well conceived and has been relatively bug free. I am a bit surprised but this is the general consensus I am hearing as well. Server refresh cycle is generally 18 months to 2 years while router refresh cycles are 5 to 10 years. Generally true. And yes we have acquisitions with 10 year old hardware. I noticed the key word there...acquisition. tv ___ 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] Cheap switch that runs same version of NX-OS that the nexus 7000 runs?
- Original Message - From: Drew Weaver drew.wea...@thenap.com To: cisco-nsp cisco-nsp@puck.nether.net Sent: Saturday, January 15, 2011 10:12 AM Subject: [c-nsp] Cheap switch that runs same version of NX-OS that the nexus 7000 runs? Are there any cheap/old switches out there that you can install the same version of the OS that the Nexus 7000 runs? The main benefit of this would be learning the new commands, etc but not having to buy a Nexus 7000. thanks, -Drew Documentation and PEC/GOLD/your fav labs. tv ___ 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] Basic Etherchannel Question
- Original Message - From: Keegan Holley keegan.hol...@sungard.com To: Cisco NSPs cisco-nsp@puck.nether.net Sent: Friday, January 14, 2011 5:50 PM Subject: [c-nsp] Basic Etherchannel Question Just wondering what the general consensus was on hard coding vs. negotiating etherchannels. I've always hard coded them and viewed the negotiation protocols as a possible point of failure. I was thinking it may be a way to diagnose switchport failures that do not cause the link to go down. Assuming the contol plane frames will not be sent if the data path goes unavailable, it seems like it could be a good way to verify the health of the member links. THoughts? ___ 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/ LACP. tv ___ 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 Catalyst 6509-E 4000w P/S
Wow that's amazing. I think that's outside the normal auto-detect range too! tv - Original Message - From: Pete Templin peteli...@templin.org To: Terry Rupeni rupen...@usp.ac.fj Cc: cisco-nsp@puck.nether.net Sent: Wednesday, December 29, 2010 9:25 PM Subject: Re: [c-nsp] Cisco Catalyst 6509-E 4000w P/S On 12/29/10 5:14 PM, Terry Rupeni wrote: Hi All, We just bought a new 6509-E with 4000w P/S. The specs say it requires a 23 A/240V Input is this the max input current permissible? We have an existing 6KVA UPS with output of 16A max. I've used the Cisco Power Calculator and with all the current cards install it will use a max of 1800w way below the 4000w mark. Can I go ahead and use this 16A UPS to power on the our Cisco 6509-E or do I need a 23A/240V Input? The 4k PS requires a high range input, 170-264V I believe. If you feed it high-range voltage, it'll pull the current necessary to run your system. If 16A is sufficient at the voltage you're feeding it, rock on. If 16A is insufficient, you'll have issues. That said, I just witnessed an install two weeks ago where the building electrical was corroded (or worse), and the brand new UPS was only seeing 89V across a 240V feed. The old UPS was so dead it was in hardware bypass, yet the 4kw PSes had been running like champs. pt ___ 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] Problem with Cisco 4900M and SFP-H10GB-CU1M-G cable
- Original Message - From: Jose Madrid jmadr...@gmail.com To: cisco-nsp@puck.nether.net Sent: Thursday, December 30, 2010 12:08 PM Subject: [c-nsp] Problem with Cisco 4900M and SFP-H10GB-CU1M-G cable I have a Cisco 4900M with the OneX adapter module (CVR-X2-SFP10G). I am trying to use a generic twinax cable (SFP-H10GB-CU1M-G) and am getting errors. I was hoping someone on this list could point me in the right direction on solving this issue. What I am getting is the following: %C4K_GLMMAN-3-NONSFPPLUSINONEXCONVERTERHOLE: Non-SFP+ inserted in port Te1/2 ( 1 ), which is for 10G SFP+ OneX Converter. Seems pretty self-explanatory except that the vendor has told me that it is indeed an SFP+ module. I have tried service unsupported-transceiver and still nothing. Any ideas? -- It has to start somewhere, it has to start sometime. What better place than here? What better time than now? I assume the G on your SPF part number was just a typo. Assuming the OneX is good, if I had to guess code on 4900M? What rev you running? Or, the rev on the SPF. tv ___ 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] Problem with Cisco 4900M and SFP-H10GB-CU1M-G cable
And the SFP rev? tv - Original Message - From: Jose Madrid To: Tony Varriale Cc: cisco-nsp@puck.nether.net Sent: Thursday, December 30, 2010 1:43 PM Subject: Re: [c-nsp] Problem with Cisco 4900M and SFP-H10GB-CU1M-G cable I upgraded the device to 12.2(54)SG. On Thu, Dec 30, 2010 at 1:27 PM, Tony Varriale tvarri...@comcast.net wrote: - Original Message - From: Jose Madrid jmadr...@gmail.com To: cisco-nsp@puck.nether.net Sent: Thursday, December 30, 2010 12:08 PM Subject: [c-nsp] Problem with Cisco 4900M and SFP-H10GB-CU1M-G cable I have a Cisco 4900M with the OneX adapter module (CVR-X2-SFP10G). I am trying to use a generic twinax cable (SFP-H10GB-CU1M-G) and am getting errors. I was hoping someone on this list could point me in the right direction on solving this issue. What I am getting is the following: %C4K_GLMMAN-3-NONSFPPLUSINONEXCONVERTERHOLE: Non-SFP+ inserted in port Te1/2 ( 1 ), which is for 10G SFP+ OneX Converter. Seems pretty self-explanatory except that the vendor has told me that it is indeed an SFP+ module. I have tried service unsupported-transceiver and still nothing. Any ideas? -- It has to start somewhere, it has to start sometime. What better place than here? What better time than now? I assume the G on your SPF part number was just a typo. Assuming the OneX is good, if I had to guess code on 4900M? What rev you running? Or, the rev on the SPF. tv ___ 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/ -- It has to start somewhere, it has to start sometime. What better place than here? What better time than now? ___ 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 Catalyst 6509-E 4000w P/S
- Original Message - From: Terry Rupeni rupen...@usp.ac.fj To: cisco-nsp@puck.nether.net Sent: Wednesday, December 29, 2010 5:14 PM Subject: [c-nsp] Cisco Catalyst 6509-E 4000w P/S Hi All, We just bought a new 6509-E with 4000w P/S. The specs say it requires a 23 A/240V Input is this the max input current permissible? We have an existing 6KVA UPS with output of 16A max. I've used the Cisco Power Calculator and with all the current cards install it will use a max of 1800w way below the 4000w mark. Can I go ahead and use this 16A UPS to power on the our Cisco 6509-E or do I need a 23A/240V Input? Appreciate any help. Thanks Terry R No you cannot. The 4000s are annoying unless you need that exactly (including 1 selection in power cables). Most customers buy the 6000s. tv ___ 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] RES: Outbound Load balancing using eBGP
- Original Message - From: Gert Doering g...@greenie.muc.de To: Leonardo Gama Souza leonardo.so...@nec.com.br Cc: RAZ MUHAMMAD raz.muham...@gmail.com; cisco-nsp@puck.nether.net Sent: Thursday, December 23, 2010 11:19 AM Subject: Re: [c-nsp] RES: Outbound Load balancing using eBGP ___ 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/ Plus using a look-good-on-paper-math-model will more than likely leave you disappointed. Unfortunately, outbound traffic patterns do not follow odd/even IP addressing. tv ___ 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 4500 E-Series
- Original Message - From: Sachin Gupta sagu...@cisco.com To: Antonio Soares amsoa...@netcabo.pt; cisco-nsp@puck.nether.net Sent: Tuesday, December 14, 2010 11:08 AM Subject: Re: [c-nsp] Catalyst 4500 E-Series The +E chassis has new mux-buffers to support 48G/slot in the redundant chassis. The higher speed mux-buffers result in the lower rated MTBF. We priced lower to encourage transition. Going forward, I recommend R+E chassis purchases only. Sachin If you are from the BU and expect to hit your bonus, come out with some bundles that are competitive with the 6E. Otherwise, everyone is going to continue buying that price point regardless. tv ___ 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] Spanning-Tree Loop (12.2.18SXF7)
Could be. What's the rest of the file and sh proc cpu say? I'd find out what's eating all that memory first. Also, your original message stated something about collisions. Resolved? Related? tv - Original Message - From: Antonio Soares amsoa...@netcabo.pt To: 'Jared Mauch' ja...@puck.nether.net Cc: 'cisco-nsp' cisco-nsp@puck.nether.net Sent: Friday, November 05, 2010 1:33 PM Subject: Re: [c-nsp] Spanning-Tree Loop (12.2.18SXF7) Interesting, the switch did not crash but a debugfile was generated. And something I can read from that file: Processor Memory: total 388120864, free 276632816, used 111488048 IO Memory: total 67108864, free 22640, used 67086224 (..) CPU utilization for five seconds: 100%/28%; one minute: 99%; five minutes: 99% Memory leak ? It's the first time I see an equipment recovering from a situation like this without human intervention. It would be nice if the impact was not an STP loop... Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Soares Sent: sexta-feira, 5 de Novembro de 2010 17:15 To: 'Jared Mauch' Cc: 'cisco-nsp' Subject: Re: [c-nsp] Spanning-Tree Loop (12.2.18SXF7) The 6500's uptime is 1 year and 16 weeks. The funny thing is that the 6500 recovered by itself, no reload or sup switchover occurred. And I don't see anything wrong with the memory stats. Really strange. Sometimes we prefer a crash :) This STP loop was active a few hours... I can't upgrade without knowing what is the bug. I will keep searching. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: sexta-feira, 5 de Novembro de 2010 17:00 To: Antonio Soares Cc: 'cisco-nsp' Subject: Re: [c-nsp] Spanning-Tree Loop (12.2.18SXF7) There could have been any sort of a memory leak since SXF7 and now that caused you to see this. How long was your device up? I hate to say this, but I would go to recent software (eg: SXF15a/SXF16). - Jared On Nov 5, 2010, at 12:25 PM, Antonio Soares wrote: Hello group, I'm troubleshooting a STP loop that seemed to be triggered by these errors: %PM_SCP-SP-3-LCP_FW_ABLC: Late collision message from module 1, port:029 %IPC-SP-5-WATERMARK: 15612 messages pending in xmt for the port CHKPT:STANDBY SP(208.B) seat 208 %IPC-SP-5-WATERMARK: 20068 messages pending in xmt for the port CHKPT:STANDBY SP(208.B) seat 208 %IPC-SP-5-WATERMARK: 22904 messages pending in xmt for the port CHKPT:STANDBY SP(208.B) seat 208 %PM_SCP-SP-3-LCP_FW_ABLC: Late collision message from module 2, port:039 %IPC-SP-5-WATERMARK: 25710 messages pending in xmt for the port CHKPT:STANDBY SP(208.B) seat 208 %IPC-SP-5-WATERMARK: 28510 messages pending in xmt for the port CHKPT:STANDBY SP(208.B) seat 208 %PM_SCP-SP-3-LCP_FW_ABLC: Late collision message from module 2, port:039 %IPC-SP-5-WATERMARK: 30344 messages pending in xmt for the port CHKPT:STANDBY SP(208.B) seat 208 %SYS-SP-2-MALLOCFAIL: Memory allocation of 1768 bytes failed from 0x4020DCC8, alignment 32 Pool: I/O Free: 148112 Cause: Memory fragmentation Alternate Pool: None Free: 0 Cause: No Alternate pool -Process= Spanning Tree, ipl= 2, pid= 126 -Traceback= 40280990 402826F8 4020DCD0 4020E064 402108DC 4020D0B8 40AAB1BC 40AAB64C 404A3970 404C4F64 404C51A8 404C5460 404AAA58 404AAE40 40A9EE00 40A9D71C These were seen on one of core's 6500. The 6500s are running 12.2.18SXF7. Fortunately the problem went away by itself. The last thing we want is a STP loop in a network with several 6500s and 4500s, right ? :) Anyone has seen something like this ? I'm now hitting Bug Toolkit to see if this was reported before. Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt ___ 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/ ___ 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] 6509 Linecard RAM
- Original Message - From: Saku Ytti s...@ytti.fi To: cisco-nsp@puck.nether.net Sent: Friday, August 27, 2010 9:42 AM Subject: Re: [c-nsp] 6509 Linecard RAM On (2010-08-27 13:40 +), C and C Dominte wrote: Does anyone know how to view the RAM that is currently installed on each linecard in a VSS cluster 2x6509 running SXI2a? I could not find anything on Cisco website, or I did not know where to look for that information. You could do 'remote login module X' and 'sh ver'. But why is this relevant? Only reason to upgrade memory of linecards is if you're running CFC card but want enough memory for ISSU. -- ++ytti eFSU x 2 != ISSU :) tv ___ 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] sup2t -- where the deets' at?
As you can guess, a lot of that info in the slide deck is either incorrect or pushed. I would guess the 2T is going to show up next year. Get with your account team if you need something more specific. What issues are you having on the 04 and 08s? tv - Original Message - From: Anton Kapela tkap...@gmail.com To: cisco-nsp@puck.nether.net Sent: Friday, May 28, 2010 12:55 PM Subject: [c-nsp] sup2t -- where the deets' at? So, looks like there's a few hints as to what's up here from wayback: http://www.cisco.com/web/AP/partners/assets/docs/Day1_03a_Catalyst_Update.pdf page 18, 2Terabit – 80G (and 40G) on all 13 slots Sup2T (Earl8) – 1HCY10 ..rumor has it the -E chassis has fabric lines enough to support 80g/slot, but is this partitioned in the famously-caveated channels that we see today? Will customers and I be reliving 6704/08 issues again? Of course, I could bother my AM or regionals for more marketing materials, but what's the word on the street? -Tk ___ 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] vs. upgrading FWSM on Cisco 6500 from 3.1(13) 3.1(17)
Assuming the secondary is running well and you are confident the config is correct, you should make it active, then perform your upgrade procedure on the primary. There is no failover preemption. So, if the secondary is active and the primary comes up dead or blows up, no harm to your environment other than you need to correct the redundant module. As a side note, I haven't seen that issue on a minor version upgrade. But, I haven't seen 3.1.x in while. The last 3.2.x I did worked great. tv - Original Message - From: Arne Larsen / Region Nordjylland a...@rn.dk To: cisco-nsp@puck.nether.net Sent: Friday, May 14, 2010 5:55 AM Subject: [c-nsp] vs. upgrading FWSM on Cisco 6500 from 3.1(13) 3.1(17) Hi all. Can someone give me a hint about what I might be doing wrong. I'm upgrading fwsm from release 3.1.13 to 3.1.17. I uploaded the new image to the secondary module, saved the config and reloaded the module. It came up totally blank. Every config on each context was gone. So I sat it up again as failover, and the primary module replicated the complete config of all contexts. Now I'm a bit afraid what will happened when I reload the primary module. Has any experienced anything like this. /Arne ___ 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] Cannot join a few multicast groups
I assume you have clients on the router having the issues. Have you verified you are seeing the IGMP membership report? Another troubleshooting step is to do a manual join on an interface (downstream/loopback/whatever) and see what you get. How about some sh ip mroute group_ip count and sh ip rpf ip_addr? Without understanding the topology and configs, that's about all I can give you. tv - Original Message - From: ML m...@kenweb.org To: cisco-nsp@puck.nether.net Sent: Monday, May 10, 2010 9:20 PM Subject: [c-nsp] Cannot join a few multicast groups I'm having trouble joining some multicast streams. The upstream router joins it fine. The upstream has (*,G) and (S,G) in the mroute table. Downstream doesn't have (S,G). This is a sparse mode environment with a static RP. From the router with trouble I can ping the mcast group and get responses from the group members. I can ping the unicast source of the group, the RP..anything I can think of to rule out an RPF problem. Keep in mind that we're having trouble with 5 out of ~400 multicast groups. Of course nothing that we know has changed at all. Thanks ___ 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] Nexus 5xxx VPC peer keepalives
- Original Message - From: Church, Charles charles.chu...@harris.com To: nsp-cisco cisco-nsp@puck.nether.net Sent: Wednesday, April 28, 2010 12:35 PM Subject: [c-nsp] Nexus 5xxx VPC peer keepalives Anyone, Coming up on a design issue with our upcoming first deployment of Nexus 5010s and 5020s in a new datacenter. It's recommended in the following doc to use the mgmt0 interface for peer keepalive messages: http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/layer2/Cisco_Nexus_5000_Series_NX-OS__chapter8.html#concept_47F7274E5FDA489884D0488BC491B066 We're doing a true out of band management approach on this new network, so the mgmt0 interfaces all home back to an OOB switch/router (4507) which houses the NMS gear, etc. My concern is that a reload (or failure of some type) on this OOB switch could cause a 'dual active' situation on all the Nexus pairs of devices . (6 pairs of 5010s, and the pair of 5020s that aggregate the 5010 pairs). I don't think I want that to happen. So the alternative seems to be a back to back non-VPC-peer link between the two devices using a VLAN interface, but I hate the idea of using a 10 gig port just for keepalives. There are what appears to be additional copper mgmt ports on the boxes, but they're covered up, and not in the CLI. Any way to utilize those? Any other possibilities I'm overlooking? Or am I stuck getting 1 gig copper SFPs and crossover cables for keepalives? Thanks, Chuck There are specific rules and actions that are taken when specific failures occur and it's important to understand them. Also, if this is your first go at this, I would highly recommend testing the scenarios so you can get comfortable. Part of the value in Nexus is the vPC. Unless you have a very specific reason that is broken by the vPC, get comfortable with it. The dual active scenario isn't that bad. Oddly enough, I was testing a 350mbps multicast stream in a similiar environment today. 2 5ks that were dual active - workstation on a single attached 2k. The keepalive link was down between those 5ks and had connection to network via peer link only. The 2nd 5k had only 1 uplink to 7k-1. The source of the multicast was on a 2k hanging off 7k-2 and a separate set of 5ks. All multicast packets were received and in order (reliable multicast testing with sequencing). tv ___ 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] ASA NAT problem
- Original Message - From: Eric Magutu emag...@gmail.com To: cisco-nsp@puck.nether.net; Cisco certification ci...@groupstudy.com Sent: Thursday, April 29, 2010 11:45 PM Subject: [c-nsp] ASA NAT problem Hi, Apologies for the cross posting. I have a problem with a NAT on my network. A private IP has been NATed to a public IP on my network. The public IP can't be reached from within my network but it can from outside. I have tried to implement dns doctoring with no success. This is what I have added in my config static (inside,outside) 209.165.201.15 10.1.1.6 netmask 255.255.255.255 dns policy-map type inspect dns preset_dns_map parameters message-length maximum 2048 policy-map global_policy class inspection_default inspect ftp inspect h323 h225 inspect h323 ras inspect rsh inspect rtsp inspect esmtp inspect sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp inspect http inspect icmp inspect dns preset_dns_map ! service-policy global_policy global How do I verify that the dns rewrite is actually taking place? Is there something wrong with my config? -- Regards, Eric Magutu Actually, it sounds like the problem is that you don't have multiple DNS servers and/or split dns. You shouldn't be able to access the public IP from inside. If you are inside, that's what you access. tv ___ 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] nexus 5xx vpc peer keepalives
- Original Message - From: scott owens scottowen...@gmail.com To: cisco-nsp@puck.nether.net Sent: Friday, April 30, 2010 5:35 PM Subject: [c-nsp] nexus 5xx vpc peer keepalives Tony, Read this as well ( it talks about NOT using the mgmt0 for peer keep alives ) - we are trying this too http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/layer2/Cisco_Nexus_5000_Series_NX-OS__chapter8.html After figure 6, step 3 there is this text ; Note VLAN 900 must not be trunked across the vPC peer-link because it carries the vPC peer-keepalive messages. There must be an alternative path between switches NX-5000-1 and NX-5000-2 for the vPC peer-keepalive messages. The problem we are encountering is that if we drop the peer vlan from the 5k to 5k link then we get weird errors as well. I will STRONGLY suggest that you test any possible failure scenario that you can think of. Are you using the 5Ks/ FEXs in dual homed fashion ? I have an open case with Cisco on the use of It's possible you may have read this incorrectly? The keep alive link should never been in the same VRF as your default VRF. Therefore, it should never be going across your peer link. Also, the linked document talks about using mgmt0. We recommend that you configure the vPC peer-keepalive link on the Cisco Nexus 5000 Series switch to run in the management VRF using the mgmt 0 interfaces. If you configure the default VRF, ensure that the vPC peer link is not used to carry the vPC peer-keepalive messages. Try not to over complicate this. It's really simple actually...and it works well. tv ___ 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] nexus 5xx vpc peer keepalives
- Original Message - From: scott owens scottowen...@gmail.com To: cisco-nsp@puck.nether.net Sent: Friday, April 30, 2010 5:35 PM Subject: [c-nsp] nexus 5xx vpc peer keepalives Tony, Read this as well ( it talks about NOT using the mgmt0 for peer keep alives ) - we are trying this too http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/layer2/Cisco_Nexus_5000_Series_NX-OS__chapter8.html After figure 6, step 3 there is this text ; Note VLAN 900 must not be trunked across the vPC peer-link because it carries the vPC peer-keepalive messages. There must be an alternative path between switches NX-5000-1 and NX-5000-2 for the vPC peer-keepalive messages. The problem we are encountering is that if we drop the peer vlan from the 5k to 5k link then we get weird errors as well. I will STRONGLY suggest that you test any possible failure scenario that you can think of. Are you using the 5Ks/ FEXs in dual homed fashion ? I have an open case with Cisco on the use of I didn't respond to all of your questions comments. We never put the keepalive vlan across the peer link. It's always in its own VRF in whatever fashion/implementation on the 5k and 7k. If you have an OOB network that requires the 5k mgmt0 ports to be used there, burn one of 1-8 on a 5010 or one of 1-16 on a 5020 as a gig port and do another VRF specially for the peer link. Done. Yes, most of our customers are dual connected. We've done a lot of testing. But, we have not done what you have. It's not the recommended practice, it's not the correct design and no one around Cisco supports it. So, we don't implement that way. I know the docs (all 1 of them) may seem confusing and contradictory. But, if you follow above you shouldn't have any issues. tv ___ 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] CSS 11501 and non-HTTP protocols
Of course! tv - Original Message - From: Jeffrey Ollie j...@ocjtech.us To: cisco-nsp cisco-nsp@puck.nether.net Sent: Thursday, April 29, 2010 3:43 PM Subject: [c-nsp] CSS 11501 and non-HTTP protocols Is the CSS 11501 able to load balance non-HTTP protocols like IMAPS? For IMAPS I don't need SSL offloading, plain TCP passed through to the bankend servers and the backend wil do the SSL processing. -- Jeff Ollie ___ 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] 10G Ethernet Module
- Original Message - From: Gert Doering g...@greenie.muc.de To: William Jobs wllm...@gmail.com Cc: cisco-nsp@puck.nether.net Sent: Monday, April 26, 2010 4:09 PM Subject: Re: [c-nsp] 10G Ethernet Module (Regarding your question, I can't say. We decided to go for 6500 chassis and SX* IOS - to eventually get software modularity... And how's that working out for you? tv ___ 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 out of stock?
They've had this problem across many product lines for over a year now (4900, 6500, ASA, Nexus, 3560s, etc). We keep hearing that management is working on it. Unfortunately, we've already had a few customers that can't tolerate 4 months lead time, canceled orders and went with the competition. tv - Original Message - From: Jeff Bacon ba...@walleyesoftware.com To: cisco-nsp@puck.nether.net Sent: Thursday, April 08, 2010 9:39 AM Subject: [c-nsp] Cisco out of stock? Word I keep running across is that Cisco is basically out of everything that matters: - there are no 6503 or 6504 chassis to be had without significant waiting - it took a month and change for my guy to find 2 6504s, and I'm very tempted to swap out a pair of 6503s (which would be foolish on my part really) - there are 7 6524s in stock in the entire world - if you need an AC power supply for said 6524, God help you (mine came in from Germany) - 4900s are still going like hotcakes when you can find them - my VAR is literally custom-machining rack-mount brackets for a 6504-E chassis for me because there are none to be purchased anywhere in the world and Cisco says June minimum OK so they've been caught unawares by the downturn/upturn, they cut back on inventory and expected demand forecasts and now they're screwed, but ye criminy! Is this the normal experience out there nowadays? ___ 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] NPE-G1 / G2 performance
- Original Message - From: Matthew Huff mh...@ox.com To: 'Jeff Bacon' ba...@walleyesoftware.com; cisco-nsp@puck.nether.net Sent: Friday, March 19, 2010 3:05 PM Subject: Re: [c-nsp] NPE-G1 / G2 performance What type of interfaces do you need? IF just Ethernet, why not look at a 3560-E with IP services or a 4900M The NAT requirement is going to throw a nice big monkey wrench into that. tv ___ 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/
