Re: [c-nsp] Sup2T and sampled netflow with inbound ACL on SVI
Believe it or not, this is [currently] expected behavior: https://tools.cisco.com/bugsearch/bug/CSCui78690 I haven't seen any movement on fixing [enhancing] this behavior, and it makes deploying FNF somewhat dangerous. Routed subinterfaces or using the workaround make work. I haven't tested them. Tnx Chris On 02/05/2015 07:21 AM, Jiri Prochazka wrote: Hi, I'd like to use sampled netflow and inbound L3 ACL together on SVI on Cat7600/Sup2T platform and I am having no luck getting this super-basic thing done. As soon as those two functions are being enabled, inbound traffic gets switched in software. As soon as I do not use either sampled netflow or inbound acl, everything works as expected. But combination of those two results in software switched in software. Config -> interface Vlan998 description SVI-of-Vlan998 ip address 192.168.1.1 255.255.255.252 ip access-group acl_deny_in in no ip redirects no ip unreachables no ip proxy-arp ip flow monitor MONITOR-NETWORK-IN sampler SAMPLER input %FMCORE-4-RACL_REDUCED: Interface Vlan998 routed traffic will be software switched in ingress direction. L2 features may not be applied at the interface When I remove either 'ip access-group acl_deny_in in' or 'ip flow monitor MONITOR-NETWORK-IN sampler SAMPLER input' I get notofication about traffic being switched in hardware. When I use unsampled netflow, it works too. %FMCORE-6-RACL_ENABLED: Interface Vlan998 routed traffic is hardware switched in ingress direction The very same setup on L3 interface itself is working absolutely OK. What am I missing? Thanks! Jiri ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Chris Griffin cgrif...@ufl.edu Network Architect Phone: (352) 273-1051 UFIT - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] Packet Lost on interface Loopback
Yes, and be careful of CSCsq77464 if you have saved your config since the exception... Tnx Chris On 5/3/2014 8:41 AM, Gert Doering wrote: Hi, On Sat, May 03, 2014 at 02:23:13PM +0700, vannara vuth wrote: I'm also facing the similar issue. What was symtom on your router when receiving the log message? Packet loss to v4 address on loop back as well? If you run into MLS CEF exception mode, some of your v4 traffic will be software switched, *and* subject to MLS rate limiters - so you'll see heavy packet loss on transit traffic to *some* destinations. Unfortunately the only way to clear the exception is to reboot. 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/ -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] ASR9K limitations
Fix is specifically in : Reload SMU, SMU Pack1 for ASR9k NP, PRM and DRV fixes, Mandatory SMU asr9k-p-4.2.1.CSCua76130.tar But yes, that tarball should have it as well. Tnx Chris On 08/17/2012 04:48 AM, tim wrote: On 05.07.2012 12:45 AM, Chris Griffin wrote: There was actually a bug that caused this for many authentic Cisco CWDM SFPs. SMU coming for 4.2.1 sometime mid this month. May help your issue. Don't known which SMU it is, but with the "4.2.1-Updated Tarball for ASR9K Recommended SMU's" of 05-AUG-2012 (4.2.1_asr9k-p_REC_SMUS_2012-07-19.tar) the probleme is gone. Cheers, 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/ -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] ASR9K limitations
There was actually a bug that caused this for many authentic Cisco CWDM SFPs. SMU coming for 4.2.1 sometime mid this month. May help your issue. Tnx Chris On 7/4/2012 5:24 AM, tim wrote: On 28.06.2012 12:29 AM, chip wrote: GLC-T SFP's aren't supported, SFP-GE-T's are, this seemed to change from 4.2.0 to 4.2.1, not the support, but the enforcement of it. Between 4.1.1 and 4.2.1 the support for some of our third party (CWDM) SFPs got lost, that means: show controller """ State: Administrative state: disabled Operational state: Down (Reason: Security failure (not a valid part)) LED state: Off Phy: Media type: Initializing, true state or type not yet known Optics: Vendor: Part number: CWDM-SFP-1550 Serial number: xx """ With 4.1.1 it showed "OEM" in the Vendor field. "transceiver permit pid all" and "service unsupported-transceiver" aren't helping. As one can see "show inventoy" and "Part number" are still working... So, test your third party SFPs before upgrading. If anybody has a fix (which does not involve new hardware ;)) please let me know. -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/ -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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
I have heard next gen ISR for XE as well... On Thu, 2011-07-21 at 11:05 +0400, Nikolay Shopik wrote: > On 21/07/11 03:56, Tony Varriale wrote: > >> > > No one cares as much as it is a software platform :) > > I'd say this give almost no benefits for such platform also. And if they > decide to give us XE, this is probably cost money on ISR-G2. Most likely > XE not happen until ISR-G3 and this is what I call Eventually(TM) > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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?
We did see very long lead times on a 4900M order made last October (took 4 months), but a recent order is showing 4 weeks. We will see if it starts getting bumped as the time to ship grows near :-) Tnx Chris On Apr 8, 2010, at 10:39 AM, Jeff Bacon wrote: > 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/ -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] Sup720 CoPP, limits on CPU performance
Are you sure this is actually fixed? When entering the command: mls rate-limit unicast cef glean 5000 250 I get: 12.2(18)SXF14 and 12.2(33)SXI3: The following is sent the console only, but not logged: %Packets requiring ARP resolution will be subject to the output ACLs of the input VLAN 12.2(33)SRD3: The following is logged: *Mar 27 07:08:50 EDT: %MLS_RATE-4-ENABLING_FIB_GLEAN_RECEIVE: Packets requiring ARP resolution will be subject to the output ACLs of the input VLAN Seems to be an expected message: http://www.cisco.com/cgi-bin/Support/Errordecoder/index.cgi?action=search&index=all&locale=en&query=MLS_RATE-4-ENABLING_FIB_GLEAN_RECEIVE&counter=0&paging=5&links=reference&sa=Submit Previous messages from Sukumar in the Feb 2007 timeframe seemed to imply this was an issue with the PFC3B and could be fixed with the PFC3C. Thanks Chris On Mar 25, 2010, at 4:20 PM, Rodney Dunn wrote: > > > On 3/25/10 1:42 PM, Tim Durack wrote: >> On Thu, Mar 25, 2010 at 12:22 PM, Rodney Dunn wrote: >>> Yep...that's it: >>> >>> Release-note >>> >>> >>> When a packet is destined to an next hop that doesn't already >>> have an ARP entry, the packet needs to be punted from the hardware >>> datapath up to the CPU. When the glean adjacency rate-limiter is >>> enabled, the egress security ACL (and egress QoS) of the ingress >>> interface is applied on these punted packets. >>> >>> The current workaround is to either relax the egress security ACLs >>> of ports facing PCs/servers (ports facing only routers are not a >>> problem since routing protocols guarantee that ARP entries always >>> exist for routers), or disable the glean adjacency rate-limiter. >> >> But it's fixed, right? > > Yes. I didn't realize how long it had been so my memory isn't totally gone > yet. ;) > > Rodney > > >> >> CSCed75920 says: >> >> Fixed-In >> 12.2(17d)SXB1 >> 12.2(18)SXD >> >> (I really want to police all ip at the end of my CoPP policy, and the >> mls glean rate-limiter appears to allow me to do that.) >> > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] Sup720 CoPP, limits on CPU performance
Because on the PFC3B, mls HWRL glean traffic is subject to the outbound ACL of the input interface. If it didn't have this "feature" we would use the glean rate limiter. Its far easier for us to track interface IPs than it is to re-write all of our outbound ACLs to account for inbound glean traffic. Tnx Chris On 3/23/2010 9:17 AM, Saku Ytti wrote: On (2010-03-23 08:56 -0400), Chris Griffin wrote: The testing I did was about a year ago, but as I recall, with our default deny any policy, traffic to hosts with no current ARP adjacency would fail. As soon as the glean rate limiter was enabled, traffic started to flow normally. Further tested demonstrated the limitation with ACL behavior and due our heavy use of outbound ACLs, we elected to track each interface IP in an object group and apply heavy deny policies to those bits while allowing glean and other unclassified traffic to hit a rate limited permit policy. If the glean rate-limiter bypasses software CoPP, as it seems to do, why would you opt not to use it? Do you want to give priority to some glean traffic to avoid possible DoS scenario where legit hosts can't be gleaned due to attack. -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] Sup720 CoPP, limits on CPU performance
Yes, much confusion, even in the same document: http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/dos.html "CoPP does not support ARP policies. ARP policing mechanisms provide protection against ARP storms. " But further on in the same document: "Layer 2 Protocols—Traffic used for address resolution protocol (ARP). Excessive ARP packets can potentially monopolize MSFC resources, starving other important processes; CoPP can be used to rate limit ARP packets to prevent this situation. Currently, ARP is the only Layer 2 protocol that can be specifically classified using the match protocol classification criteria." The testing I did was about a year ago, but as I recall, with our default deny any policy, traffic to hosts with no current ARP adjacency would fail. As soon as the glean rate limiter was enabled, traffic started to flow normally. Further tested demonstrated the limitation with ACL behavior and due our heavy use of outbound ACLs, we elected to track each interface IP in an object group and apply heavy deny policies to those bits while allowing glean and other unclassified traffic to hit a rate limited permit policy. Tnx Chris On 3/23/2010 8:24 AM, Tim Durack wrote: On Tue, Mar 23, 2010 at 7:29 AM, Chris Griffin wrote: Anything matching a fixed mls rate limit will bypass copp, which can be a useful technique to avoid having to account for glean traffic in your copp policies. Be cautious however, you may get this error message (only on the console!) when enabling: %Packets requiring ARP resolution will be subject to the output ACLs of the input VLAN This basically results in all the glean traffic being subject to non-obvious ACL behavior. This is apparently a limitation in some versions of the PFC 3B, but has been fixed in the 3C. Funny thing is that in our experiments not all of our PFC3Bs do it, but based on the fact that we could be required to replace one with a version that does have this limitation, we elected to avoid using it. Interesting. The docs are somewhat confusing on the interaction between mls rate-limiters and CoPP. http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/copp.html •PFC3 supports built-in special-case rate limiters, which are useful for situations where an ACL cannot be used (for example, TTL, MTU, and IP options). When you enable the special-case rate limiters, you should be aware that the special-case rate limiters will override the CoPP policy for packets matching the rate-limiter criteria. http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dos.html •Rate limiters override the CoPP traffic. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_553261.html • When combining CoPP and HWRL, HWRL always takes precedence over CoPP; for example, if HWRL is applied in hardware, CoPP for the same traffic can only be applied in software. The exception is for HWRL that is applied after packet rewrite in hardware (for example, only TTL=1 and MTU failure so far) since control packets are excluded from this HWRL logic. In general, control plane packets hitting the bridge adjacency are not affected by TTL and MTU rate limiting. http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html "Figure 6. Relationship between Control Plane Policing and Special-Case Rate-limiters for 6500/7600 Platforms" indicates that traffic passing through mls rate-limiters proceeds to hit software CoPP. So if I make a default deny for traffic not matching approved classes, I would again affect glean traffic. -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] Sup720 CoPP, limits on CPU performance
Anything matching a fixed mls rate limit will bypass copp, which can be a useful technique to avoid having to account for glean traffic in your copp policies. Be cautious however, you may get this error message (only on the console!) when enabling: %Packets requiring ARP resolution will be subject to the output ACLs of the input VLAN This basically results in all the glean traffic being subject to non-obvious ACL behavior. This is apparently a limitation in some versions of the PFC 3B, but has been fixed in the 3C. Funny thing is that in our experiments not all of our PFC3Bs do it, but based on the fact that we could be required to replace one with a version that does have this limitation, we elected to avoid using it. Tnx Chris On 3/23/2010 4:09 AM, Saku Ytti wrote: On (2010-03-22 22:23 -0400), Tim Durack wrote: Not being able to differntiate receive from glean traffic is a huge problem. This makes it difficult/impossible to permit approved control plane traffic, then deny everything else. If you do, glean traffic won't hit the control plane, causing arp failures. Not fun. I thought of Phil's email last night at bed, and concluded he must be right and I must be wrong, it made whole lot of sense and I was confused why I have not gotten into trouble because of it. Now I tried to reproduce the problem by taking ssh to IP address in my LAN where I don't have server. I see the 7600 sending arp who has to me, while CoPP does not allow the packet. RBUS result: CCC [3] = b101 [L2_POLICE] DEST_INDEX [19] = 0x7F05 VLAN [12] = 4055 RBH [3] = b111 (4055 is vrf_0_vlan) If I try SSH to the router I get (CoPP drop): CCC [3] = b101 [L2_POLICE] DEST_INDEX [19] = 0x7FFF VLAN [12] = 4055 RBH [3] = b010 I remember by heart that 0x7FFF LTL is drop adjacency for various things (you can rewrite it to physical port, if you want to get CoPP drops out in analyser) 0x7F05 appears to be: 0x0465:RED_RATE_IDX_4 = 0x7F05 [32517 ] Which is again different from CoPP permit LTL. So glean appears in my 7600's to get its own adjacency, which as far as I can see in my case does not get evaluated by software CoPP. Not sure if this is side effect of one of these, or what. But could someone try to reproduce my results, since what you and Phil are saying makes perfect sense but I'm just not seeing the drops. mls qos protocol ARP police 200 62000 mls rate-limit unicast cef glean 200 50 According to N7K docs, this is all fixed in EARL8... -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] QOS mismatch for channel ports ??
try "no mls qos channel-consistency" under the port channel... On Fri, 2009-09-25 at 10:33 -0400, Jeff Fitzwater wrote: > I have the following two ports on different modules and they have > different QOS scheduling which stops them from being members of a > channel group. > > Is there a way to fix this by changing the QOS on one of the > ports ? I wanted to keep the ports on separate boards if possible. > > > > TenGigabitEthernet12/6 > Model: WS-X6708-10GE > Type: 10Gbase-LR > Speed: 1 > Duplex:full > Trunk encap. type: 802.1Q,ISL > Trunk mode:on,off,desirable,nonegotiate > Channel: yes > Broadcast suppression: percentage(0-100) > Flowcontrol: rx-(off,on),tx-(off,on) > Membership:static > Fast Start:yes > QOS scheduling:rx-(8q4t), tx-(1p7q4t) > QOS queueing mode: rx-(cos,dscp), tx-(cos,dscp) > CoS rewrite: yes > ToS rewrite: yes > Inline power: no > Inline power policing: no > SPAN: source/destination > UDLD yes > Link Debounce: yes > Link Debounce Time:yes > Ports-in-ASIC (Sub-port ASIC) : 2-3,6,8 (6) > Remote switch uplink: no > Dot1x: yes > Port-Security: yes > - > > TenGigabitEthernet7/4 > Model: VS-S720-10G > Type: 10Gbase-LR > Speed: 1 > Duplex:full > Trunk encap. type: 802.1Q,ISL > Trunk mode:on,off,desirable,nonegotiate > Channel: yes > Broadcast suppression: percentage(0-100) > Flowcontrol: rx-(off,on),tx-(off,on) > Membership:static > Fast Start:yes > QOS scheduling:rx-(2q4t), tx-(1p3q4t) > QOS queueing mode: rx-(cos), tx-(cos) > CoS rewrite: yes > ToS rewrite: yes > Inline power: no > Inline power policing: no > SPAN: source/destination > UDLD yes > Link Debounce: yes > Link Debounce Time:yes > Ports-in-ASIC (Sub-port ASIC) : 1-5 (3-4) > Remote switch uplink: no > Dot1x: yes > Port-Security: yes > - > > Thanks in advance... > > > Jeff Fitzwater > OIT Network Systems > Princeton University > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] ASA5520 which image should I use?
I have been told that going forward TAC is the only way to get interim releases on 8.2 and newer code. This wouldn't be bad if they put out real releases more than once per year. Crazy that it seems to be SOP that Cisco, through making it difficult to get patches, encourages running code on a security device with known security flaws. Tnx Chris On Fri, 2009-09-25 at 09:45 -0400, Ryan West wrote: > Nick, > > I agree with you on the earlier 7.2(4) releases, in particular 7.2(4)18 was > bombing on us in multiple locations with site to site tunnels. However, I > think the same interim released bugs were in both trains. In terms of bug > fixes and general release times, 8.0(4)32 and 7.2(4)33 were released two days > apart and have held up to any of the recent of PSIRT fixes. I won't run > 8.0(4)16 anywhere, just as I won't run 7.2(4)18. > > I used the bugID Justin mentioned a while back to get 8.2.1(3) and it has > proved to be stable for AnyConnect Essential customers. I'm not sure why > Cisco isn't releasing anything in the way of interim updates, the last was > the 18th of May, I would rather not contact TAC for anything outside of the > main train. > > -ryan > > -Original Message- > From: cisco-nsp-boun...@puck.nether.net > [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of nm...@guesswho.com > Sent: Friday, September 25, 2009 9:30 AM > To: amsoa...@netcabo.pt > Cc: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] ASA5520 which image should I use? > > Obviously everybody's experience has been different but I have been running > very nicely on 8.0.x code. I am running on the latest interim code on both > ASAs and PIXs due to a security flaw though.(knock on wood) It has been > very stable. 7.2.4 code was very buggy for me. I was upgrading probably > every other month due to bugs until we jumped to 8.x code a while ago. > > Justin, > I believe I saw your posts on the RANCID list and although the 8.2 coredump > problem can be a pain you can modify your rancid script to ignore the > coredump file when rancid does a show flash. I do this for dhcp snooping > since the db is small enough that I can keep it in flash. (Yes I know about > the warning that they give when you configure like this) Every time a lease > expires or a new lease is distributed the file is updated which would make > rancid grab the change. > > Nick > > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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 VPN Client Causes Mac OS X Crash - Update!
Starting with 8.2(1), Cisco now offers an Anyconnect only license called "Anyconnect essentials" which allows you to use the Anyconnect client in a very similar mode to the IPsec client. Doesn't offer traditional web based SSL services or posture assessment, but does allow you to support 64bit OS'es. Cost is around $500 list for the 5550 and less for smaller platforms as I recall... MUCH cheaper than the old Anyconnect SSL license. Only problem is you must run 8.2, and its not quite there for us yet, but we will be testing an interim release soon. Tnx Chris On Mon, 2009-09-14 at 15:36 +0200, Gert Doering wrote: > Hi, > > On Mon, Sep 14, 2009 at 06:22:04AM -0700, Kaj Niemi wrote: > > The Cisco VPN Client (CVC) doesn't support IPv6 but AnyConnect SSL VPN > > Client (AVC) does. It works well, too, even on OS X 10.6 - AVC is 2.3.0254 > > and the ASAs are running 8.0(x) and 8.2(x). > > ... if you have the appropriate license. > > 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/ -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] SRC on 7200
Also watch out for CSCsy58115. BGP memory leak if you have any idle/active peers. We are still going through the full scope of this bug and how to get around it. Thanks Chris Mark Tinka wrote: On Tuesday 14 April 2009 11:48:36 pm MKS wrote: What's your experience with SRC or SRC3 on 7200, is it stable as a MPLS PE? A number of bugs - the worst of which, for us, is a system crash when running BFD on an NPE-G1. NPE-G2's and 7201's are unaffected. Issue as yet unfixed (please look at an e-mail I just sent on this). Enabling Flexible Netflow on an interface while in production also crashes the box, but this is fixed in SRC3. That said, consider SRC3 as a minimum. Lots of interesting features and quite comprehensive, but still a relatively "young" code base. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Chris Griffin cgrif...@ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] SRC2?
Anyone know when 12.2(33)SRC2 is supposed to be released, specifically for the 7600. I had heard by the end of July, but so far no release. Thanks -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] DOM for 6724, could it be??
Unfortunately this does appear to be hardware related and not so much code related. Did some checks and HW 3.0 and 3.1 6724s read the DOM information, 2.4 and 2.3 do not. It even works on SXF9. show int transceiver supported-list Transceiver Type Cisco p/n min version supporting DOM -- - DWDM GBICALL DWDM SFP ALL RX only WDM GBIC ALL DWDM XENPAK ALL DWDM X2 ALL DWDM XFP ALL CWDM GBICNONE CWDM X2 ALL CWDM XFP ALL XENPAK ZRALL X2 ZRALL XFP ZR ALL Rx_only_WDM_XENPAK ALL XENPAK_ER10-1888-04 X2_ERALL XFP_ER ALL XENPAK_LR10-1838-04 X2_LRALL XFP_LR ALL XENPAK_LWALL X2_LWALL XFP_LW NONE XENPAK SRNONE X2 SRALL XFP SR ALL XENPAK LX4 NONE X2 LX4 NONE XFP LX4 NONE XENPAK CX4 NONE X2 CX4 NONE SX GBIC NONE LX GBIC NONE ZX GBIC NONE CWDM_SFP ALL Rx_only_WDM_SFP NONE SX_SFP ALL LX_SFP ALL ZX_SFP ALL SX SFP NONE LX SFP NONE ZX SFP NONE GIgE BX U SFPNONE GigE BX D SFPALL My guess is SX_SFP are the newer SFP-GE-S guys. If it turns out to be an improvement to 3.0+ revs of the 6724, I sure hope they come out with a unique partnumber for it so I can be assured that all future purchases have that capability. You think they would have learned from the whole Xenpack thing (and hence we now have Xenpack+'s). This does seem to indicate that earlier boards are not hardware capable of reading the information which is a bit depressing... Thanks Chris Saku Ytti wrote: > On (2008-03-30 16:15 +0100), Phil Mayers wrote: > >> Hmm; I wonder if there's a slightly newer hardware rev. doing the rounds? > > I looked all PCN's for 6724 and 6748 and could not find such > enhancement, but perhaps PCN was not issued, it's not viewable or wrong > search terms. > >> To the OP: what does "sh mod" report for this linecard? > -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] DOM for 6724, could it be??
Running 12.2.33SXH1 with SFP-GE-S style SFPs. Module 1 is a 6724. show int transceiver Transceiver monitoring is disabled for all interfaces. If device is externally calibrated, only calibrated values are printed. ++ : high alarm, + : high warning, - : low warning, -- : low alarm. NA or N/A: not applicable, Tx: transmit, Rx: receive. mA: milliamperes, dBm: decibels (milliwatts). Optical Optical Temperature Voltage Current Tx Power Rx Power Port (Celsius)(Volts) (mA) (dBm) (dBm) --- --- --- Gi1/9 39.8 3.27 4.8 -6.2 -6.1 Gi1/10 40.7 3.26 4.5 -5.6 -6.1 Gi1/11 40.0 3.27 4.4 -5.1 -6.5 Gi1/12 39.8 3.27 4.7 -5.8 -6.7 Gi1/13 40.0 3.27 4.3 -5.5 -5.5 Gi1/15 40.7 3.28 4.5 -5.5 -6.0 Gi1/16 40.7 3.28 4.6 -5.8 -5.1 Gi1/17 40.8 3.27 4.3 -5.5 -5.1 Also noticed in inventory: NAME: "Gi1/15", DESCR: "1000BaseSX" PID: , VID:, SN: NAME: "Gi1/15 Module Temperature Sensor", DESCR: "GigabitEthernet1/15 Module Temperature Sensor" PID: , VID:, SN: NAME: "Gi1/15 Supply Voltage Sensor", DESCR: "GigabitEthernet1/15 Supply Voltage Sensor" PID: , VID:, SN: NAME: "Gi1/15 Bias Current Sensor", DESCR: "GigabitEthernet1/15 Bias Current Sensor" PID: , VID:, SN: NAME: "Gi1/15 Transmit Power Sensor", DESCR: "GigabitEthernet1/15 Transmit Power Sensor" PID: , VID:, SN: NAME: "Gi1/15 Receive Power Sensor", DESCR: "GigabitEthernet1/15 Receive Power Sensor" PID: , VID:, SN: The release notes mention Digital Optical Monitoring (DOM) Phase 2 as a new feature. Is DOM now officially supported on the 6724?? -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] EoMPLS between 7600 & 7200 config clarification
For 12.2SR there is mux-uni, which allows you to run ports in switchport mode, but then create a subinterface to support eompls. http://tinyurl.com/hfb5p Says its supported by normal LAN cards, but haven't tried it yet. Thanks Chris Justin Shore wrote: > Bill, > > I'm in a similar boat as Jose. What options for EoMPLS do we people > with 6700s have? I'm trying physical to physical with no luck. > Sub-interface isn't an option for a particular design that I'm working > on either. > > Thanks > Justin > > > Bill Wade (wwade) wrote: >> Jose, >> >> SVI (vlan interface) based EoMPLS requires an OSM, SIP-400, SIP-600 >> or ES-20 as core facing interface. >> >> Bill >> >> >> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Jose >>> Sent: Tuesday, February 05, 2008 11:16 AM >>> To: Cisco >>> Subject: [c-nsp] EoMPLS between 7600 & 7200 config clarification >>> >>> Hi everyone. I'm doing some preliminary testing in our lab >>> in order to deploy EoMPLS on our ethernet network but I've >>> run into a little bit of a snag and was wondering if anyone >>> could clarify something for me. >>> >>> The setup I have is 3550---7603-SUP32---7204VXR---3550 >>> >>> I have VLAN 800 setup to cross from one 3550 to the other. >>> The relevant portions of the config are as follows: >>> >>> 7603: >>> interface GigabitEthernet2/2 >>> description to 3550 >>> switchport >>> switchport trunk encapsulation dot1q >>> switchport trunk allowed vlan 800 >>> switchport mode trunk >>> no ip address >>> load-interval 30 >>> ! >>> interface Vlan800 >>> xconnect 10.0.1.4 800 encapsulation mpls ! >>> interface GigabitEthernet1/1 >>> description 7603 to 7204 >>> switchport >>> switchport trunk encapsulation dot1q >>> switchport trunk allowed vlan 220 >>> switchport mode trunk >>> no ip address >>> load-interval 30 >>> ! >>> interface Vlan220 >>> ip address 10.0.0.18 255.255.255.252 >>> load-interval 30 >>> tag-switching mtu 1520 >>> tag-switching ip >>> ! >>> >>> 7204VXR: >>> interface FastEthernet1/0.220 >>> encapsulation dot1Q 220 >>> ip address 10.0.0.17 255.255.255.252 >>> ip ospf cost 40 >>> tag-switching mtu 1520 >>> tag-switching ip >>> ! >>> interface FastEthernet3/0.800 >>> encapsulation dot1Q 800 >>> xconnect 10.0.1.1 800 encapsulation mpls ! >>> >>> Now when I do a "show mpls l2 vc" I can see the circuit up >>> from the 7204 side but down from the 7603 side. I think I >>> have everything setup properly but can't figure out why it >>> wouldn't work. >>> >>> If I change things around a bit and reconfigure the 7603 to >>> use sub-interfaces with dot1q instead of vlan interfaces like this: >>> >>> interface GigabitEthernet2/2.800 >>> encapsulation dot1Q 800 >>> xconnect 10.0.1.4 800 encapsulation mpls ! >>> >>> The circuit is up from both ends and pings from/to each 3550 >>> are successful: >>> >>> frort01-lab#sh mpls l2 vc >>> >>> Local intf Local circuitDest addressVC ID >>> Status >>> - --- >>> -- -- >>> Gi2/2.800 Eth VLAN 800 10.0.1.4800 >>> UP >>> 7603-lab# >>> >>> Is this the only way to get EoMPLS to work between these two >>> devices? >>> I'm sure I've seen the xconnect command used on VLAN >>> interfaces before and it has worked fine. >>> >>> Any thoughts or comments would be greatly appreaciated. >>> >>> Thanks. >>> >>> Jose >>> ___ >>> cisco-nsp 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/ -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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 uptime, can you beat it?
ssrb-monitor-5002> show ver WS-C5002 Software, Version McpSW: 2.3(1) NmpSW: 2.3(1) Copyright (c) 1995-1997 by Cisco Systems NMP S/W compiled on Jul 10 1997, 11:30:44 MCP S/W compiled on Jul 10 1997, 11:50:20 System Bootstrap Version: 2.4(1) Hardware Version: 2.1 Model: WS-C5002 Serial #: 007408223 Module Ports Model Serial # Hw Fw Fw1 Sw -- - -- - -- --- --- 1 2 WS-X5506 007408223 2.12.4(1) 2.4(1) 2.3(1) 2 12WS-X5203 006841349 1.13.1(1) 2.3(1) Module DRAMFLASH NVRAM UsedAvailable -- --- --- --- --- - 1 16384K 8192K256K 88K 168K Uptime is 3446 days, 19 hours, 22 minutes We actually powered down this guy about a month ago and this was the last command executed :-) Gert Doering wrote: > Hi, > > On Wed, Jan 30, 2008 at 10:35:23AM +1030, Ben Steele wrote: >> Anyone got anything currently running longer? >> >> router uptime is 4 years, 10 weeks, 5 days, 9 hours, 13 minutes > > Pff, that's nothing :-) > > win-gw uptime is 8 years, 17 weeks, 2 days, 19 hours, 4 minutes > System restarted by power-on at 11:32:24 UTC Sat Oct 2 1999 > System image file is "flash:c2500-is-l.112-15a.bin.Z", booted via flash > > 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/ -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] Determining software switched FIB entries
Is there a way to determine *which* entries are software switched when a Sup720 exceeds FIB TCAM? In testing I see general warnings from various show commands that exceptions have occurred, but having a way to figure out if a given fib entry was software switched would be helpful. -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] 12.2(33)SXH1 - Release Date?
Any update to the current estimate? Thanks Chris Rodney Dunn wrote: > Estimate (always subject change) 11/23/07. > > Rodney > > On Mon, Oct 22, 2007 at 02:32:43PM +0100, Ian MacKinnon wrote: >> Anybody heard of an SXH1 release date yet? >> >> The date on the current release notes keeps updating with no visible >> changes to the content... >> >> >> Ian MacKinnon wrote: >>> Phil Mayers wrote: >>>> On Sun, 2007-09-16 at 08:46 +0200, Gert Doering wrote: >>>>> Hi, >>>>> >>>>> On Sat, Sep 15, 2007 at 05:28:35PM -0500, mack wrote: >>>>>> Does anyone have a tentative release date for 12.2(33)SXH1? >>>>> I haven't, sorry. But you have made me curious - anything wrong with SXH >>>>> that we should be aware of? (There must be a reason why you ask for >>>>> SHX1). >>>>> >>>>> We're planning to go to modular SXH "really soon now"... >>>>> >>>> On that topic: does anyone know whether SXH contains some or all of the >>>> bugfixes from SRA? SRB? To which minor revisions? I know the release >>>> notes state that "12.2(33)SXH contains all fixes that are in >>>> 12.2(33)SXF10" but obviously that doesn't cover all the new features. >>>> >>>> >>> The release notes also say to check the bug toolkit for outstanding bugs. >>> But when I chose 12.2(33)SXH as the release there are no known bugs at >>> all. Thats all statuses, all severity everything >>> >>> Given there are no bugs, it does not need a SXH1 :-) >>> >> _______ >> cisco-nsp 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/ -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] 100Mbit SM fiber ports on Cat 65XX
Yes, I think this is starting to drive people to other vendors. Silly when the high end box can't do it, but the low end ones can... Marian Ďurkovič wrote: > On Thu, Oct 18, 2007 at 10:38:05AM +0300, Tassos Chatzithomaoglou wrote: >> WS-X6148-FE-SFP ( shared bus connection :( ) >> >> It's a shame that all other WS-X67xx gigabit cards do not support such SFPs. > > ... and those WS-X67xx-SFP cards also don't support Digital Optical > Monitoring :-( > > It would be really helpful to have a new revision of 67xx cards supporting > both 100 Mbps and 1 Gbps SFPs with proper DOM support. > > With kind regards, > > M. > >> -- >> Tassos >> >> Robert Boyle wrote on 18/10/2007 10:17 πμ: >>> Hello all, >>> >>> I am trying to simplify some of our POP setups. We frequently have a >>> stand alone fiber transceiver rack shelf for conversion of a few >>> 100Mbit SM fiber connections to 100Base-T. In our Foundry XMR gear, >>> we can install 100Mbit SM SFPs in the GigE slots. Is there any card >>> (current or discontinued) for the Catalyst 65XX which will directly >>> take 100Mbit SM fiber directly or via a SFP or GBIC? All of our >>> routers have Sup720-3BXL engines. We run 12.2SXF now. Thanks! >>> >>> -Robert >>> >>> >>> >>> Tellurian Networks - Global Hosting Solutions Since 1995 >>> http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 >>> "Well done is better than well said." - Benjamin Franklin > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] fabric counters on 6500s
Can someone point me to some descriptive information about fabric errors and procedures to troubleshoot them. Basically I am looking for descriptive information on: show fabric errors show fabric channel-counters remote command switch show fabric errors For instance, what do rxErrors mean on the channel counters, and how do they differ from errors shown by show fabric errors. What is the best procedure to troubleshoot rxErrors under channel-counters. I was told by TAC that any module in the system can cause rxErrors on any slot and channel, which I am skeptical of. How do show fabric errors differ from the switch and msfc point of view. So far I have yet to ever see an error under "show fabric errors", but they are not uncommon on the switch side. Has anyone had an rxError problem so great that they had to swap the chassis? Thanks! -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] L2 SNMP performance on Cat65/76?
Lately we have been having performance issues with SNMP queries to Sup720 based systems when gathering Layer 2 information (ifOperStatus and several layer 2 traffic counters). SNMP for these elements will be dropped for long periods of time (5-15 minutes). This normally happens during network reconvergence events, but sometimes just happens. During these intervals queries for layer 3 information (BGP etc) occur just fine. I assume this is because in native IOS, the snmp query has to be relayed to the sup from the msfc? Any tips on making it a bit more responsive even during convergence? IOS is 12.2.18SXF7. Thanks -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] VRF forwarding limits on SVI?
Are we going to see eompls support on SVIs at some point on the Sup720 (PFC MPLS)? I have heard yes, but future code, and then no unless you have SIP/SPAs. Thanks! Chris Ian Cox wrote: > At 11:02 AM 7/19/2007 -0400, Jeff Kell wrote: >> 6500 Sup-II/MSFC2/PFC2 can't do SVI VRF forwarding? >> >>> UTC-6509(config)#interface Vlan801 >>> UTC-6509(config-if)# description No Man's LAN ring 1 >>> UTC-6509(config-if)# ip vrf forwarding no-mans-lan >>> %This interface does not support ip vrf forwarding >> Say it ain't so...? IOS c6sup22-jk2s-mz.121-26.E5. > > It is so, VRFs are not supported on SVIs on Sup2, you need Sup720 for > vrf support on SVIs. Sup2 PFC hardware was not designed to support VRFs. > > > Ian > >> Jeff >> ___ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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 crash on loss of power to power bay 1
I think you are running into CSCeb51698. We hit this a while back... Thanks Chris Rick Kunkel wrote: > Hello all, > > Many thanks for help in the past. I'm hoping someone will have something > enlightening about this. TAC and Bugfinder are turning up little, so I > dunno what the chances are, but here it is... > > I'll paste a bunch of version and module info at the bottom of this email, > so as not to clutter the part that peple are more likely to read here. > Essentially, what's happening is that when power is lost to Power Supply > 1, the router crashes. [System returned to ROM by power-on (SP by error - > a Software forced crash, PC 0x4011EF5C)] Power loss to PS2 doesn't cause > it. If I swap the two power supplies, it still does it on PS1. In other > words, if the power is lost to "bay" 1, for lack of a better word, it > crashes. > > Has anyone ever run into anything like this? One thing to note is that > the input AC appears to be a bit low. I don't know if that could > contribute. > > Thanks much. All the relevant info that's not overly verbose follows. > > Here are the modules (modified "show mod"): > > Mod Ports Card Type Model > --- - -- -- > 12 Catalyst 6000 supervisor 2 (Active)WS-X6K-SUP2-2GE > 28 8 port 1000mb ethernet WS-X6408-GBIC > 3 48 48 port 10/100 mb RJ-45 ethernet WS-X6248-RJ-45 > > Mod Sub-Module Model > --- --- --- > 1 Policy Feature Card 2 WS-F6K-PFC2 > 1 Cat6k MSFC 2 daughterboard WS-F6K-MSFC2 > > > A show ver: > > Cisco Internetwork Operating System Software > IOS (tm) c6sup2_rp Software (c6sup2_rp-PSV-M), Version 12.1(19)E1, EARLY > DEPLOYMENT RELEASE SOFTWARE (fc2) > TAC Support: http://www.cisco.com/tac > Copyright (c) 1986-2003 by cisco Systems, Inc. > Compiled Sun 29-Jun-03 22:45 by nmasa > Image text-base: 0x40008C00, data-base: 0x41814000 > ROM: System Bootstrap, Version 12.2(17r)S1, RELEASE SOFTWARE (fc1) > BOOTLDR: c6sup2_rp Software (c6sup2_rp-PSV-M), Version 12.1(19)E1, EARLY > DEPLOYMENT RELEASE SOFTWARE (fc2) > SEABD1 uptime is 1 week, 1 day, 21 hours, 43 minutes > Time since SEABD1 switched to active is 1 week, 1 day, 21 hours, 42 > minutes > System returned to ROM by power-on (SP by error - a Software forced crash, > PC 0x4011EF5C) > System restarted at 14:20:22 PDT Tue May 22 2007 > System image file is "sup-bootflash:c6sup22-psv-mz.121-19.E1.bin" > cisco WS-C6509 (R7000) processor (revision 3.0) with 458752K/65536K bytes > of memory. > Processor board ID SAL0730H93F > R7000 CPU at 300Mhz, Implementation 39, Rev 3.3, 256KB L2, 1024KB L3 Cache > Last reset from power-on > X.25 software, Version 3.0.0. > Bridging software. > 2 Virtual Ethernet/IEEE 802.3 interface(s) > 48 FastEthernet/IEEE 802.3 interface(s) > 10 Gigabit Ethernet/IEEE 802.3 interface(s) > 381K bytes of non-volatile configuration memory. > 32768K bytes of Flash internal SIMM (Sector size 512K). > Configuration register is 0x2102 > > > A "show env status power-supply X" shows the following for PS1 and PS2 > > power-supply X: > power-supply X fan-fail: OK > power-supply X power-input: AC low > power-supply X power-output-fail: OK > > > Thanks, > > Rick Kunkel > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 392-2061 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp 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] DOM redux
Hi all, We are thinking about switching to DOM based SFPs and are experimenting with them. So far we have found them to work ok with: 3750 with SEE2 code. 3750me with 12.2.35SE2 code (SEG gave bad RX values). 6509/7609/Sup720 on the sup SFP ports themselves. Haven't yet tried them on 2960s. Of course the big hold out seems to be the 6724SFP card. I have seen a few threads in the past on DOM support here, but never seemed to come to a conclusion. Is this just a waiting game until the software catches up, or is this a fundamental hardware issue with the 6724. I would think software based on the fact that the SFP can be interrogated for other things such as serial number, etc. Thanks! -- Chris Griffin [EMAIL PROTECTED] Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
