Re: [c-nsp] Small 1U-2U DC powered fixed configuration switch
Hi, Look at WS-C3550-24-DC-SMI Arunas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of William Jackson Sent: Tuesday, August 21, 2007 5:57 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Small 1U-2U DC powered fixed configuration switch I am having a hard time finding a low end cisco DC powered switch, 24 port 10/100. I can see that the Cisco ME 2400 Series has this power option. But can it be used a standard layer 2 switch? 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/ - This message has been sent by e-mail system of BITE Group. This e-mail message is intended solely to the person to whom it is addressed and it may contain confidential or legally privileged information. If you have received it in error, please notify sender immediately and destroy this e-mail and any attachments. Opinions, conclusions and other information in this message that do not relate to the official business of BITE Group shall be understood as neither given nor endorsed by it. - ___ 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 15454 ONS
Hello All: -Original Message- From: [EMAIL PROTECTED] [mailto:cisco-nsp- [EMAIL PROTECTED] On Behalf Of Phil Bedard Sent: Tuesday, August 21, 2007 5:20 PM To: Andrew Matthews Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco 15454 ONS It will do everything you listed. The cards are all channelized, it's an ADM at its most basic. They make OC3 and OC12 cards for it but I'd go with the newer multirate cards depending on the density you need. It's SFP based so you can pick and choose which optics you want. Phil On Aug 21, 2007, at 7:58 PM, Andrew Matthews wrote: I have a few questions regarding a Cisco ONS. 1. Are there Channelized OC cards for the ONS? or are they just raw ports that can be done anyway needed? And if so are there OC3 and OC12 Channelized? 2. If 1 is true, can the ONS mux circuits? For example; Can i take 2 OC3s on one side, and mux them into one large OC12? 3. If all are true, what oc3 and what oc12 card is needed? and i think its the IR since i'm not going over 70km between the ons and the connecting device. Thanks Just to add to what Phil said. The ONS platform has gone through several iterations of hardware and major software upgrades. It sounds like you have the chassis but not the cards. If this is the case, or you're starting from scratch, it would be a good idea to either talk to a Cisco Sales Engineer or post to this list with the cards and software revisions you have in play to make sure everything will work the way you expect. There's nothing worse than putting that new fangled card in with an ancient TCC card and having nothing work. :-) Regards, Mike ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] multiple repeated gigE card failures WS-X6748-GE-TX
Hello, I would like to have a feedback concerning this issue because I have the same on my environment. I have had 3 cards fail in 3 seperate 6509 chassis (WS-SUP720-3B). Mod Ports Card Type Model Serial No. --- - -- -- --- 1 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX SAL091272TH Mod MAC addresses HwFw Sw Status --- -- -- --- 1 0013.60a0.daf0 to 0013.60a0.db1f 2.1 12.2(14r)S5 12.2(18)SXE3 PwrDown Mod Sub-Module Model SerialHw Status --- --- -- --- --- 1 Centralized Forwarding Card WS-F6700-CFC SAL091270GR 2.0 PwrDown Mod Online Diag Status --- --- 1 Unknown Did you receive an answer from TAC or another concerning this problem? Thanks for your help. Olivier _ Découvrez le Blog heroic Fantaisy d'Eragon! http://eragon-heroic-fantasy.spaces.live.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/
[c-nsp] sh ip ro keywords
Explain please what do keywords Known via, Redistributing via and Advertised by mean? Rack1R3#sh ip ro 164.1.12.0 Routing entry for 164.1.12.0/24 Known via eigrp 10, distance 90, metric 18063872, type internal Redistributing via eigrp 10, ospf 10 Advertised by ospf 10 subnets Last update from 164.1.13.1 on Serial1/2, 00:08:38 ago ___ 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] automatically enable debugs after a reload
For example, to enable debugging of incoming SSH connections, use the following EEM applet: event manager applet EnableDebugging event syslog occurs 1 pattern %SYS-5-RESTART action 1.0 cli command enable action 2.0 cli command debug ip ssh For versions of IOS that don't support EEM but do support the config command 'do', you could modify the config off of the router and add a 'do debug...' command to the end then copy the config back directly into the startup-config. It's messy I know, but it does work. Regards, Masood Ahmad Shah Nexlinx BLOG: http://www.weblogs.com.pk/jahil/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tassos Chatzithomaoglou Sent: Tuesday, August 21, 2007 4:22 PM To: Oliver Boehmer (oboehmer) Cc: cisco-nsp Subject: Re: [c-nsp] automatically enable debugs after a reload I'm trying to check if CSCed45578 applies to our case, but the first tests show that the proposed workaround doesn't work. -- Tassos Oliver Boehmer (oboehmer) wrote on 21/8/2007 8:25 πμ: Tassos Chatzithomaoglou wrote on Monday, August 20, 2007 6:54 PM: I'm trying to troubleshoot an issue which appears just after a reload and i need to have some debugs enabled as soon as the router boots up. Is there a way i can enable some debugs before a reload and keep them active after the reload? PS: I tried the EEM functionality (event syslog %SYS-5-RESTART, action cli debug) which works fine, but i was hoping for something easier and maybe safer (am i really catching the data starting from the best possible moment?) There is no formal way to enable debugs right after reload, but next to the EEM solution, you could add the below lines to your startup-config (via copy remote-location startup-config) to achieve the same, but we can't be sure that this will necessarily catch all debugs right from the start. [...] ! enable Radius accounting right after startup config is parsed privilege exec level 1 debug radius ! do debug radius ! [...] Guess it really depends on what you need to do.. Which problem are you trying to solve? oli ___ 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] sh ip ro keywords
known via is telling you how the route was received.. redistributing is the protocol that is redistributing the route throughout your network advertised by is who/how the route is being advertised On 8/22/07, Sergey [EMAIL PROTECTED] wrote: Explain please what do keywords Known via, Redistributing via and Advertised by mean? Rack1R3#sh ip ro 164.1.12.0 Routing entry for 164.1.12.0/24 Known via eigrp 10, distance 90, metric 18063872, type internal Redistributing via eigrp 10, ospf 10 Advertised by ospf 10 subnets Last update from 164.1.13.1 on Serial1/2, 00:08:38 ago ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] 6500 GE modules comparison
Hi, Can i replace the WS-6748-GE-TX with WS-6548-GE-TX on a 6513 switch? someone told me that the 65xx has less features to the 67xx, please help me identify what are those lacking features? thanks, kim ___ 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 GE modules comparison
There are significant differences http://www.cisco.com/en/US/products/hw/switches/ps708/products_data_sheet0900aecd8017376e.html -- Tom Sands Chief Network Engineer Rackspace Managed Hosting (210)447-4391 -- Kim Onnel wrote: Hi, Can i replace the WS-6748-GE-TX with WS-6548-GE-TX on a 6513 switch? someone told me that the 65xx has less features to the 67xx, please help me identify what are those lacking features? thanks, kim ___ 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] external modem on 2610 question
If you are using to dial out then AUX, but if you want to use it as a backup for OOB then I would use the console. That will enable you to see any messages appearing during boot up. Aaron On 8/21/07, Conaway, Aaron [EMAIL PROTECTED] wrote: Give these a shot. Cable guide: http://www.cisco.com/warp/public/471/mod-aux-dialout.html Config guide: http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0 08009428b.shtml - Aaron Conaway -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Granados Sent: Tuesday, August 21, 2007 4:00 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] external modem on 2610 question This is probably a basic question but Google isn't yielding the results I need. I'm trying to attach an external modem to a 2610 for backup purposes (not use a WIC). Do I simply attach to the AUX port with the console cable or do I use the console port for this. Does anyone have a pointer for documentation on using an external modem with a 2600 series router? Thanks Scott ___ 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/
[c-nsp] ddts
Does anybody know what's the meaning of ddts? sincerely, Leonardo. Flickr agora em português. Você clica, todo mundo vê. Saiba mais. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Annex-M 877
Hey all, Does anyone know if the 877 which supports Annex-M (3mb upstream on ADSL2+) is a software upgrade or a hardware specific device. I've seen 877-M mentioned, along with 1801-M and an ADSL WIC-M, but I don't know if these are special hardware releases or not. If they are special hardware releases. anyone got any part numbers or know if they cost more. and which countries they are released on. Thanks all. .Skeeve -- Skeeve Stevens, RHCE [EMAIL PROTECTED] / www.skeeve.org Cell +61 (0)414 753 383 / skype://skeeve eintellego - [EMAIL PROTECTED] - www.eintellego.net -- I'm a groove licked love child king of the verse Si vis pacem, para bellum ___ 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] Force initiate DSL connect
On Thu, Aug 23, 2007, Skeeve Stevens wrote: Hi all, Can anyone please tell me how to initiate a DSL connection (forcing to authenticate) on an 877, and is it any different on an 837, etc. It seems to wait some sort of random period before retries. Its just a normal dialer session. Fiddle with the dialer config to set the dial conditions and retry. (And try dialer persistent; dialer idle-timeout 0?) Adrian ___ 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] ddts
On Aug 22, 2007, at 10:53 AM, Leonardo Souza wrote: Does anybody know what's the meaning of ddts? Don't Drop the Soap ? or more that likely... Direct Digital Telephone Service In what context is it being used. -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C Printed on 100% recyclable phosphor. ___ 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] 7204vxr freeze-up question
Can you get it in that condition and get a 'sh controller' and 'show int'? It sounds like the ingress rx driver is locking up. Try the latest 12.4 mainline code (12.4(16)) if you have it in the lab and see if it's there too. Rodney On Wed, Aug 22, 2007 at 11:45:29AM -0400, Adam Greene wrote: Hmm. Upgraded router to 12.3(23). Even after the upgrade, passing 82.3Mbps in / 42.5Mbps out over the 7204VXR's PA-GE interface (plus 1000BaseSX GBIC) causes the interface to stop passing traffic. Reseating the GBIC does not rectify the issue. However, reseating the PA-GE card does. Tried moving the PA-GE card from slot 2 to slot 3 (different PCI bus) and the problem still occurs. Tried with a different PA-GE card. Problem still occurs. I'll try with another GBIC, but that seems unlikely to resolve the issue. It's sounding like I may need to replace this router. Ugh. If anyone has any bright ideas, they are welcome. Thanks, Adam - Original Message - From: Adam Greene [EMAIL PROTECTED] To: Masood Ahmad Shah [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Friday, August 17, 2007 10:22 AM Subject: Re: [c-nsp] 7204vxr freeze-up question Masood, Thanks for the advice. Current IOS is 12.2(13)T16. We'll look into upgrading it. I'll have to see what will support the NPE300; we're running very few features, though, so I don't expect to have an issue... The GBIC is plugged into a Bridgewave radio; power cycling the radio does not resolve the issue, only cycling the router does, so I think the issue is on the router end. But we'll keep in mind the suggestion. Thanks again, Adam - Original Message - From: Masood Ahmad Shah [EMAIL PROTECTED] To: 'Adam Greene' [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Wednesday, August 15, 2007 9:19 PM Subject: RE: [c-nsp] 7204vxr freeze-up question Well, which IOS version you run? I know there are some issues with Intel chipset while it gets connected into cisco GBIC. I strongly suggest updating driver of NIC (if there is), upgrade IOS or change your NIC to check it out... Regards, Masood Ahmad Shah -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Greene Sent: Wednesday, August 15, 2007 8:43 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 7204vxr freeze-up question Hi, I'm running into an issue with a 7204VXR/NPE-300 router with 128MB RAM. A 1000Base-SX GBIC is plugged into one of the slots (not sure of the part # of the card into which the GBIC plugs). We were running some dueling gateways speed tests with the router (packet stream is sent via iPerf to router A, which forwards it to router B, which forwards it back to router A, which forwards it back to router B, until TTL is decremented to 0). Soon after I start sending 75Mbps - 80Mbps of traffic to the router's gig interface via iPerf, the gig interface stops sending / receiving any traffic whatsoever. The CLI of the router remains up, the gig interface reports it is up / up, memory and cpu utilization remain low. No logs are generated. Traffic on other interfaces is unaffected. I shut / no shut the gigabit interface, but traffic still refuses to pass. Only a reload of the router rectifies the issue. I wonder if there is a debug command that could provide some insight into the problem. At this point I am suspecting a hardware issue (GBIC, card, or backplane). Thanks for any insights Adam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] ddts
;) The dts is Defect Tracking System. I can't remember but I think the dd, ok no comment there :), is distributed defect. Rodney On Wed, Aug 22, 2007 at 11:53:58AM -0300, Leonardo Souza wrote: Does anybody know what's the meaning of ddts? sincerely, Leonardo. Flickr agora em portugu?s. Voc? clica, todo mundo v?. Saiba mais. ___ 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] ddts
Hi Leo, In plain words, it means bug. Regards, Kim On 8/22/07, Leonardo Souza [EMAIL PROTECTED] wrote: Does anybody know what's the meaning of ddts? sincerely, Leonardo. Flickr agora em português. Você clica, todo mundo vê. Saiba mais. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] UDLD vs Auto-neg
A question that's been bugging me for a while: what does UDLD give me that running auto-neg on both sides of a link doesn't? If I run auto, link drops if the pathway goes one-way, and won't renegotiate until the pathway is re-established. Isn't that all UDLD does? Perhaps there are some failure modes I'm not considering. Or maybe it has more to do with not running auto on infrastructure links. Comments would be appreciated! Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] SIP-400 GigE vs SUP720-10G GigE
Trying to figure out whether I really need a SIP-400 for WAN facing ethernet links. Can I get away with the GigE uplinks on the new SUP720-10G? Docs suggest it supports SRR. Not sure if this will work if the GigE link is actually sub-rate (which is what I will be facing.) I'm not really convinced that deep buffers/shaping is the only way to go. If I just police, host tcp stacks should do their thing anyway, which pushes the buffering back towards the edge. Real world experience would be appreciated. Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] SIP-400 GigE vs SUP720-10G GigE
Don't need locally significant VLANs, might be doing EoMPLS for Data Center extension (perhaps), but I can always loopback ports for local-switching (LAN ports are cheap.) The question I'm still stuck with: what does shaping give me under congestion condtions? Following some of the threads on congestion, I'm getting the feeling that shaping might change latency, but not much else. In which case, why spend the money? Tim: On 8/22/07, Phil Bedard [EMAIL PROTECTED] wrote: If you don't need locally significant VLANs for things like EoMPLS termination or have a need to do real traffic shaping, then I wouldn't spend the money. Phil On Aug 22, 2007, at 1:16 PM, Tim Durack wrote: Trying to figure out whether I really need a SIP-400 for WAN facing ethernet links. Can I get away with the GigE uplinks on the new SUP720-10G? Docs suggest it supports SRR. Not sure if this will work if the GigE link is actually sub-rate (which is what I will be facing.) I'm not really convinced that deep buffers/shaping is the only way to go. If I just police, host tcp stacks should do their thing anyway, which pushes the buffering back towards the edge. Real world experience would be appreciated. Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] UDLD vs Auto-neg
Tell that to my Cisco(4908G-L3) and HP(4000/5406) switches. Seems to work for me. (Actually with the 4908 you have to set Auto or else you don't get link detection - the port will always show as up.) Tim: On 8/22/07, Church, Charles [EMAIL PROTECTED] wrote: I think UDLD was originally designed for fiber, where there is no auto-neg. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Durack Sent: Wednesday, August 22, 2007 1:12 PM To: Cisco Mailing list Subject: [c-nsp] UDLD vs Auto-neg A question that's been bugging me for a while: what does UDLD give me that running auto-neg on both sides of a link doesn't? If I run auto, link drops if the pathway goes one-way, and won't renegotiate until the pathway is re-established. Isn't that all UDLD does? Perhaps there are some failure modes I'm not considering. Or maybe it has more to do with not running auto on infrastructure links. Comments would be appreciated! Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7204vxr freeze-up question
Thanks, Chuck and Rodney. CEF is enabled. I'm sending about 95Mbps of 1470-byte UDP packets to the PA-GE interface, then the dueling gateways is trying to push that traffic even higher. The router is connected to a radio that can only do 100Mbps, so there's no chance of traffic exceeding 100Mbps in either direction. I'll try 12.4(16) and see what happens. Here's the 'show int' during the outage condition (particularly worrisome to me are the 18 interface resets, all caused by the test. There are also a lot of output drops, which is understandable, 1 no buffer and 1 throttle): r2#sh int g2/0 GigabitEthernet2/0 is up, line protocol is up Hardware is WISEMAN, address is 0007.8420.e838 (bia 0007.8420.e838) Description: *** Wireless Network Mgmt VLAN *** MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 15/255, rxload 24/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Unknown duplex, Unknown Speed, link type is autonegotiation, media type is SX output flow-control is on, input flow-control is on ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters never Input queue: 11/75/0/0 (size/max/drops/flushes); Total output drops: 1173852 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 96026000 bits/sec, 7955 packets/sec 30 second output rate 59502000 bits/sec, 5143 packets/sec 29510670 packets input, 2249605461 bytes, 1 no buffer Received 1686266 broadcasts, 0 runts, 0 giants, 1 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 1513394 multicast, 611 pause input 0 input packets with dribble condition detected 30538392 packets output, 3381947542 bytes, 0 underruns 0 output errors, 0 collisions, 18 interface resets 0 babbles, 0 late collision, 0 deferred 3 lost carrier, 0 no carrier, 2 pause output 0 output buffer failures, 0 output buffers swapped out I don't have a 'show controller' during the outage condition. I'll try to obtain it. I agree, before we swap the router, we should do some more normal tests and see if the problem persists even then at 80Mbps in / 40Mbps out levels. Thanks, Adam - Original Message - From: Rodney Dunn [EMAIL PROTECTED] To: Adam Greene [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Sent: Wednesday, August 22, 2007 12:13 PM Subject: Re: [c-nsp] 7204vxr freeze-up question Can you get it in that condition and get a 'sh controller' and 'show int'? It sounds like the ingress rx driver is locking up. Try the latest 12.4 mainline code (12.4(16)) if you have it in the lab and see if it's there too. Rodney On Wed, Aug 22, 2007 at 11:45:29AM -0400, Adam Greene wrote: Hmm. Upgraded router to 12.3(23). Even after the upgrade, passing 82.3Mbps in / 42.5Mbps out over the 7204VXR's PA-GE interface (plus 1000BaseSX GBIC) causes the interface to stop passing traffic. Reseating the GBIC does not rectify the issue. However, reseating the PA-GE card does. Tried moving the PA-GE card from slot 2 to slot 3 (different PCI bus) and the problem still occurs. Tried with a different PA-GE card. Problem still occurs. I'll try with another GBIC, but that seems unlikely to resolve the issue. It's sounding like I may need to replace this router. Ugh. If anyone has any bright ideas, they are welcome. Thanks, Adam - Original Message - From: Adam Greene [EMAIL PROTECTED] To: Masood Ahmad Shah [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Friday, August 17, 2007 10:22 AM Subject: Re: [c-nsp] 7204vxr freeze-up question Masood, Thanks for the advice. Current IOS is 12.2(13)T16. We'll look into upgrading it. I'll have to see what will support the NPE300; we're running very few features, though, so I don't expect to have an issue... The GBIC is plugged into a Bridgewave radio; power cycling the radio does not resolve the issue, only cycling the router does, so I think the issue is on the router end. But we'll keep in mind the suggestion. Thanks again, Adam - Original Message - From: Masood Ahmad Shah [EMAIL PROTECTED] To: 'Adam Greene' [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Wednesday, August 15, 2007 9:19 PM Subject: RE: [c-nsp] 7204vxr freeze-up question Well, which IOS version you run? I know there are some issues with Intel chipset while it gets connected into cisco GBIC. I strongly suggest updating driver of NIC (if there is), upgrade IOS or change your NIC to check it out... Regards, Masood Ahmad Shah -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Greene Sent: Wednesday, August 15, 2007 8:43 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 7204vxr freeze-up
Re: [c-nsp] UDLD vs Auto-neg
While originally designed for fiber, I also find it useful where wireless bridges are used. Church, Charles wrote: I think UDLD was originally designed for fiber, where there is no auto-neg. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Durack Sent: Wednesday, August 22, 2007 1:12 PM To: Cisco Mailing list Subject: [c-nsp] UDLD vs Auto-neg A question that's been bugging me for a while: what does UDLD give me that running auto-neg on both sides of a link doesn't? If I run auto, link drops if the pathway goes one-way, and won't renegotiate until the pathway is re-established. Isn't that all UDLD does? Perhaps there are some failure modes I'm not considering. Or maybe it has more to do with not running auto on infrastructure links. Comments would be appreciated! Tim: ___ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] IPSec SPA trunk ports and allowed VLANs
Can anyone with a IPSec SPA (SSC-400 plus 2G IPSec SPA) tell me when I should allow a VLAN onto the SPA trunk ports? For example, should a VLAN be allowed onto the trunk if it has an SVI with a crypto map? What about other VLANs in the same VRF? On both SPA interfaces or just one? Here's an example of the interface config: #sh run int gi11/0/1 Building configuration... Current configuration : 321 bytes ! interface GigabitEthernet11/0/1 description VPNSM I-VLAN's switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 1,102-105,108,109,111-191,193-198,1002-1005,2201 switchport mode trunk mtu 9216 flowcontrol receive on flowcontrol send off no cdp enable spanning-tree portfast trunk end #sh run int gi11/0/2 Building configuration... Current configuration : 283 bytes ! interface GigabitEthernet11/0/2 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 103-105,111-191,193-198,1002-1005,2201 switchport mode trunk mtu 9216 flowcontrol receive on flowcontrol send off no cdp enable spanning-tree portfast trunk end I'm reading through the 7600 Series Router SIP, SSC, and SPA Software Configuration Guide right now (page 668) but I'm not quite sure I'm understanding it correctly. The doc is helpful but it doesn't do a good job of explaining the configuration of the SPA ports. For the record we are operating in VRF Mode on Sub720-3BXLs running SRB1. The way I see it I allow the VLANs that have crypto maps assigned to them (with the 'crypto engine slot inside' command) to Gi11/0/1. Then the 'crypto engine slot outside' statement will force incoming IPSec packets to be directed to the SPA so that the vrf statement in the ISAKMP profile will be able to match traffic to individual VRFs. So I think I may have a grasp of what needs to be permitted on Gi11/0/1 but I don't know what's needing on Gi11/0/2. What exactly does the second interface do? Is there a better way to look at this? Thanks Justin ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] 12.2(33)SXH on a ME6500
Does anyone have an operational experience with 12.2(33)SXH on a ME6524 yet? That may be asking a bit much since it came out on Monday but it can't hurt to ask, right? :-) I'm curious to see what it brings to the table over the ZU train. I checked the Feature Navigator and SXH isn't listed yet. Looking through the release notes it looks like they've ported some of the additional features from the SRA train into SXH. I might be seeing things though. Thanks Justin ___ 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] 7204vxr freeze-up question
Here's output from a sh controller during the outage state: Interface GigabitEthernet3/0(idb 0x6363B6DC) Hardware is WISEMAN 2.1, network connection mode is auto network link is up loopback type is none startup time: 176602 usec GBIC type is 1000BaseSX idb-lc_ip_turbo_fs=0x606372F4, ip_routecache=0x11(dfs=0/mdfs=0), max_mtu=1528 fx1000_ds(tx)=0x6363CE6C(0x6363CE6C), registers(tx)=0x3D80(0x3D80), cu rr_intr=0 rx cache size=2000, rx cache end=1872, rx_nobuffer=0 FX1000 registers: CTRL =0x18180005, STATUS=0x000F FCAL =0x00C28001, FCAH =0x0100, FCT =0x8808, FCTTV =0x16E3 RCTL =0x00428032, RDBAL0=0x2000B000, RDBAH0=0x, RDLEN0=0x0800 RDH0 =0x0038, RDT0 =0x0037, RDTR0 =0x, IMS =0x02D6 TCTL =0x000400FA, TIPG =0x00A0080A, TQC =0x, TDBAL =0x2000C000 TDBAH =0x, TDLEN =0x1000, TDH =0x00BA, TDT =0x00BA TXCW =0xC1A0, RXCW =0xCC0041A0, FCRTL =0x80001200, FCRTH =0xAFF0 RDFH =0x14D7, RDFT =0x14D7, TDFH =0x03A7, TDFT =0x03A7 RX=normal, enabled TX=normal, enabled Device status=full-duplex, link up, tx clock, rx clock AN status=done(RF:0 , PAUSE:3 ), SYNC'ed, rx idle stream, rx invalid symbols, rx idle char GBIC registers: Register 0x00: 01 07 01 00 00 00 01 00 Register 0x08: 00 00 00 01 0D 00 00 00 Register 0x10: 32 16 00 00 41 47 49 4C Register 0x18: 45 4E 54 20 20 20 20 20 Register 0x20: 20 20 20 20 00 00 00 00 Register 0x28: 51 46 42 52 2D 35 36 38 Register 0x30: 39 20 20 20 20 20 20 20 Register 0x38: 30 30 30 30 00 00 00 58 Register 0x40: 00 1A 00 00 30 31 31 30 Register 0x48: 31 36 30 38 32 36 34 31 Register 0x50: 38 36 34 35 30 31 31 30 Register 0x58: 31 36 30 30 00 00 00 D8 PartNumber: QFBR-5689 PartRev: F SerialNo: 0110160826418645 Options: 0 Length(9um/50um/62.5um): 000/500/220 Date Code: 01101600 Gigabit Ethernet Codes: 1 PCI configuration registers: bus_no=6, device_no=0 DeviceID=0x1000, VendorID=0x8086, Command=0x0116, Status=0x0200 Class=0x02/0x00/0x00, Revision=0x03, LatencyTimer=0xFC, CacheLineSize=0x10 BaseAddr0=0x4904, BaseAddr1=0x, MaxLat=0x00, MinGnt=0xFF SubsysDeviceID=0x1000, SubsysVendorID=0x8086 Cap_Ptr=0x Retry/TRDY Timeout=0x PMC=0x00210001 PMCSR=0x Software MAC address filter(hash:length/addr/mask/hits): need_af_check = 0 0x00: 0 .. .. 0 0xC0: 0 0100.0ccc. .. 0 0xD0: 0 0007.8420.e854 .. 0 FX1000(type=0x98) Internal Statistics: rxring(128)=0x2000B000, shadow=0x6363D310, head=56, rx_buf_size=512 txring(256)=0x2000C000, shadow=0x6363D53C, head=186, tail=186 tx_int_txdw=0, tx_int_txqe=0, rx_int_rxdmt0=0, rx_int_rxt0=0 tx_count=0, txring_full=0, rx_max=0, filtered_pak=0 rx_overrun=0, rx_seq=0, reg_read=0, reg_write=0 rx_count=128, throttled=1, enabled=1, disabled=1 rx_no_enp=0, rx_discard=0, link_reset=0, pci_rev=3 tbl_overflow=0, chip_state=2, tx_nonint_done=0, tx_limited=0 reset=5(init=0, check=0, restart=4, pci=0), auto_restart=1 tx_carrier_loss=1, fatal_tx_err=0, tx_stucks_count=1 isl_err=0, wait_for_last_tdt=0, ctrl=1885, ctrl0=1895 rx_stucks_count=2, rdtr_fpd=3 HW addr filter: 0x6363DD68, ISL disabled, Promiscuous mode multicast Entry= 0: Addr=0007.8420.E854 Entry= 1: Addr=.. Entry= 2: Addr=.. Entry= 3: Addr=.. Entry= 4: Addr=.. Entry= 5: Addr=.. Entry= 6: Addr=.. Entry= 7: Addr=.. Entry= 8: Addr=.. Entry= 9: Addr=.. Entry=10: Addr=.. Entry=11: Addr=.. Entry=12: Addr=.. Entry=13: Addr=.. Entry=14: Addr=.. Entry=15: Addr=.. FX1000 Statistics (PA3) CRC error0 Symbol error 0 Missed Packets 0 Single Collision 0 Excessive Coll 0 Multiple Coll0 Late Coll0 Collision0 Defer497 Receive Length 0 Sequence Error 0 XON RX 0 XON TX 0 XOFF RX 0 XOFF TX 0 FC RX Unsupport 0 Packet RX (64) 52Packet RX (127) 289 Packet RX (255) 0 Packet RX (511) 5 Packet RX (1023) 0 Packet RX (1522) 433425 Good Packet RX 949328Broadcast RX 46180 Multicast RX 32953 Good Packet TX 0 Good Octets RX.H 0 Good Octets RX.L 657160659 Good Octets TX.H 0 Good Octets TX.L 334817282 RX No Buff 0 RX Undersize 0 RX Fragment 0 RX Oversize 0 RX Octets High 0 RX
Re: [c-nsp] TE over Etherchannel
Will this also be a problem on SR? I'm getting ready to work on this myself. Thanks Justin Rodney Dunn wrote: That's right. I've seen that from the BU's that it's not currently supported. I hear it's on the roadmap to be officially supported. Rodney On Mon, Aug 20, 2007 at 07:04:09AM -0500, [EMAIL PROTECTED] wrote: Have you heard such affirmation before? TE FRR is not supported over Etherchannel Under SX releases, the only feature that it says it is not supported under etherchannel is DS-TE. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] NAT - multiple inside source, single outside address
I have an issue I'm trying to fix with NAT. We have a group of SMTP servers, all with their own addresses. Due to some customer firewall issues I need all the servers to deliver outbound mail using a different address than their own. All other inbound and outbound traffic should be untouched. My first attempt looked something like this: ip nat inside source static 10.35.0.11 172.16.2.11 route-map SMTPout ! ip access-list extended cluster11-smtp-out permit tcp host 10.35.0.11 neq smtp any eq smtp permit tcp host 10.35.0.12 neq smtp any eq smtp ! ! route-map SMTPout permit 10 match ip address cluster11-smtp-out The problem is, when I try to add a second inside source static: ip nat inside source static 10.35.0.12 172.16.2.11 route-map SMTPout it's just silently ignored, and doesn't show in the config. I tried adding extendable - with the same effect. Is there a way to do this? -- matt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] NAT on one interface
Hello, I am trying to figure out if it's possible to configure NAT in IOS on just one interface. Specifically, say I need to translate traffic flows between X.X.X.X and Y.Y.Y.Y. Y.Y.Y.Y is reachable through one interface, that's my gateway to the other network. However, X.X.X.X can be reached through multiple interfaces. Normal NAT configuration requires me to specify a nat inside and a nat outside interfaces. I can certainly specify the gateway interface to Y.Y.Y.Y as nat outside, but I don't want to set a bunch of other interfaces as nat inside (nor do I want to involve them in NAT processing at all). Is there any other way? Thanks, Michael Malitsky ___ 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] NAT on one interface
nat on a stick http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094430.shtml Church, Charles wrote: Yeah, it's possible to policy route the traffic to a loopback that has nat inside configured on it, and then out the normal interface. It's kludgy, but it'll work, I think. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Malitsky Sent: Wednesday, August 22, 2007 3:12 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] NAT on one interface Hello, I am trying to figure out if it's possible to configure NAT in IOS on just one interface. Specifically, say I need to translate traffic flows between X.X.X.X and Y.Y.Y.Y. Y.Y.Y.Y is reachable through one interface, that's my gateway to the other network. However, X.X.X.X can be reached through multiple interfaces. Normal NAT configuration requires me to specify a nat inside and a nat outside interfaces. I can certainly specify the gateway interface to Y.Y.Y.Y as nat outside, but I don't want to set a bunch of other interfaces as nat inside (nor do I want to involve them in NAT processing at all). Is there any other way? Thanks, Michael Malitsky ___ 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] TE over Etherchannel
It's not supported anywhere that I know of right now so yes. I've seen some references that it may be in SRC for 76xx. On Wed, Aug 22, 2007 at 01:46:03PM -0500, Justin Shore wrote: Will this also be a problem on SR? I'm getting ready to work on this myself. Thanks Justin Rodney Dunn wrote: That's right. I've seen that from the BU's that it's not currently supported. I hear it's on the roadmap to be officially supported. Rodney On Mon, Aug 20, 2007 at 07:04:09AM -0500, [EMAIL PROTECTED] wrote: Have you heard such affirmation before? TE FRR is not supported over Etherchannel Under SX releases, the only feature that it says it is not supported under etherchannel is DS-TE. ___ 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] NAT on one interface
Bad idea because it causes process switching. Don't expect high throughput out of it. Rodney On Wed, Aug 22, 2007 at 03:40:55PM -0400, Joe Maimon wrote: nat on a stick http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094430.shtml Church, Charles wrote: Yeah, it's possible to policy route the traffic to a loopback that has nat inside configured on it, and then out the normal interface. It's kludgy, but it'll work, I think. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Malitsky Sent: Wednesday, August 22, 2007 3:12 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] NAT on one interface Hello, I am trying to figure out if it's possible to configure NAT in IOS on just one interface. Specifically, say I need to translate traffic flows between X.X.X.X and Y.Y.Y.Y. Y.Y.Y.Y is reachable through one interface, that's my gateway to the other network. However, X.X.X.X can be reached through multiple interfaces. Normal NAT configuration requires me to specify a nat inside and a nat outside interfaces. I can certainly specify the gateway interface to Y.Y.Y.Y as nat outside, but I don't want to set a bunch of other interfaces as nat inside (nor do I want to involve them in NAT processing at all). Is there any other way? Thanks, Michael Malitsky ___ 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/
[c-nsp] Output Packet drops on ethernet interface
Hi all I have a 6509 10/100/1000 TX port facing a 10/100 on a 7204-vrx. Both sides are hard coded to 100/Full and the link does not exhibit any layer 2 errors for this link yet on the 6509 side I am seeing many output drops. And causing some packet loss, if I do a 5000 packet ping I get a dropped packet every 20 or so. These are connected directly with a cat6 cable 6509 output sh int gig 9/46 GigabitEthernet9/46 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is 0015.c761.3000 (bia 0015.c761.3000) Description: Internet address is MTU 1500 bytes, BW 10 Kbit, DLY 10 usec, reliability 255/255, txload 32/255, rxload 22/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s input flow-control is off, output flow-control is off Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:02, output 00:00:03, output hang never Last clearing of show interface counters 00:07:05 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 33255 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 8719000 bits/sec, 2929 packets/sec 30 second output rate 12585000 bits/sec, 2842 packets/sec L2 Switched: ucast: 2037 pkt, 240423 bytes - mcast: 59 pkt, 7630 bytes L3 in Switched: ucast: 1080261 pkt, 404550799 bytes - mcast: 0 pkt, 0 bytes mcast L3 out Switched: ucast: 1074724 pkt, 578040580 bytes mcast: 0 pkt, 0 bytes 1101559 packets input, 411802765 bytes, 0 no buffer Received 67 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 1062119 packets output, 569997724 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 7204 router FastEthernet1/0 is up, line protocol is up Hardware is i82543 (Livengood), address is 0005.9a69.d81c (bia 0005.9a69.d81c) Description: Internet address is MTU 1500 bytes, BW 10 Kbit, DLY 100 usec, reliability 255/255, txload 21/255, rxload 31/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 00:05:55 Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 12159000 bits/sec, 2725 packets/sec 30 second output rate 8507000 bits/sec, 2804 packets/sec 922901 packets input, 488079048 bytes Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog 0 input packets with dribble condition detected 957072 packets output, 353542000 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 output buffer failures, 0 output buffers swapped out Any ideas or things to check? ___ 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] Annex-M 877
Skeeve Stevens wrote: Does anyone know if the 877 which supports Annex-M (3mb upstream on ADSL2+) is a software upgrade or a hardware specific device. It's a hardware update - the old 877's can't support Annex M. The new part number is CISCO877-M-K9 and it's the same price as the old one. I've seen 877-M mentioned, along with 1801-M and an ADSL WIC-M, but I don't know if these are special hardware releases or not. Likewise for these - updated hardware. The 1801 is CISCO1801-M/K9. Haven't come across the new HWIC yet - I don't think it's released. The updated routers are available in .au. Regards, Brad ___ 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] sh ip ro keywords
Christian wrote: On 8/22/07, Sergey [EMAIL PROTECTED] wrote: Routing entry for 164.1.12.0/24 Known via eigrp 10, distance 90, metric 18063872, type internal Redistributing via eigrp 10, ospf 10 Advertised by ospf 10 subnets known via is telling you how the route was received.. redistributing is the protocol that is redistributing the route throughout your network advertised by is who/how the route is being advertised Also bear in mind that the 'redistributing via' line is stupid - it's purely based on the routing protocol 'redistribute' statements. If a route-map or distribute-list is preventing the route being redistributed by or advertised to another protocol, 'redistributing via' will still appear for that route, but 'advertised by' won't. Regards, Brad ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco 877W BVI nat problem
Hi guys, I'm lost here, can't seem to find where I'm going wrong. atm0.1 is unnumbered to vlan1 vlan1 has public IP address and is nat outside bvi2 has internal address, is bridge for vlan2 and ssid wifi4 and is nat inside wifi clients on this router are getting their IP addresses, but can't reach the outside world. Here is my config: dot11 ssid wifi4 vlan 2 authentication open authentication key-management wpa guest-mode wpa-psk ascii 0 ! ip dhcp excluded-address 192.168.30.1 ! ip dhcp pool vlan2 network 192.168.30.0 255.255.255.0 dns-server 83.149.80.123 62.212.65.123 default-router 192.168.30.1 bridge irb interface ATM0 no ip address no atm ilmi-keepalive dsl operating-mode auto ! interface ATM0.1 point-to-point ip unnumbered Vlan1 no snmp trap link-status pvc 0/35 encapsulation aal5snap interface FastEthernet0 switchport access vlan 2 interface Dot11Radio0 no ip address ! encryption vlan 2 mode ciphers aes-ccm ! ssid wifi4 speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0 station-role root ! interface Dot11Radio0.2 encapsulation dot1Q 2 bridge-group 2 bridge-group 2 subscriber-loop-control bridge-group 2 spanning-disabled bridge-group 2 block-unknown-source no bridge-group 2 source-learning no bridge-group 2 unicast-flooding ! interface Vlan1 ip address 85.17.85.97 255.255.255.248 ip nat outside ip virtual-reassembly ! interface Vlan2 no ip address bridge-group 2 bridge-group 2 spanning-disabled ! interface BVI2 ip address 192.168.30.1 255.255.255.0 ip nat inside ip virtual-reassembly ! ip route 0.0.0.0 0.0.0.0 ATM0.1 ! ip nat inside source list 10 interface Vlan1 overload ! access-list 10 permit 192.168.30.0 0.0.0.255 ! bridge 2 route ip Any pointers in the right direction would help me greatly. Thanks in advance, Bas ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7204vxr freeze-up question
Well, I strongly recommend replacing radio unit with another device. There are some legacy gigabit intel chipset cards and they have problem while transmitting even octets to Cisco GE interfaces. The workaround was to update intel NIC drivers. If you believe that you have intel card than I guess you can't update the drivers for your radio unit and you may need to consult with vendor. Regards, Masood Ahmad Shah -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Greene Sent: Wednesday, August 22, 2007 11:44 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 7204vxr freeze-up question Here's output from a sh controller during the outage state: Interface GigabitEthernet3/0(idb 0x6363B6DC) Hardware is WISEMAN 2.1, network connection mode is auto network link is up loopback type is none startup time: 176602 usec GBIC type is 1000BaseSX idb-lc_ip_turbo_fs=0x606372F4, ip_routecache=0x11(dfs=0/mdfs=0), max_mtu=1528 fx1000_ds(tx)=0x6363CE6C(0x6363CE6C), registers(tx)=0x3D80(0x3D80), cu rr_intr=0 rx cache size=2000, rx cache end=1872, rx_nobuffer=0 FX1000 registers: CTRL =0x18180005, STATUS=0x000F FCAL =0x00C28001, FCAH =0x0100, FCT =0x8808, FCTTV =0x16E3 RCTL =0x00428032, RDBAL0=0x2000B000, RDBAH0=0x, RDLEN0=0x0800 RDH0 =0x0038, RDT0 =0x0037, RDTR0 =0x, IMS =0x02D6 TCTL =0x000400FA, TIPG =0x00A0080A, TQC =0x, TDBAL =0x2000C000 TDBAH =0x, TDLEN =0x1000, TDH =0x00BA, TDT =0x00BA TXCW =0xC1A0, RXCW =0xCC0041A0, FCRTL =0x80001200, FCRTH =0xAFF0 RDFH =0x14D7, RDFT =0x14D7, TDFH =0x03A7, TDFT =0x03A7 RX=normal, enabled TX=normal, enabled Device status=full-duplex, link up, tx clock, rx clock AN status=done(RF:0 , PAUSE:3 ), SYNC'ed, rx idle stream, rx invalid symbols, rx idle char GBIC registers: Register 0x00: 01 07 01 00 00 00 01 00 Register 0x08: 00 00 00 01 0D 00 00 00 Register 0x10: 32 16 00 00 41 47 49 4C Register 0x18: 45 4E 54 20 20 20 20 20 Register 0x20: 20 20 20 20 00 00 00 00 Register 0x28: 51 46 42 52 2D 35 36 38 Register 0x30: 39 20 20 20 20 20 20 20 Register 0x38: 30 30 30 30 00 00 00 58 Register 0x40: 00 1A 00 00 30 31 31 30 Register 0x48: 31 36 30 38 32 36 34 31 Register 0x50: 38 36 34 35 30 31 31 30 Register 0x58: 31 36 30 30 00 00 00 D8 PartNumber: QFBR-5689 PartRev: F SerialNo: 0110160826418645 Options: 0 Length(9um/50um/62.5um): 000/500/220 Date Code: 01101600 Gigabit Ethernet Codes: 1 PCI configuration registers: bus_no=6, device_no=0 DeviceID=0x1000, VendorID=0x8086, Command=0x0116, Status=0x0200 Class=0x02/0x00/0x00, Revision=0x03, LatencyTimer=0xFC, CacheLineSize=0x10 BaseAddr0=0x4904, BaseAddr1=0x, MaxLat=0x00, MinGnt=0xFF SubsysDeviceID=0x1000, SubsysVendorID=0x8086 Cap_Ptr=0x Retry/TRDY Timeout=0x PMC=0x00210001 PMCSR=0x Software MAC address filter(hash:length/addr/mask/hits): need_af_check = 0 0x00: 0 .. .. 0 0xC0: 0 0100.0ccc. .. 0 0xD0: 0 0007.8420.e854 .. 0 FX1000(type=0x98) Internal Statistics: rxring(128)=0x2000B000, shadow=0x6363D310, head=56, rx_buf_size=512 txring(256)=0x2000C000, shadow=0x6363D53C, head=186, tail=186 tx_int_txdw=0, tx_int_txqe=0, rx_int_rxdmt0=0, rx_int_rxt0=0 tx_count=0, txring_full=0, rx_max=0, filtered_pak=0 rx_overrun=0, rx_seq=0, reg_read=0, reg_write=0 rx_count=128, throttled=1, enabled=1, disabled=1 rx_no_enp=0, rx_discard=0, link_reset=0, pci_rev=3 tbl_overflow=0, chip_state=2, tx_nonint_done=0, tx_limited=0 reset=5(init=0, check=0, restart=4, pci=0), auto_restart=1 tx_carrier_loss=1, fatal_tx_err=0, tx_stucks_count=1 isl_err=0, wait_for_last_tdt=0, ctrl=1885, ctrl0=1895 rx_stucks_count=2, rdtr_fpd=3 HW addr filter: 0x6363DD68, ISL disabled, Promiscuous mode multicast Entry= 0: Addr=0007.8420.E854 Entry= 1: Addr=.. Entry= 2: Addr=.. Entry= 3: Addr=.. Entry= 4: Addr=.. Entry= 5: Addr=.. Entry= 6: Addr=.. Entry= 7: Addr=.. Entry= 8: Addr=.. Entry= 9: Addr=.. Entry=10: Addr=.. Entry=11: Addr=.. Entry=12: Addr=.. Entry=13: Addr=.. Entry=14: Addr=.. Entry=15: Addr=.. FX1000 Statistics (PA3) CRC error0 Symbol error 0 Missed Packets 0 Single Collision 0 Excessive Coll 0 Multiple Coll0 Late Coll0 Collision0 Defer497 Receive Length 0 Sequence Error 0 XON RX 0
Re: [c-nsp] UDLD vs Auto-neg
From the documentation: At Layer 1, autonegotiation takes care of physical signaling and fault detection. UDLD performs tasks that autonegotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected interfaces. When you enable both autonegotiation and UDLD, the Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols. See the 'Configuring UDLD' section of any recent software config guide for more info. --afsheenb Tim Durack wrote: A question that's been bugging me for a while: what does UDLD give me that running auto-neg on both sides of a link doesn't? If I run auto, link drops if the pathway goes one-way, and won't renegotiate until the pathway is re-established. Isn't that all UDLD does? Perhaps there are some failure modes I'm not considering. Or maybe it has more to do with not running auto on infrastructure links. Comments would be appreciated! Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] sh ip ro keywords
good point brad! On 8/22/07, Brad Henshaw [EMAIL PROTECTED] wrote: Christian wrote: On 8/22/07, Sergey [EMAIL PROTECTED] wrote: Routing entry for 164.1.12.0/24 Known via eigrp 10, distance 90, metric 18063872, type internal Redistributing via eigrp 10, ospf 10 Advertised by ospf 10 subnets known via is telling you how the route was received.. redistributing is the protocol that is redistributing the route throughout your network advertised by is who/how the route is being advertised Also bear in mind that the 'redistributing via' line is stupid - it's purely based on the routing protocol 'redistribute' statements. If a route-map or distribute-list is preventing the route being redistributed by or advertised to another protocol, 'redistributing via' will still appear for that route, but 'advertised by' won't. Regards, Brad ___ 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] E1 controller - clock problems with 'line' fine with 'internal'
Circuits from the SAME carrier can generally share a clock because the carrier will generally have a single clock source for all their circuits. If you have 3 E1 from the same carrier, on one of the E1's you would configure clock source primary and the rest could be clock source internal, because the internal clock would be synced to the primary line. You can also configure each interface as clock source line which is the default. All E1's need a clock source, either your end or their end, and if this is a carrier circuit, than they provide the clock and you need either clock source line or clock source primary on one E1, and clock source internal on the others. Regards, Masood Ahmad Shah Nexlinx BLOG: http://www.weblogs.com.pk/jahil/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ras Sent: Wednesday, August 22, 2007 5:14 PM To: c-nsp Subject: [c-nsp] E1 controller - clock problems with 'line' fine with 'internal' I've recently run into a slightly strange problem with one of my E1 circuits. We operate a hub-and-spoke setup, where a number of lines terminate into a single aggregation router on our side, and into a bunch of different locations/CPEs on the remote end. For all these lines, we have always had 'clock source line' for the E1 controller on both the aggregation router and the CPE routers. This has worked fine and the controllers show no errors. I've just commissioned a new line into the same aggregation router, exactly the same equipment on the CPE side (2811, VWIC2-1MFT-G703), exactly the same equipment on PE side (2811, VWIC2-2MFT-G703). But this time, we were seeing continuous 'Slip Secs' (top marks to whoever made that term up incidentally), which were also showing up as 'Errored Secs' (but crucially, never 'Errored Secs'). After much investigation and a VWIC/chassis swap later, we were in exactly the same position. I think tried configuring the aggregation controller (just for that one port) with 'clock source internal' and bang all the errors disappeared completely. It's now been running well over 48h without a single errored second, versus 1 second per second before. For reference, the aggregation router now has: controller E1 0/0/1 framing NO-CRC4 clock source internal channel-group 0 timeslots 1-31 and the CPE has: controller E1 0/1/0 framing NO-CRC4 channel-group 0 timeslots 1-31 Has anyone seen anything like this before and/or know what might cause this? My telco insists that they've tested the circuit end to end and it's working as expected (and to be fair, it is now..) Thanks, Ras ___ 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] NAT - multiple inside source, single outside address
We have a group of SMTP servers, all with their own addresses. Due to some customer firewall issues I need all the servers to deliver outbound mail using a different address than their own. All other inbound and outbound traffic should be untouched. You might try using an external NAT address pool - each outbound connection attempt should cause a different IP address in the pool to be used. If you want servers to switch addresses you can play with the pool address allocation times I think. Sorry - don't have an example to hand... B. ___ 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] Force initiate DSL connect
Can anyone please tell me how to initiate a DSL connection (forcing to authenticate) on an 877, and is it any different on an 837, etc. It seems to wait some sort of random period before retries. Its just a normal dialer session. Fiddle with the dialer config to set the dial conditions and retry. And add something that will force a dial like NTP... If you're doing things manually, try clear int dialerx. B. ___ 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] Annex-M 877
Thanx. Any possible upgrade to -M for 877... doubt it, but worth asking. ...Skeeve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Looney Sent: Thursday, 23 August 2007 9:53 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Annex-M 877 Does anyone know if the 877 which supports Annex-M (3mb upstream on ADSL2+) is a software upgrade or a hardware specific device. Definitely hardware specific - cannot be done with a software upgrade. Part numbers for Oz: CISCO877-M-K9 CISCO877W-G-E-M-K9 CISCO1801-M/K9 I know there is supposed to be a HWIC but it hasn't shown up as being orderable in Australia yet. B. ___ 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] UDLD vs Auto-neg
Okay, now it makes sense: A unidirectional link occurs whenever traffic transmitted by the local device over a link is received by the neighbor but traffic transmitted from the neighbor is not received by the local device. If one of the fiber strands in a pair is disconnected, as long as autonegotiation is active, the link does not stay up. In this case, the logical link is undetermined, and UDLD does not take any action. If both fibers are working normally at Layer 1, then UDLD at Layer 2 determines whether those fibers are connected correctly and whether traffic is flowing bidirectionally between the correct neighbors. This check cannot be performed by autonegotiation, because autonegotiation operates at Layer 1. On 8/22/07, Afsheen Bigdeli [EMAIL PROTECTED] wrote: From the documentation: At Layer 1, autonegotiation takes care of physical signaling and fault detection. UDLD performs tasks that autonegotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected interfaces. When you enable both autonegotiation and UDLD, the Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols. See the 'Configuring UDLD' section of any recent software config guide for more info. --afsheenb Tim Durack wrote: A question that's been bugging me for a while: what does UDLD give me that running auto-neg on both sides of a link doesn't? If I run auto, link drops if the pathway goes one-way, and won't renegotiate until the pathway is re-established. Isn't that all UDLD does? Perhaps there are some failure modes I'm not considering. Or maybe it has more to do with not running auto on infrastructure links. Comments would be appreciated! Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Annex-M 877
Yes, replace it with a -M model. Its the only way. Cheers, Tom Thanx. Any possible upgrade to -M for 877... doubt it, but worth asking. ..Skeeve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Looney Sent: Thursday, 23 August 2007 9:53 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Annex-M 877 Does anyone know if the 877 which supports Annex-M (3mb upstream on ADSL2+) is a software upgrade or a hardware specific device. Definitely hardware specific - cannot be done with a software upgrade. Part numbers for Oz: CISCO877-M-K9 CISCO877W-G-E-M-K9 CISCO1801-M/K9 I know there is supposed to be a HWIC but it hasn't shown up as being orderable in Australia yet. B. ___ 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/
