Re: [c-nsp] full duplex mismatch speed - dynamips

'no cdp log mismatch duplex' could be a better way to get rid of annoying message but still have cdp running. That is if you're sure it's a bug not inadequate configuration. On Wed, Aug 18, 2010 at 4:42 AM, Jeferson Guardia jefers...@gmail.com wrote:  Guys, Thanks for all replies, googling it

Re: [c-nsp] PA-FE-TX Duplex

Hi, On Tue, Aug 17, 2010 at 11:28:48PM -0400, Sridhar Ayengar wrote: Is there any way to get a PA-FE-TX to autonegotiate duplex? No. The PA-FE-TX and the 7200-IO-FE just don't do duplex negotiation. This is about the only bit of hardware that still needs forcing of full-duplex on both sides.

Re: [c-nsp] full duplex mismatch speed - dynamips

Hi, On Tue, Aug 17, 2010 at 11:03:44PM -0300, Jeferson Guardia wrote: Anyone knows how to solve this on dynamips? (router with lan switch connection) - I thought that setting speed auto would solve it. If that's a 7200, just nail it to duplex full. gert -- USENET is *not* the non-clickable

Re: [c-nsp] full duplex mismatch speed - dynamips

Jeferson, why no one read the 'dynamis' word on the subject? this is a particular issue being experienced on a 3725 being used as a switch on DYNAMIPS... it just doesnt work... Since Dynamips is an emulator (and from the looks of it, quite an old one) it could also be a bug in the emulator

Re: [c-nsp] full duplex mismatch speed - dynamips

If it's any help at all, I downloaded GNS3 about 3 weeks ago and with relatively recent IOS, its working fine and I can force to 100/full. Andreas is right.. So is it possible for you to upgrade to latest dynamips? On 18 August 2010 09:44, Andreas Sikkema asikk...@office.unet.nl wrote:

Re: [c-nsp] full duplex mismatch speed - dynamips

Hi, On Wed, Aug 18, 2010 at 10:44:37AM +0200, Andreas Sikkema wrote: Since Dynamips is an emulator (and from the looks of it, quite an old one) it could also be a bug in the emulator itself. Or even a bug in the IOS version you're using, or a combination of both. The bug in dynamips would

Re: [c-nsp] full duplex mismatch speed - dynamips

Whatever config I make, it does not work. Some people here got the point, some are still thinking I am missing stuff somewhere.. anyway, I not using GNS3 but Dynagen. I am loading up 14 devices and on gns3 this usually crashes, the only stable way I found on loading, it was using dynagen, but

Re: [c-nsp] ASA 8.3

Could and of these be the issue? All are fixed in the 8.3.2 release now on CCO... CSCso65967 SIP builds many secondary conns with register msg but no registrar CSCtb23281 ASA: SIP inspect not opening pinhole for contact header of SIP 183 msg CSCte47509 Inspect SIP: Segmented SIP message

[c-nsp] Setting P-bit for T7 LSA in NSSA

Folks, everyone knows it's possible to set the P bit of T7 LSA to 0 at the ASBR using the not-advertise keyword of the summary-address command, such as router ospf 1 summary-address 141.108.10.0 255.255.255.0 not-advertise but is there anything similarly possible with the redistribute

Re: [c-nsp] Network Change Management

Thanks all! -Jeff -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mark Meijerink Sent: Tuesday, August 17, 2010 11:13 AM Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Network Change Management We have written an

[c-nsp] mac-address-table aging-time cannot go 480

I'm using SXI4a 6500#conf t Enter configuration commands, one per line. End with CNTL/Z. 6500(config)#mac-address-table aging-time 300 6500(config)#^Z 6500#sh mac address-table aging-time VlanAging Time -- Global 480 no vlan age other than global age configured 6500#conf t

Re: [c-nsp] PA-FE-TX Duplex

On Wed, Aug 18, 2010 at 1:28 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Tue, Aug 17, 2010 at 11:28:48PM -0400, Sridhar Ayengar wrote: Is there any way to get a PA-FE-TX to autonegotiate duplex? No.  The PA-FE-TX and the 7200-IO-FE just don't do duplex negotiation. This is about the

Re: [c-nsp] mac-address-table aging-time cannot go 480

ok, i believe i found out that it's due to the mac-sync feature of the 6708 module which uses an interval of 160. 6500#sh mac address-table synchronize statistics MAC Entry Out-of-band Synchronization Feature Statistics: - Module [4]

Re: [c-nsp] PA-FE-TX Duplex

Gert Doering wrote: Hi, On Tue, Aug 17, 2010 at 11:28:48PM -0400, Sridhar Ayengar wrote: Is there any way to get a PA-FE-TX to autonegotiate duplex? No. The PA-FE-TX and the 7200-IO-FE just don't do duplex negotiation. This is about the only bit of hardware that still needs forcing of

Re: [c-nsp] PA-FE-TX Duplex

Hi, On Wed, Aug 18, 2010 at 10:50:48AM -0400, Joe Maimon wrote: Some I/O controllers do auto-neg. Some dont. NAME: module 0, DESCR: I/O FastEthernet (TX-ISL) PID: C7200-IO-FE-MII/RJ45=, VID:, SN: 15698175 Single port... NAME: module 0, DESCR: I/O Dual FastEthernet Controller PID:

Re: [c-nsp] mac-address-table aging-time cannot go 480

http://www.cisco.com/en/US/products/ps9336/products_tech_note09186a0080a7c837.shtml#misc See the Configure the MAC aging timer to three times the MAC synchronization timer value. at the Miscellaneous section at the end.

[c-nsp] incoming queue

hi, i read on cisco's site that the default cos mapping for this receive queue is cos 5 mapped to priority queue 2, but when i do a show queuing im not seeing that mapping on the receive queue. when I try to map cos 5 to receive queue 2, I only have an option for queue id 1. On the outgoing queue

Re: [c-nsp] PA-FE-TX Duplex

Gert Doering wrote: NAME: module 0, DESCR: I/O Dual FastEthernet Controller PID: C7200-I/O-2FE/E , VID:, SN: 33390818 ... and dual port. Different chip, different driver, different (less) bugs. The 2FE/E is more similar to the PA-2FE-TX. So can I conclude from your statement that the

Re: [c-nsp] incoming queue

I'm not sure I can answer, but you could probably help youself by supplying a bit more information. A shot in the dark: Did you enable mls qos trust cos on the port? (Beware that this propagates to every port on the same ASIC.) But on what device (incl. relevant modules) and what IOS version are

[c-nsp] C6K, 12.2(33)SXI3, vrf-aware SNMP

C6K, 12.2(33)SXI3: Is there anyway to isolate snmp to a specific vrf or set of vrfs? Seems like a simple concept, but I'm having a hard time with it. -- Tim: ___ cisco-nsp mailing list cisco-nsp@puck.nether.net

Re: [c-nsp] PA-FE-TX Duplex

Hi, On Wed, Aug 18, 2010 at 01:13:50PM -0400, Sridhar Ayengar wrote: Gert Doering wrote: The 2FE/E is more similar to the PA-2FE-TX. So can I conclude from your statement that the PA-2FE-TX *does* support autonegotiation? Yes. gert -- USENET is *not* the non-clickable part of WWW!

Re: [c-nsp] incoming queue

Peter, see below for more info. But I have mls qos trust dscp on most interfaces, mls qos trust cos will only work on trunks and I'm using routed/access ports. I did issue mls qos trust cos on one of the access ports but that didn’t cause cos 5 to be mapped to pri queue 2 for incoming. On

[c-nsp] Retrieving *'d secrets in PIX6.3(5)

In current PIX/ASA OS 7+, one is able to look at things like *'d out ipsec/isakmp secrets using 'more system:running-configuration' which makes it easy to move the config over to a new box or something. Is there a way to do the same thing with PIX6? 6.3(5) more specifically? I'm looking to

Re: [c-nsp] incoming queue

I think I may of found the issue, looks like incoming queue based on DSCP trust will only work for some lan cards Congestion avoidance—If you configure an Ethernet LAN port to trust CoS or DSCP, QoS classifies the traffic on the basis of its Layer 2 CoS value or its Layer 3 DSCP value and

Re: [c-nsp] incoming queue

On Wed, 2010-08-18 at 15:01 -0400, P.A wrote: Peter, see below for more info. But I have mls qos trust dscp on most interfaces, mls qos trust cos will only work on trunks and I'm using routed/access ports. I can apply mls qos trust cos fine to both access and routed ports. I do see though that

Re: [c-nsp] incoming queue

On Wed, 2010-08-18 at 22:15 +0200, Peter Rathlev wrote: 1) apply mls qos trust cos to all ports on the ASIC. (show interface GiX/Y | incl Ports on ASIC), I missed a capabilities there. The command is of course show interface GiX/Y capabilities | incl Ports on ASIC (Proof reading after

Re: [c-nsp] Retrieving *'d secrets in PIX6.3(5)

Jason -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Jason Lixfeld Sent: Wednesday, August 18, 2010 4:04 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Retrieving *'d secrets in PIX6.3(5) In current PIX/ASA

Re: [c-nsp] Retrieving *'d secrets in PIX6.3(5)

Hello Jason: If you save your configuration to a tftp server it will show the password in the clear. There may be another way but I've not found it. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206)

Re: [c-nsp] Retrieving *'d secrets in PIX6.3(5)

On Wed, 2010-08-18 at 16:03 -0400, Jason Lixfeld wrote: In current PIX/ASA OS 7+, one is able to look at things like *'d out ipsec/isakmp secrets using 'more system:running-configuration' which makes it easy to move the config over to a new box or something. Is there a way to do the same

Re: [c-nsp] Retrieving *'d secrets in PIX6.3(5)

If you can tftp the config, it will show the passwords in clear text. Not sure if there's any other way to do it in 6.3.5 Clue On Wed, Aug 18, 2010 at 3:03 PM, Jason Lixfeld ja...@lixfeld.ca wrote: In current PIX/ASA OS 7+, one is able to look at things like *'d out ipsec/isakmp secrets using

Re: [c-nsp] incoming queue

On Wed, 2010-08-18 at 16:25 -0400, P.A wrote: Peter, I think I may of found the issue, looks like incoming queue based on DSCP trust will only work for some lan cards Congestion avoidance—If you configure an Ethernet LAN port to trust CoS or DSCP, QoS classifies the traffic on the basis of

Re: [c-nsp] full duplex mismatch speed - dynamips

sth...@nethelp.no writes: I would have agreed five to ten years ago. However, nowadays we use autoneg everywhere with a few well known exceptions (e.g. Cisco 7200 with Fast Ethernet PAs). Autoneg simply gives us less problems. Autoneg also has the advantage of almost always failing in an

[c-nsp] Oversubscription on 6509 blade

We're seeing overruns on a 6148 module in a 6509-E switch. The overruns would be considered normal if the ASIC port range was oversubscribed, however, according to interface traffic levels, it doesn't reach the 1Gb peak. Output from the 'show int summ' command below shows that Rxbs = ~70Mbps while

Re: [c-nsp] Oversubscription on 6509 blade

Overruns have nothing to do with oversubscription. They are packets dropped due to the input ring being full. Basically the other end is filling the queue faster than the 6509 can empty them. What's on the other end? Flow control may help here if it's supported. On Wed, Aug 18, 2010 at 7:28

Re: [c-nsp] full duplex mismatch speed - dynamips

On Wednesday, August 18, 2010 01:30:07 pm sth...@nethelp.no wrote: I would have agreed five to ten years ago. However, nowadays we use autoneg everywhere with a few well known exceptions (e.g. Cisco 7200 with Fast Ethernet PAs). Autoneg simply gives us less problems. +1. Mark.