[c-nsp] CPU profiling
Hello, I'm trying to do profiling on cpu process that's occasionally 100% (PDU DISPATCHER). This is what I'm using: process cpu threshold type total rising 50 interval 5 falling 30 interval 5 ! event manager applet profile_snmp_start event syslog pattern .*SYS-1-CPURISINGTHRESHOLD.* action 0 cli command enable action 1 cli command clear profile action 2 cli command profile task 708 action 3 cli command profile 0800 0FFF 4 ! event manager applet profile_snmp_stop event syslog pattern .*SYS-1-CPUFALLINGTHRESHOLD.* action 0 cli command enable action 1 cli command profile stop When I do it from cli myself, it works. Whan I wait for EEM to do it, it never does. I see it matches syslog event, but when I log in and try show profile terse, nothing is there. Anyone? Kind Regards ___ cisco-nsp 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] CPU profiling
On Mon, 2014-02-03 at 09:44 +0100, Cydon Satyr wrote: event manager applet profile_snmp_start [...] When I do it from cli myself, it works. Whan I wait for EEM to do it, it never does. I see it matches syslog event, but when I log in and try show profile terse, nothing is there. Are you using TACACS+ with command authorization by any chance? I that case you need to configure event manager session cli username name or it will fail. (I'm not sure it actually does the authorization steps at all though.) None of the commands ask any questions that needs input? -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] CPU profiling
Ah, that was it! I had a feeling it had to do with authorization. Thanks! Kind Regards On Mon, Feb 3, 2014 at 11:14 AM, Peter Rathlev pe...@rathlev.dk wrote: On Mon, 2014-02-03 at 09:44 +0100, Cydon Satyr wrote: event manager applet profile_snmp_start [...] When I do it from cli myself, it works. Whan I wait for EEM to do it, it never does. I see it matches syslog event, but when I log in and try show profile terse, nothing is there. Are you using TACACS+ with command authorization by any chance? I that case you need to configure event manager session cli username name or it will fail. (I'm not sure it actually does the authorization steps at all though.) None of the commands ask any questions that needs input? -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASA5520 latency OSPF drops
Thank you to all for your replies and advice over the weekend. We are treating the situation as a DoS originating from within our network and are locking things down accordingly. You may be hearing from me again soon depending on how things go! Adam From: John Kougoulos [mailto:john.kougou...@gmail.com] Sent: Saturday, February 01, 2014 4:30 PM To: Adam Greene Cc: cisco-nsp@puck.nether.net NSP Subject: Re: [c-nsp] ASA5520 latency OSPF drops Hi, since you don't lose the OSPF session between 5520 and 2921, I would say that this is not related to ASA CPU, DoS from Internet etc. This would also suggest that 2950G in general works ok. The vlan that connects 3750 to 5520 exists only in 2950G and only these 2 devices are connected? Would it be possible that there is some kind of spanning tree instability issue in this VLAN that causes this? Other than this, I would watch the ASA logs carefully, possibly upgrade to the latest 8.2 in case that there is a bug that could lead to some kind of blocking of the input queue. Also I think there is a show memory xxx command that allows you to see how much memory is allocated / freed per process since boot. This might give you a hint on which process allocates these few megabytes when the issue occurs. Regards, John On Sat, Feb 1, 2014 at 8:39 PM, Adam Greene maill...@webjogger.net mailto:maill...@webjogger.net wrote: Octavio, What about pings from the external world to the ASA? These appear normal, since the ASA5520---2921 OSPF session is not dropping. Also, I'd increase logging verbosity to a Syslog server with an interface connected to each side of the ASA. Good idea. And I'd also be prepared to do a packet capture on both sides of the ASA for the next time it happens. Tough since they occur so sporadically, and up to now have been relatively brief. I wonder if there is some way to trigger a capture upon a specific event occurring. Or maybe will we just have to keep tons of logs which roll over, and hope we catch something. We generally have about 40Mbps pumping through the unit. That's a lot of data, and a fast rollover. You mention spares (I assume cold spares) but also OSPF, do you have your devices HA? Yes, cold spares. Devices are not HA. I have seen posts about OSPF failing in 8.2 when the active host of a failover pair fails, due to a bug, but that doesn't seem to be our case here as far as I can tell. Any other ideas welcome. Sounds like people's thoughts are tending toward DoS ... Thanks, Adam -Original Message- From: Octavio Alvarez [mailto:alvar...@alvarezp.ods.org mailto:alvar...@alvarezp.ods.org ] Sent: Saturday, February 01, 2014 1:24 PM To: Adam Greene Cc: cisco-nsp@puck.nether.net mailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 latency OSPF drops On 02/01/2014 08:27 AM, Adam Greene wrote: Every so often (it started three months ago, about once per month, now it's about once per week, but it's not regular), we're getting very high latency on pings from our Internal Network to the ASA5520, and the OSPF adjacency between the 3750 and the ASA5520 is dropping. The issue was lasting about 60 seconds each time up to this morning, when it lasted about 3 hours. Ugh! Pings from the Internal Network to the 3750 and 2950G are fine. What about pings from the external world to the ASA? ALso, I'd increase logging verbosity to a Syslog server with an interface connected to each side of the ASA. And I'd also be prepared to do a packet capture on both sides of the ASA for the next time it happens. You mention spares (I assume cold spares) but also OSPF, do you have your devices HA? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net mailto: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] Sup720 - FIB full, software switching
Hi, today I saw 2x Sup720-3B (default 192K IPv4 routes) that received a full table. After FIB was filled IOS gave a warning that it now may forward in software (and resetted all BGP sessions because of memory issues). I don't have the exact messages. The real problem occured after that. I shut the full table BGP session and cleared the others, the system now had a few routes only again. But it started to drop packets, I saw no pattern, it looked nearly random. I needed to reboot both boxes to resolve that issue. IOS was s72033-advipservicesk9_wan-mz.122-33.SXJ.bin Is there a way to avoid those issues by let it just ignoring routes not matching into the FIB? Is there a command to reset the routing mode/routes back to CEF without reloading the box? kind regards Rolf ___ cisco-nsp 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 - FIB full, software switching
Hi, On Mon, Feb 03, 2014 at 03:09:07PM +0100, Rolf Hanßen wrote: today I saw 2x Sup720-3B (default 192K IPv4 routes) that received a full table. After FIB was filled IOS gave a warning that it now may forward in software (and resetted all BGP sessions because of memory issues). I don't have the exact messages. Sup720 will never recover from that except by reload :-( gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp2bb6uN_jhI.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Sup720 - FIB full, software switching
I've never tried it, but you might be able to create a MLS rate limiter/CoPP policy to drop all the FIB Miss packets from being punted and try to reset the HW CEF table and see if that works. I doubt it will, but in a pinch it could be worth a try. On Mon, Feb 3, 2014 at 9:09 AM, Rolf Hanßen n...@rhanssen.de wrote: Hi, today I saw 2x Sup720-3B (default 192K IPv4 routes) that received a full table. After FIB was filled IOS gave a warning that it now may forward in software (and resetted all BGP sessions because of memory issues). I don't have the exact messages. The real problem occured after that. I shut the full table BGP session and cleared the others, the system now had a few routes only again. But it started to drop packets, I saw no pattern, it looked nearly random. I needed to reboot both boxes to resolve that issue. IOS was s72033-advipservicesk9_wan-mz.122-33.SXJ.bin Is there a way to avoid those issues by let it just ignoring routes not matching into the FIB? Is there a command to reset the routing mode/routes back to CEF without reloading the box? kind regards Rolf ___ cisco-nsp 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] Sup720 - FIB full, software switching
Simple answer: No. One of the major design errors of the FIB in the Sup720. Unfortunately, once the FIB is full, the only way to get it back to normal is to restart the whole box. CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched %CFIB-SP-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched %CFIB-SP-STBY-7-CFIB_EXCEPTION : FIB TCAM exception, Some entries will be software switched This error message is received when the amount of available space in the TCAM is exceeded. This results in high CPU. This is a FIB TCAM limitation. Once TCAM is full, a flag will be set and FIB TCAM exception is received. This stops from adding new routes to the TCAM. Therefore, everything will be software switched. The removal of routes does not help resume hardware switching. Once the TCAM enters the exception state, the system must be reloaded to get out of that state. You can view if you have hit a FIB TCAM exception with the following command: 6500-2#sh mls cef exception status Current IPv4 FIB exception state = TRUE Current IPv6 FIB exception state = FALSE Current MPLS FIB exception state = FALSE When the exception state is TRUE, the FIB TCAM has hit an exception. The maximum routes that can be installed in TCAM is increased by the mls cef maximum-routes command. This issue is common when trying to route a full BGP table on PFC-3A or a PFC-3B. **Note a failover of the supervisors in dual supervisor system will not recover this exception, even through the “show mls cef exception status” will no longer indicate a FIB exception. A full reload of the switch is required. Regards, Chris Am 03/02/14 15:09, schrieb Rolf Hanßen: Hi, today I saw 2x Sup720-3B (default 192K IPv4 routes) that received a full table. After FIB was filled IOS gave a warning that it now may forward in software (and resetted all BGP sessions because of memory issues). I don't have the exact messages. The real problem occured after that. I shut the full table BGP session and cleared the others, the system now had a few routes only again. But it started to drop packets, I saw no pattern, it looked nearly random. I needed to reboot both boxes to resolve that issue. IOS was s72033-advipservicesk9_wan-mz.122-33.SXJ.bin Is there a way to avoid those issues by let it just ignoring routes not matching into the FIB? Is there a command to reset the routing mode/routes back to CEF without reloading the box? kind regards Rolf ___ cisco-nsp 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] Sup720 - FIB full, software switching
Is there a way to avoid those issues by let it just ignoring routes not matching into the FIB? Hi Rolf, Unfortunately the only option is to reset the bgp neighbor after the number of received routes crosses a certain threshold. neighbor x.x.x.x maximum-prefix 1 75 restart 5 But still better than having the whole box stuck in process switching. adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rolf Hanßen Sent: Monday, February 03, 2014 3:09 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Sup720 - FIB full, software switching Hi, today I saw 2x Sup720-3B (default 192K IPv4 routes) that received a full table. After FIB was filled IOS gave a warning that it now may forward in software (and resetted all BGP sessions because of memory issues). I don't have the exact messages. The real problem occured after that. I shut the full table BGP session and cleared the others, the system now had a few routes only again. But it started to drop packets, I saw no pattern, it looked nearly random. I needed to reboot both boxes to resolve that issue. IOS was s72033-advipservicesk9_wan-mz.122-33.SXJ.bin Is there a way to avoid those issues by let it just ignoring routes not matching into the FIB? Is there a command to reset the routing mode/routes back to CEF without reloading the box? kind regards Rolf ___ cisco-nsp 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] TAC hits a new record level of aggravation...
On Sat, Feb 1, 2014 at 12:41 PM, Chris Marget ch...@marget.com wrote: I tried two operating systems and four browsers yesterday. I couldn't upload files that were just a few hundred KB. That was on Friday. Nothing has changed on my end (hardware/software/network), but I'm able to upload files just fine today. ___ cisco-nsp 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] IOS-XR: 6PE - next-hop manipulation in route-policy.
Hi list, I am trying to manipulate the next-hop for community-tagged routes, inbound on a 6PE router. Routes are received from route-reflectors, and should be treated inbound. In this specific scenario I am trying to change a next-hop. The configuration is based on what we have in production on IOS today, where this works just fine. PE is ASR9000 running IOS-XR 4.3.2. My configuration; Non-essential configuration has been omitted. router static address-family ipv6 unicast 2001:db8::160/128 Null0 :::192.168.0.1/128 Null0 router bgp asn neighbor-group IPv6RR address-family ipv6 labeled-unicast route-policy rr-edge-in in route-policy rr-edge-in if community matches-any (1000:6) and destination in (::/0 ge 64) then set next-hop 2001:db8::160 endif pass end-policy Also tried this.. route-policy rr-edge-in if community matches-any (1000:6) and destination in (::/0 ge 64) then set next-hop :::192.168.0.1 endif pass end-policy The defined policy is processing the routes. I tried swapping the next-hop statement for a simple drop, and the prefix was dropped. In IOS, I use an IPv6 next-hop which works just fine. In IOS-XR, I tried with both a normal IPv6 unicast address, and with IPv4-mapped address - without success. I am sure there is a reasonable explanation for this, and I have a feeling it lies in the 6PE part of the next-hop magic. As it seems to be working just fine in IOS, I'm fairly confident it should be possible to do in XR as well. Any help is appreciated! ___ cisco-nsp 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] TAC hits a new record level of aggravation...
Hi Chris / All, Thanks for alerting us to this problem. The Support Case Manager team put a fix (we hope) in this weekend. Glad it is now working for you. Sincerely, David. On 2/3/2014 10:12 AM, Chris Marget wrote: On Sat, Feb 1, 2014 at 12:41 PM, Chris Marget ch...@marget.com wrote: I tried two operating systems and four browsers yesterday. I couldn't upload files that were just a few hundred KB. That was on Friday. Nothing has changed on my end (hardware/software/network), but I'm able to upload files just fine today. ___ cisco-nsp 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] Sup720 - FIB full, software switching
One other thing I noticed from your email and something that we've experienced in the past as well. I think it may also be related to hitting the TCAM limit but check to see if you have this command enabled: mls rate-limit unicast cef receive 1 255 According to Cisco, that command will automatically get added to your config when the tables get full. That command will start to drop packets and unless you look for it you wouldn't know it's there because generally it's not. All BGP sessions appear normal and none of your interfaces show full yet you're still dropping packets. Cisco advised us to increase the receive to 100 to avoid any possible issues in the future. Thanks to the other replies about having to reload the switch to clear the TCAM exception. I didn't know that once you hit it that the only way to fix it was to completely reload the box. Jose On 2/3/2014 9:09 AM, Rolf Hanßen wrote: Hi, today I saw 2x Sup720-3B (default 192K IPv4 routes) that received a full table. After FIB was filled IOS gave a warning that it now may forward in software (and resetted all BGP sessions because of memory issues). I don't have the exact messages. The real problem occured after that. I shut the full table BGP session and cleared the others, the system now had a few routes only again. But it started to drop packets, I saw no pattern, it looked nearly random. I needed to reboot both boxes to resolve that issue. IOS was s72033-advipservicesk9_wan-mz.122-33.SXJ.bin Is there a way to avoid those issues by let it just ignoring routes not matching into the FIB? Is there a command to reset the routing mode/routes back to CEF without reloading the box? kind regards Rolf ___ cisco-nsp 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] Sup720 - FIB full, software switching
Hey, I don't think you can actually recover from that. What you might be able to do, depending on your design, is use selective route download (http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-selective-download.html ) to prevent routes from overflowing your FIB in the first place. Obviously you'll need to be careful to avoid blackholing traffic. Spyros Kakaroukas IP Engineer ? Consider our environment – Think before you print ? -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rolf Han?en Sent: Monday, February 03, 2014 4:09 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Sup720 - FIB full, software switching Hi, today I saw 2x Sup720-3B (default 192K IPv4 routes) that received a full table. After FIB was filled IOS gave a warning that it now may forward in software (and resetted all BGP sessions because of memory issues). I don't have the exact messages. The real problem occured after that. I shut the full table BGP session and cleared the others, the system now had a few routes only again. But it started to drop packets, I saw no pattern, it looked nearly random. I needed to reboot both boxes to resolve that issue. IOS was s72033-advipservicesk9_wan-mz.122-33.SXJ.bin Is there a way to avoid those issues by let it just ignoring routes not matching into the FIB? Is there a command to reset the routing mode/routes back to CEF without reloading the box? kind regards Rolf ___ cisco-nsp 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 e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Rolaware Hellas SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication. ___ cisco-nsp 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] IOS-XR: 6PE - next-hop manipulation in route-policy.
I don't have time at the moment to look up the details, but I seem to recall that beginning in XR 4.2, there are limitations (or maybe flat out restrictions) on setting the next-hop on an ingress route policy. I do know that we had to change several of our route policies to get around this when doing upgrades to 4.2 or beyond. John On Mon, Feb 3, 2014 at 8:17 AM, Jonathan Hart johathan.h...@gmail.com wrote: Hi list, I am trying to manipulate the next-hop for community-tagged routes, inbound on a 6PE router. Routes are received from route-reflectors, and should be treated inbound. In this specific scenario I am trying to change a next-hop. The configuration is based on what we have in production on IOS today, where this works just fine. PE is ASR9000 running IOS-XR 4.3.2. My configuration; Non-essential configuration has been omitted. router static address-family ipv6 unicast 2001:db8::160/128 Null0 :::192.168.0.1/128 Null0 router bgp asn neighbor-group IPv6RR address-family ipv6 labeled-unicast route-policy rr-edge-in in route-policy rr-edge-in if community matches-any (1000:6) and destination in (::/0 ge 64) then set next-hop 2001:db8::160 endif pass end-policy Also tried this.. route-policy rr-edge-in if community matches-any (1000:6) and destination in (::/0 ge 64) then set next-hop :::192.168.0.1 endif pass end-policy The defined policy is processing the routes. I tried swapping the next-hop statement for a simple drop, and the prefix was dropped. In IOS, I use an IPv6 next-hop which works just fine. In IOS-XR, I tried with both a normal IPv6 unicast address, and with IPv4-mapped address - without success. I am sure there is a reasonable explanation for this, and I have a feeling it lies in the 6PE part of the next-hop magic. As it seems to be working just fine in IOS, I'm fairly confident it should be possible to do in XR as well. Any help is appreciated! ___ cisco-nsp 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] Sup720 - FIB full, software switching
Hi, indeed, the limiter was installed. kind regards Rolf One other thing I noticed from your email and something that we've experienced in the past as well. I think it may also be related to hitting the TCAM limit but check to see if you have this command enabled: mls rate-limit unicast cef receive 1 255 According to Cisco, that command will automatically get added to your config when the tables get full. That command will start to drop packets and unless you look for it you wouldn't know it's there because generally it's not. All BGP sessions appear normal and none of your interfaces show full yet you're still dropping packets. Cisco advised us to increase the receive to 100 to avoid any possible issues in the future. Thanks to the other replies about having to reload the switch to clear the TCAM exception. I didn't know that once you hit it that the only way to fix it was to completely reload the box. Jose On 2/3/2014 9:09 AM, Rolf Hanßen wrote: Hi, today I saw 2x Sup720-3B (default 192K IPv4 routes) that received a full table. After FIB was filled IOS gave a warning that it now may forward in software (and resetted all BGP sessions because of memory issues). I don't have the exact messages. The real problem occured after that. I shut the full table BGP session and cleared the others, the system now had a few routes only again. But it started to drop packets, I saw no pattern, it looked nearly random. I needed to reboot both boxes to resolve that issue. IOS was s72033-advipservicesk9_wan-mz.122-33.SXJ.bin Is there a way to avoid those issues by let it just ignoring routes not matching into the FIB? Is there a command to reset the routing mode/routes back to CEF without reloading the box? kind regards Rolf ___ cisco-nsp 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] ASA5520 latency OSPF drops
Hi Adam, So, the symptoms are high latency from internal network to Inside of ASA's interface? And during this problem, the switch appears to be re-establishing the OSPF neighbor? It wasn't clear to me if you were also seeing packet loss or not. A suggestion to narrow down some things: If the 2950G has an L3 interface in the same segment as the ASA's inside interface, then do pings from the ASA (and likewise from the switch) show the latency? If there is no L3 interface on the 2950, then perform this test from a device local to the network. One thing you want to do is determine if OSPF is the cause, or just a victim of a different problem. Checking from local devices (or adding static routes) will help eliminate OSPF. For some local issues, things that come to mind: * Duplicate IP addresses * L2 loops * Spanning-tree changes Also, on the ASA, look at the output of show asp drop. You might want to clear it, and then look at this output after the next occurrence of the issue. Sincerely, David. On 2/1/2014 11:27 AM, Adam Greene wrote: Hi, We are having a problem with high latency and OSPF drops on an ASA5520. The portion of our network in question is connected as follows: Internal Network---3750---2950G---ASA5520---2950G---2921---External World The two 2950G's shown above are actually the same device; we are using VLANs to segment the traffic. We're running OSPF between the 3750 and the ASA5520, and between the ASA5520 and the 2921. Every so often (it started three months ago, about once per month, now it's about once per week, but it's not regular), we're getting very high latency on pings from our Internal Network to the ASA5520, and the OSPF adjacency between the 3750 and the ASA5520 is dropping. The issue was lasting about 60 seconds each time up to this morning, when it lasted about 3 hours. Ugh! Pings from the Internal Network to the 3750 and 2950G are fine. The OSPF adjacency between the ASA5520 and the 2921 is not affected. This would seem to suggest an issue between the 2950G and the ASA5520. There are some input errors showing on the inside interface of the ASA5520, but very few compared with the traffic that passes through the interface (0.009%). There is no evidence of errors on the 2950G interface(s), even when show controllers Ethernet-controller is issued. The 3750 is showing: Feb 1 06:12:03: %OSPF-5-ADJCHG: Process 2, Nbr x.x.x.x on FastEthernet1/0/1 from LOADING to FULL, Loading Done Feb 1 06:17:03: %OSPF-5-ADJCHG: Process 2, Nbr x.x.x.x on FastEthernet1/0/1 from LOADING to FULL, Loading Done Feb 1 06:18:54: %OSPF-5-ADJCHG: Process 2, Nbr x.x.x.x on FastEthernet1/0/1 from LOADING to FULL, Loading Done Feb 1 07:40:35: %OSPF-5-ADJCHG: Process 2, Nbr x.x.x.x on FastEthernet1/0/1 from LOADING to FULL, Loading Done Feb 1 07:46:55: %OSPF-5-ADJCHG: Process 2, Nbr x.x.x.x on FastEthernet1/0/1 from LOADING to FULL, Loading Done Feb 1 07:59:46: %OSPF-5-ADJCHG: Process 2, Nbr x.x.x.x on FastEthernet1/0/1 from LOADING to FULL, Loading Done Strangely, it is not showing any FULL to DOWN events. The ASA is not logging OSPF drops, but show ospf neighbor does show that the neighbor has only been up since the last drop. We do not see any evidence of CPU or traffic spikes (either in terms of bandwidth, connection counts, or number of unicast packets traversing the link). RAM on the ASA5520 went up very slightly during this morning's events, but hardly enough to care about. MTU is set to 1500 on all implicated 3750, 2950G and ASA interfaces. We are rather stumped. The ASA is running 8.2(4) . we're thinking of upgrading to 8.2(5). We are also considering: - bypass the 2950G - replace the ASA5520 with a spare - replace the 3750 with a spare All these options imply 3am maintenance windows. Any ideas before we start to have a few sleepless nights? :) Thanks, 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/
Re: [c-nsp] Sup720 - FIB full, software switching
On 2/3/14 7:03 AM, Adam Vitkovsky wrote: Is there a way to avoid those issues by let it just ignoring routes not matching into the FIB? Hi Rolf, Unfortunately the only option is to reset the bgp neighbor after the number of received routes crosses a certain threshold. neighbor x.x.x.x maximum-prefix 1 75 restart 5 This is a suitable solution if you have one feed and no internal routes. Practically speaking, you probably have routes coming from different directions, and therefore you'd have to manage (by guessing) these thresholds like a secret art form. pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Sup720 - FIB full, software switching
There is a field upgrade available from Cisco for the 3B to convert it to a 3BXL that as I recall was fairly cheap, and was pretty simple to install. -- Don On 2/3/2014 9:09 AM, Rolf Hanßen wrote: Hi, today I saw 2x Sup720-3B (default 192K IPv4 routes) that received a full table. After FIB was filled IOS gave a warning that it now may forward in software (and resetted all BGP sessions because of memory issues). I don't have the exact messages. The real problem occured after that. I shut the full table BGP session and cleared the others, the system now had a few routes only again. But it started to drop packets, I saw no pattern, it looked nearly random. I needed to reboot both boxes to resolve that issue. IOS was s72033-advipservicesk9_wan-mz.122-33.SXJ.bin Is there a way to avoid those issues by let it just ignoring routes not matching into the FIB? Is there a command to reset the routing mode/routes back to CEF without reloading the box? kind regards Rolf ___ cisco-nsp 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] Sup720 - FIB full, software switching
On 02/03/2014 06:09 AM, Rolf Hanßen wrote: But it started to drop packets, I saw no pattern, it looked nearly random. I needed to reboot both boxes to resolve that issue. That pretty much sums it up. You can set up some inbound filtering to prevent a lot of routes to go into the routing table in the first place, and thus, protecting the FIB. There was some discussion in Pepelnjak's blog about the filtering, precisely for the same problem with a Sup720: [1] and its followup post [2] some time ago. [1] http://blog.ipspace.net/2012/01/how-could-we-filter-extraneous-bgp.html [2] http://blog.ipspace.net/2012/01/filter-inbound-bgp-prefixes-summary.html ___ cisco-nsp 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 - FIB full, software switching
Hi, On Mon, Feb 03, 2014 at 10:24:56AM -0500, Lobo wrote: Thanks to the other replies about having to reload the switch to clear the TCAM exception. I didn't know that once you hit it that the only way to fix it was to completely reload the box. Been there, done that. Affected only very few prefixes for us, so we didn't notice right away... tracked it down eventually with Ytti's help (thanks)... reload. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp32xCcpufQX.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Packet-level iSCSI debugging
Nick: We are not using Jumbo Frames or QoS yet, but we haven't seen any indication of packet drops caused by saturation of the links. The hosts and storage are primarily plugged into the 2ks, and we are seeing the issue across multiple ones. It does span multiple LUNs, and I believe they're spread among the two SPs. The CPU of both SPs is well below 50%. Blake: Do you know specifically which program? We've got an OptiView XG...thanks for reminding me. I'll have to see if this sucker has the tools we need. Nick: You're absolutely correct...thank you. I'm not seeing any drops on any interfaces, so if something's happening to those packets, it's not being logged by the Nexus. On Sun, Feb 2, 2014 at 9:03 AM, Nick Hilliard n...@foobar.org wrote: On 02/02/2014 01:41, Mike Hale wrote: the utilization is well below 10gigs what you mean here is that the utilization is well below 10gigs averaged over the sampling period. Iscsi is sensitive to dropped packets, and it could be that you're dropping packets due to traffic bursts which are too short to see on your graph sampling period (300 seconds? most graphs use 300s by default). Check out the dropped packet counts on all your iscsi ports and see what's happening there. Even better, monitor the packet drop rate on your graphing system and build up a profile of what's happening. Nick -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ cisco-nsp 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-level iSCSI debugging
No, but that's exactly the tool I would have suggested looking at to start with. -Blake On Mon, Feb 3, 2014 at 11:57 AM, Mike Hale eyeronic.des...@gmail.comwrote: Nick: We are not using Jumbo Frames or QoS yet, but we haven't seen any indication of packet drops caused by saturation of the links. The hosts and storage are primarily plugged into the 2ks, and we are seeing the issue across multiple ones. It does span multiple LUNs, and I believe they're spread among the two SPs. The CPU of both SPs is well below 50%. Blake: Do you know specifically which program? We've got an OptiView XG...thanks for reminding me. I'll have to see if this sucker has the tools we need. Nick: You're absolutely correct...thank you. I'm not seeing any drops on any interfaces, so if something's happening to those packets, it's not being logged by the Nexus. On Sun, Feb 2, 2014 at 9:03 AM, Nick Hilliard n...@foobar.org wrote: On 02/02/2014 01:41, Mike Hale wrote: the utilization is well below 10gigs what you mean here is that the utilization is well below 10gigs averaged over the sampling period. Iscsi is sensitive to dropped packets, and it could be that you're dropping packets due to traffic bursts which are too short to see on your graph sampling period (300 seconds? most graphs use 300s by default). Check out the dropped packet counts on all your iscsi ports and see what's happening there. Even better, monitor the packet drop rate on your graphing system and build up a profile of what's happening. Nick -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ cisco-nsp 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] Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever)
On Feb 2, 2014, at 9:35 PM, Jeff Kell jeff-k...@utc.edu wrote: Still somewhat of a mystery, as there is no proper twinax standard like there is with 10G-SR, LR, LRM, ER, etc. Just picking one at random from google.. http://www.cdw.com/shop/products/Proline-Force10-CBL-10GSFP-DAC-5M-Compatible-5M-PASSIVE-TWINAX-SFP-Cable/2785340.aspx One can get 2x10G SR optics + om3 mmf for lower cost than the above cable. - Jared ___ cisco-nsp 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] TAC hits a new record level of aggravation...
Hi list, FYI, Support Case Manager now shows this message: UPDATE:Sharing Files with TAC via FTP Please be aware that using Support Case Manager's 'Attach Files' feature is the preferred method to share files with TAC by uploading files directly to your support case. However, if you use the alternate FTP method to attach files to your support case, please note the upload directory has changed from ftp.cisco.com/incoming to ftp.cisco.com/incoming/TAC. With a link to: http://www.cisco.com/web/about/security/intelligence/01_12_TAC_Uploads.html So FTP is still a last resort option. Regards, Lukas ___ cisco-nsp 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] TAC hits a new record level of aggravation...
You can also e-mail stuff to att...@cisco.com as long as the case (C3) number is in the subject line. - Jared On Feb 3, 2014, at 10:30 AM, David White, Jr. (dwhitejr) dwhit...@cisco.com wrote: Hi Chris / All, Thanks for alerting us to this problem. The Support Case Manager team put a fix (we hope) in this weekend. Glad it is now working for you. Sincerely, David. On 2/3/2014 10:12 AM, Chris Marget wrote: On Sat, Feb 1, 2014 at 12:41 PM, Chris Marget ch...@marget.com wrote: I tried two operating systems and four browsers yesterday. I couldn't upload files that were just a few hundred KB. That was on Friday. Nothing has changed on my end (hardware/software/network), but I'm able to upload files just fine today. ___ cisco-nsp 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] PIM and network redundancy
Hi I have project where network looks like this: IPTV source | 7600_1 | | | | 7600_2| | | | | 7600_3- | IPTV distribution switches (~20 VLANs) I'm currently using PIM static joins on first 7600 next to the source and classic PIM spare-mode (ip pim spare-mode) sessions between rest 7600 and 'pim passive' from 7600 to IPTV distribution switches. First 7600 is my RP. My question is how I can provide redundancy in this network. I had issue, when link between 7600_1 and 7600_2 was down, and traffic switched to link 7600_1--7600_3. IPv4 works without problem as OSPF use backup path. But how deal with PIM and multicasts ? Intergrate MSDP or other protocol ? Any recommendations ? I think about creating xconnect (L2VPN over MPLS) from first 7600_1 to 7600_3 and put additional Cat6500 on the end as PIM box. Rob ___ cisco-nsp 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] PIM and network redundancy
Hi Rob, Did you mean to say you have IGMP static-groups on the 7600_3 to attract multicast traffic toward your distribution switches? If you meant 7600_1 then I'm not sure what your topology is but the redundancy issue made me think of a similar issue I faced in the past. Are you using any static routes (or mroutes) on 7600_3 to the multicast source? I think your multicast trafic must have failed RPF check when the link between 7600_1 and 7600_2 failed. Using show ip mroute count you can maybe check your Other counts counters to confirm this. The RPF failed counter should be high. WS-C6506#show ip mroute 232.32.1.1 10.154.128.58 count IP Multicast Statistics 785 routes using 396312 bytes of memory 362 groups, 1.16 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 232.32.1.1, Source count: 1, Packets forwarded: 630315119, Packets received: 630659870 Source: 10.154.128.58/32, Forwarding: 630315119/393/1344/4230, Other: 630659870/0/344751 PIM is protocol independent and depends on CEF/RIB so if OSPF converges then PIM should converge as well. Hope this helps. Cheers, JF Jean-François Dubé Technicien, Opérations Réseau IP Ingénierie Exploitation des Réseaux Vidéotron cisco-nsp cisco-nsp-boun...@puck.nether.net a écrit sur 2014-02-03 17:39:44 : De : Robert Hass robh...@gmail.com A : cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net, Date : 2014-02-03 17:47 Objet : [c-nsp] PIM and network redundancy Envoyé par : cisco-nsp cisco-nsp-boun...@puck.nether.net Hi I have project where network looks like this: IPTV source | 7600_1 | | | | 7600_2| | | | | 7600_3- | IPTV distribution switches (~20 VLANs) I'm currently using PIM static joins on first 7600 next to the source and classic PIM spare-mode (ip pim spare-mode) sessions between rest 7600 and 'pim passive' from 7600 to IPTV distribution switches. First 7600 is my RP. My question is how I can provide redundancy in this network. I had issue, when link between 7600_1 and 7600_2 was down, and traffic switched to link 7600_1--7600_3. IPv4 works without problem as OSPF use backup path. But how deal with PIM and multicasts ? Intergrate MSDP or other protocol ? Any recommendations ? I think about creating xconnect (L2VPN over MPLS) from first 7600_1 to 7600_3 and put additional Cat6500 on the end as PIM box. Rob ___ cisco-nsp 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] IOS-XR: 6PE - next-hop manipulation in route-policy.
Hi, For IPv4 we ended up manipulating the next hops on the outbound policy from the RRs (in XR). There is one magic switch under the bgp config that you have to enable for the outbound manipulations to work: bgp ibgp policy out enforce-modifications kind regards Pshem On 4 February 2014 04:17, Jonathan Hart johathan.h...@gmail.com wrote: Hi list, I am trying to manipulate the next-hop for community-tagged routes, inbound on a 6PE router. Routes are received from route-reflectors, and should be treated inbound. In this specific scenario I am trying to change a next-hop. The configuration is based on what we have in production on IOS today, where this works just fine. PE is ASR9000 running IOS-XR 4.3.2. My configuration; Non-essential configuration has been omitted. router static address-family ipv6 unicast 2001:db8::160/128 Null0 :::192.168.0.1/128 Null0 router bgp asn neighbor-group IPv6RR address-family ipv6 labeled-unicast route-policy rr-edge-in in route-policy rr-edge-in if community matches-any (1000:6) and destination in (::/0 ge 64) then set next-hop 2001:db8::160 endif pass end-policy Also tried this.. route-policy rr-edge-in if community matches-any (1000:6) and destination in (::/0 ge 64) then set next-hop :::192.168.0.1 endif pass end-policy The defined policy is processing the routes. I tried swapping the next-hop statement for a simple drop, and the prefix was dropped. In IOS, I use an IPv6 next-hop which works just fine. In IOS-XR, I tried with both a normal IPv6 unicast address, and with IPv4-mapped address - without success. I am sure there is a reasonable explanation for this, and I have a feeling it lies in the 6PE part of the next-hop magic. As it seems to be working just fine in IOS, I'm fairly confident it should be possible to do in XR as well. Any help is appreciated! ___ cisco-nsp 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] Transparent WAN Encryption
On 4 Feb 2014, at 10:30 am, Benny Amorsen benny+use...@amorsen.dk wrote: Does that actually work over WAN links that are not just plain optical paths? I have been wondering if you can get MacSec to work over EoMPLS. It ‘just worked’ in the lab over EoMPLS, but I haven’t experienced it in production. ___ cisco-nsp 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] Transparent WAN Encryption
Ian Henderson i...@ianh.net.au writes: What about MacSec? Works between 3560X/4500/4500X/Sup2T/etc for wire rate L2 encryption. http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/15.1/XE_330SG/configuration/guide/swmacsec.html#wp1334072 says: Does that actually work over WAN links that are not just plain optical paths? I have been wondering if you can get MacSec to work over EoMPLS. VPLS seems unlikely, as MacSec seems to be point-to-point. /Benny ___ cisco-nsp 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] 4900M / ME3600 / 4500X
Hi everyone, Quick question(s) on the above switches. Is the 4500X just an improved version of the 4900M, or does the 4900M have other metro-e features over the 4500X? For mpls support, the only option would be the ME3600? (i.e. If wanting to do L3VPN's+VPLS at the access) Cheers. ___ cisco-nsp 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] Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever)
On Monday, February 3, 2014, Jared Mauch ja...@puck.nether.net wrote: On Feb 2, 2014, at 9:35 PM, Jeff Kell jeff-k...@utc.edu javascript:; wrote: Still somewhat of a mystery, as there is no proper twinax standard like there is with 10G-SR, LR, LRM, ER, etc. Just picking one at random from google.. http://www.cdw.com/shop/products/Proline-Force10-CBL-10GSFP-DAC-5M-Compatible-5M-PASSIVE-TWINAX-SFP-Cable/2785340.aspx One can get 2x10G SR optics + om3 mmf for lower cost than the above cable. - Jared Or you can use a china supplier like sfpcables.com instead and not overpay. -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler ___ cisco-nsp 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] Transparent WAN Encryption
I've been working with MACsec over the last two weeks as a cheaper way to get some encryption in place over some lit paths. In our case I also manage the transport gear. I had to change a frame disposition setting on our transport gear because, by default, the Ethertype for the initial EAPOL exchange, 0x888E, was filtered out. MACsec content has a 0x88E5 Ethertype. It still didn't work, but our transport vendor identified the issue as a bug already fixed that in a future newer release, and they were able to patch the problem. So if you run the traffic through transport gear that handles those two Ethertypes, MACsec should run fine. Regards, Frank -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Benny Amorsen Sent: Monday, February 03, 2014 5:31 PM To: Ian Henderson Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Transparent WAN Encryption Ian Henderson i...@ianh.net.au writes: What about MacSec? Works between 3560X/4500/4500X/Sup2T/etc for wire rate L2 encryption. http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/15.1/XE_330SG/conf iguration/guide/swmacsec.html#wp1334072 says: Does that actually work over WAN links that are not just plain optical paths? I have been wondering if you can get MacSec to work over EoMPLS. VPLS seems unlikely, as MacSec seems to be point-to-point. /Benny ___ cisco-nsp 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/
