Re: [c-nsp] vlan shaping
me3600x/me3800x Thanks Darren http://www.mellowd.co.uk/ccie From: cisconsp_l...@hotmail.com To: cisco-nsp@puck.nether.net Date: Wed, 9 Oct 2013 15:43:20 +1100 Subject: [c-nsp] vlan shaping Hi Everyone - ME3400's appear to not support (easily) per vlan shaping - What (switch) platform does have this functionality? Thanks. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Stable IOS 15.x version for 7600
Hi all, I'm looking for a stable IOS version for a 7600 with RSP720. Every IOS in the 15.x range is either ED or MD. To all out there with 15.x on a 7600, what do you recommend ? Kind regards, 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] MPBGP, CEF drops and upgrade from 12.4.4 to 12.4.24
On Tue, 2013-10-08 at 16:04 -0600, Karl Putland wrote: Well... so it works in 12.4.4 but not 12.4.24 as configured. It's a change alright but it seems semi-logical to me that the router drops packets with an Unresolved route reason given what you describe. :-) I had wanted to use the global instead of specifying an interface. I don't remember the train of thought for that right now as the config has been in place for over a year. You should still be able to use the global. You just need to change the next hops. For the connected destination: ip route vrf VOIP 172.16.119.178 255.255.255.255 172.16.119.178 global name TEST_7206_1oc ^ And the other can use this recursively: ^ ip route vrf VOIP 172.16.119.130 255.255.255.255 172.16.119.178 global name dlab-irvine-1 ^ Would that mess something else up? ^ I also wanted to avoid putting any static routes in the Customer VRFs and instead use MPBGP to import the routes from vrf VOIP. So that I could maintain all of the routes to be shared in a single table. Resource wise it's the same. Management wise your suggestion is probably a little better but keep in mind that only exact prefixes can be imported. So if you need to import a /32 prefix it needs to exist as exactly /32 in the source VRF. If your goal is the make things work on 12.4(4) IOS 15.2(4) then that should be possible. -- 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] vlan shaping
Thanks Darren - So massive jump in price to support this feature? From: darre...@outlook.com To: cisconsp_l...@hotmail.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] vlan shaping Date: Wed, 9 Oct 2013 07:42:06 +0100 me3600x/me3800x Thanks Darren http://www.mellowd.co.uk/ccie From: cisconsp_l...@hotmail.com To: cisco-nsp@puck.nether.net Date: Wed, 9 Oct 2013 15:43:20 +1100 Subject: [c-nsp] vlan shaping Hi Everyone - ME3400's appear to not support (easily) per vlan shaping - What (switch) platform does have this functionality? Thanks. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Possible causes for fiber link flap?
We're scratching our heads regarding some strange link-flapping. We have a ~3 km run (no underground vaults before a recent accident) over which we run 10G-LR. It has worked without problems for a couple of months. A few weeks ago someone pushed a sharpened wooden pole down through the plastic conduit around halfway between the end points and damaged the fiber. All fibers were spliced in a new vault and OTDR showed nothing wrong afterwards. We can see the loss/reflection from the splice but it's well within tolerances. The total link loss (according to DOM) is 0.6 dB in one direction and 2.4 dB in the other direction. Budget should be at least around 8 dB. Since the fiber was repaired we're seeing quite frequent (dozens a day) link flaps. Only one end actually registers link down, the other end just sees the ISIS adjacency flapping. (See logs further down.) The end that registers link down also sees a few input errors (FCS+symbol) We tried changing the optics (third party, but we have had no problems with them previously) and patch cords and tried using another fiber pair in the run (in a different tube in this 96 strand run). Everything has been clean many times over. Nothing has helped. The only thing we haven't tried is using another physical container port since we don't have any available at the moment. :-( One end is Sup720 + 6708 running 12.2(33)SXJ3 AIS, the other is Sup2T + 6904 running 15.1(1)SY1. The latter, ROUTER-B in the logs, is the one that sees link down. We have two 8G FC links running without problems (on MDS equipment) on other fibers in the same tube. We're contemplating swapping with one of these to see if the problem follows the fiber or the equipment. What could the cause be and how can we investigate? Regular OTDR shows no problems, but can it see polarisation and/or chromatic dispersion? And are those relevant on such a short run (3km)? Logs follow; ISIS runs on Vlan2294 and the physical interfaces are trunks to carry some inter-DC VLANs. Oct 9 10:30:29.220 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet9/8, changed state to down Oct 9 10:30:29.228 CEST: %LINK-3-UPDOWN: Interface Vlan2294, changed state to down Oct 9 10:30:29.228 CEST: %PIM-5-NBRCHG: neighbor 192.0.2.253 DOWN on interface Vlan2294 non DR Oct 9 10:30:29.228 CEST: %CLNS-5-ADJCHANGE: ISIS: Adjacency to ROUTER-A (Vlan2294) Down, interface deleted(non-iih) Oct 9 10:30:29.228 CEST: %CLNS-5-ADJCHANGE: ISIS: Adjacency to ROUTER-A (Vlan2294) Down, interface deleted(non-iih) Oct 9 10:30:29.276 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2294, changed state to down Oct 9 10:30:29.276 CEST: %LINK-3-UPDOWN: Interface TenGigabitEthernet9/8, changed state to down Oct 9 10:30:29.280 CEST: %LDP-5-SP: 198.51.100.4:0: session hold up initiated Oct 9 10:30:31.056 CEST: %LINK-3-UPDOWN: Interface TenGigabitEthernet9/8, changed state to up Oct 9 10:30:31.060 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet9/8, changed state to up Oct 9 10:30:32.068 CEST: %LINK-3-UPDOWN: Interface Vlan2294, changed state to up Oct 9 10:30:32.068 CEST: %PIM-5-NBRCHG: neighbor 192.0.2.253 UP on interface Vlan2294 Oct 9 10:30:32.072 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2294, changed state to up Oct 9 10:30:33.528 CEST: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 192.0.2.254 on interface Vlan2294 Oct 9 10:30:34.560 CEST: %LDP-5-SP: 198.51.100.4:0: session recovery succeeded Oct 9 10:30:34.576 CEST: %CLNS-5-ADJCHANGE: ISIS: Adjacency to ROUTER-A (Vlan2294) Up, new adjacency Oct 9 10:30:30.105 CEST: %CLNS-5-ADJCHANGE: ISIS: Adjacency to ROUTER-B (Vlan2294) Down, hold time expired Oct 9 10:30:34.545 CEST: %CLNS-5-ADJCHANGE: ISIS: Adjacency to ROUTER-B (Vlan2294) Up, new adjacency -- 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] Possible causes for fiber link flap?
2.4dB on a 3km link maybe well in your budget but its way to high for a 3km link. Must be something wrong with the splice. Swapping fibers seems a logic first step to narrow this down. Kind regards, Erik - Oorspronkelijk bericht - Van: Peter Rathlev pe...@rathlev.dk Aan: cisco-nsp cisco-nsp@puck.nether.net Verzonden: Woensdag 9 oktober 2013 11:31:08 Onderwerp: [c-nsp] Possible causes for fiber link flap? We're scratching our heads regarding some strange link-flapping. We have a ~3 km run (no underground vaults before a recent accident) over which we run 10G-LR. It has worked without problems for a couple of months. A few weeks ago someone pushed a sharpened wooden pole down through the plastic conduit around halfway between the end points and damaged the fiber. All fibers were spliced in a new vault and OTDR showed nothing wrong afterwards. We can see the loss/reflection from the splice but it's well within tolerances. The total link loss (according to DOM) is 0.6 dB in one direction and 2.4 dB in the other direction. Budget should be at least around 8 dB. Since the fiber was repaired we're seeing quite frequent (dozens a day) link flaps. Only one end actually registers link down, the other end just sees the ISIS adjacency flapping. (See logs further down.) The end that registers link down also sees a few input errors (FCS+symbol) We tried changing the optics (third party, but we have had no problems with them previously) and patch cords and tried using another fiber pair in the run (in a different tube in this 96 strand run). Everything has been clean many times over. Nothing has helped. The only thing we haven't tried is using another physical container port since we don't have any available at the moment. :-( One end is Sup720 + 6708 running 12.2(33)SXJ3 AIS, the other is Sup2T + 6904 running 15.1(1)SY1. The latter, ROUTER-B in the logs, is the one that sees link down. We have two 8G FC links running without problems (on MDS equipment) on other fibers in the same tube. We're contemplating swapping with one of these to see if the problem follows the fiber or the equipment. What could the cause be and how can we investigate? Regular OTDR shows no problems, but can it see polarisation and/or chromatic dispersion? And are those relevant on such a short run (3km)? Logs follow; ISIS runs on Vlan2294 and the physical interfaces are trunks to carry some inter-DC VLANs. Oct 9 10:30:29.220 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet9/8, changed state to down Oct 9 10:30:29.228 CEST: %LINK-3-UPDOWN: Interface Vlan2294, changed state to down Oct 9 10:30:29.228 CEST: %PIM-5-NBRCHG: neighbor 192.0.2.253 DOWN on interface Vlan2294 non DR Oct 9 10:30:29.228 CEST: %CLNS-5-ADJCHANGE: ISIS: Adjacency to ROUTER-A (Vlan2294) Down, interface deleted(non-iih) Oct 9 10:30:29.228 CEST: %CLNS-5-ADJCHANGE: ISIS: Adjacency to ROUTER-A (Vlan2294) Down, interface deleted(non-iih) Oct 9 10:30:29.276 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2294, changed state to down Oct 9 10:30:29.276 CEST: %LINK-3-UPDOWN: Interface TenGigabitEthernet9/8, changed state to down Oct 9 10:30:29.280 CEST: %LDP-5-SP: 198.51.100.4:0: session hold up initiated Oct 9 10:30:31.056 CEST: %LINK-3-UPDOWN: Interface TenGigabitEthernet9/8, changed state to up Oct 9 10:30:31.060 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet9/8, changed state to up Oct 9 10:30:32.068 CEST: %LINK-3-UPDOWN: Interface Vlan2294, changed state to up Oct 9 10:30:32.068 CEST: %PIM-5-NBRCHG: neighbor 192.0.2.253 UP on interface Vlan2294 Oct 9 10:30:32.072 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2294, changed state to up Oct 9 10:30:33.528 CEST: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 192.0.2.254 on interface Vlan2294 Oct 9 10:30:34.560 CEST: %LDP-5-SP: 198.51.100.4:0: session recovery succeeded Oct 9 10:30:34.576 CEST: %CLNS-5-ADJCHANGE: ISIS: Adjacency to ROUTER-A (Vlan2294) Up, new adjacency Oct 9 10:30:30.105 CEST: %CLNS-5-ADJCHANGE: ISIS: Adjacency to ROUTER-B (Vlan2294) Down, hold time expired Oct 9 10:30:34.545 CEST: %CLNS-5-ADJCHANGE: ISIS: Adjacency to ROUTER-B (Vlan2294) Up, new adjacency -- 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/ ___ cisco-nsp 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] vlan shaping
On Wednesday, October 09, 2013 11:15:58 AM CiscoNSP List wrote: Thanks Darren - So massive jump in price to support this feature? The ME3600X/3800X are the future of Cisco's Metro-E portfolio. Those boxes have the hardware that previous boxes didn't to do many of the things service providers in Metro-E deployments. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp 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] Stable IOS 15.x version for 7600
On Wednesday, October 09, 2013 08:52:04 AM Rob Timmermans wrote: I'm looking for a stable IOS version for a 7600 with RSP720. Every IOS in the 15.x range is either ED or MD. To all out there with 15.x on a 7600, what do you recommend ? The MD releases. can be considered akin to the old GD releases. This is probably as stable as you will get. Much of the code on this platform is ED, however, and tends to have the cool features. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp 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] Possible causes for fiber link flap?
On Wed, 2013-10-09 at 11:31 +0200, Peter Rathlev wrote: All fibers were spliced in a new vault and OTDR showed nothing wrong afterwards. We can see the loss/reflection from the splice but it's well within tolerances. The total link loss (according to DOM) is 0.6 dB in one direction and 2.4 dB in the other direction. Budget should be at least around 8 dB. Several people on and off list points out the 2.4 dB loss is in itself strange even though it's within the budget. That points towards bad splices. Another interesting point is that the link flaps are not completely random. It depends on time of day and from cursory inspection it looks correlated with when many cars are driving near the area where the splices are made. This could lend itself to this being a fiber problem. Only thing that bothers us is that two different pairs in two different tubes (pairs 1,2 and 43,44) exhibit the exact same symptoms. Which led us to believe that it was unrelated to the fiber itself. -- 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] Possible causes for fiber link flap?
On 09/10/2013 13:31, Peter Rathlev wrote: Another interesting point is that the link flaps are not completely random. It depends on time of day and from cursory inspection it looks correlated with when many cars are driving near the area where the splices are made. This could lend itself to this being a fiber problem. interesting data point. You could drive a car or a light truck over the area where the splices were made at some quiet time of the day, so you can measure whether this has any effect on link stability. Whatever the exact cause, it looks like the civil engineering works may have been handled badly for this repair. 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/
Re: [c-nsp] Possible causes for fiber link flap?
On 09/10/13 10:31, Peter Rathlev wrote: within tolerances. The total link loss (according to DOM) is 0.6 dB in one direction and 2.4 dB in the other direction. Budget should be at least around 8 dB. As others have suggested, this seems like a bad fix to me. How sure of the OTDR trace are you? There could be a micro-bend; we've seen similar things where long fibre runs get fiddled with at some mid-point, and are then very sensitive to physical movement (as the nudge puts the micro-bend over the edge). Or just a plain bad splice! ___ cisco-nsp 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] Possible causes for fiber link flap?
On 09/10/13 10:47, Erik Klaassen wrote: 2.4dB on a 3km link maybe well in your budget but its way to high for a 3km link. True, however note he cited loss figures from DOM, which may be imprecise. That said, I agree such an asymmetry suggests a problem. ___ cisco-nsp 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] Rosen-Draft mvpn Data-tree selection fail XR 4.2.3
Hi folks, I've been used to the convenience of being able to select exactly which groups will use which data tree like below IOS cfg snip. mdt data 232.1.0.0 0.0.0.0 mdt data 232.1.0.1 0.0.0.0 list AL_IPTV_BASIC mdt data 232.1.0.2 0.0.0.0 list AL_IPTV_LOCAL1 And I have just found out it's not possible in XR 4.2.3. Since it'll allow me to enter only a single mdt data range per VRF. Either restricted with an ACL or not (if I enter more only the last one survives the commit operation). In case the range is restricted by an ACL the rest of the groups (groups not matching the ACL) will use the default tree according to the doc. Can anyone please confirm whether this restriction applies in 4.3 as well? 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/
Re: [c-nsp] Stable IOS 15.x version for 7600
15.2.4S4 is considered a Safe Harbor release for 15S, but you might want to wait a week or two for 15.24S4a to come out (roughly scheduled) On Wed, Oct 9, 2013 at 7:48 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Wednesday, October 09, 2013 08:52:04 AM Rob Timmermans wrote: I'm looking for a stable IOS version for a 7600 with RSP720. Every IOS in the 15.x range is either ED or MD. To all out there with 15.x on a 7600, what do you recommend ? The MD releases. can be considered akin to the old GD releases. This is probably as stable as you will get. Much of the code on this platform is ED, however, and tends to have the cool features. 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/ ___ cisco-nsp 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] DMVPN/mGRE on L3VPN - anyone experience issues with encapsulation overhead/MTU?
Hey, all. I'm looking at an option to consolidate and reduce complexity of a multi-provider L3VPN network in a way that lets me also use internet-based VPNs for backup. Right now I have dual provider uplinks at all of my sites to provide me inter-office WAN connectivity. DMVPN is a nice and easy option where I can have everything run in a single routing domain, drasticially simplifying my network topology. Has anyone experience with a network running in such a design? I am concerned about increased latency, and worse, packet overhead. I'm not sure I'll be able to get jumbos on these providers, so I'll have to deal with ipsec/gre overhead. I don't do anything crazy blocking with ICMP, but I'm still hesitant to move forward with such a design. -JP Senior The contents of this message may contain confidential and/or privileged subject matter. If this message has been received in error, please contact the sender and delete all copies. Like other forms of communication, e-mail communications may be vulnerable to interception by unauthorized parties. If you do not wish us to communicate with you by e-mail, please notify us at your earliest convenience. In the absence of such notification, your consent is assumed. Should you choose to allow us to communicate by e-mail, we will not take any additional security measures (such as encryption) unless specifically requested. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco Security Advisory: Multiple Vulnerabilities in Cisco ASA Software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Cisco Security Advisory: Multiple Vulnerabilities in Cisco ASA Software Advisory ID: cisco-sa-20131009-asa Revision 1.0 For Public Release 2013 October 9 16:00 UTC (GMT) +- Summary === Cisco Adaptive Security Appliance (ASA) Software is affected by the following vulnerabilities: IPsec VPN Crafted ICMP Packet Denial of Service Vulnerability SQL*Net Inspection Engine Denial of Service Vulnerability Digital Certificate Authentication Bypass Vulnerability Remote Access VPN Authentication Bypass Vulnerability Digital Certificate HTTP Authentication Bypass Vulnerability HTTP Deep Packet Inspection Denial of Service Vulnerability DNS Inspection Denial of Service Vulnerability AnyConnect SSL VPN Memory Exhaustion Denial of Service Vulnerability Clientless SSL VPN Denial of Service Vulnerability These vulnerabilities are independent of one other; a release that is affected by one of the vulnerabilities may not be affected by the others. Successful exploitation of the IPsec VPN Crafted ICMP Packet Denial of Service Vulnerability, SQL*Net Inspection Engine Denial of Service Vulnerability, HTTP Deep Packet Inspection Denial of Service Vulnerability, DNS Inspection Denial of Service Vulnerability, and Clientless SSL VPN Denial of Service Vulnerability may result in a reload of an affected device, leading to a denial of service (DoS) condition. Successful exploitation of the Digital Certificate Authentication Bypass Vulnerability, Remote Access VPN Authentication Bypass Vulnerability, and Digital Certificate HTTP Authentication Bypass Vulnerability may result in an authentication bypass, which could allow the attacker access to the inside network via remote access VPN or management access to the affected system via the Cisco Adaptive Security Device Management (ASDM). Successful exploitation of the AnyConnect SSL VPN Memory Exhaustion Denial of Service Vulnerability may exhaust available memory, which could result in general system instability and cause the affected system to become unresponsive and stop forwarding traffic. Cisco has released free software updates that address these vulnerabilities. Workarounds are available for some of the vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20131009-asa Note: The Cisco Firewall Services Module (FWSM) for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers may be affected by the SQL*Net Inspection Engine Denial of Service Vulnerability. A separate Cisco Security Advisory has been published to disclose the vulnerabilities that affect the Cisco FWSM. This advisory is available at: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20131009-fwsm -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iF4EAREKAAYFAlJVVn0ACgkQUddfH3/BbTqWZwD/RwBC6JBngB+veDwlJnE/f0JZ iuuIjMkJNw/hIWUZBSgA+gMaBfPY40K8ORrja7Tf9cuThC8QxjtRmX/Rkj3Rx2P3 =9LM3 -END 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/
[c-nsp] Cisco Security Advisory: Multiple Vulnerabilities in Cisco Firewall Services Module Software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Cisco Security Advisory: Multiple Vulnerabilities in Cisco Firewall Services Module Software Advisory ID: cisco-sa-20131009-fwsm Revision 1.0 For Public Release 2013 October 9 16:00 UTC (GMT) +- Summary === Cisco Firewall Services Module (FWSM) Software for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers is affected by the following vulnerabilities: Cisco FWSM Command Authorization Vulnerability SQL*Net Inspection Engine Denial of Service Vulnerability These vulnerabilities are independent of each other; a release that is affected by one of the vulnerabilities may not be affected by the other. Successful exploitation of the Cisco FWSM Command Authorization Vulnerability may result in a complete compromise of the confidentiality, integrity and availability of the affected system. Successful exploitation of the SQL*Net Inspection Engine Denial of Service Vulnerability may result in a reload of an affected device, leading to a denial of service (DoS) condition. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate these vulnerabilities are available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20131009-fwsm Note: The Cisco Adaptive Security Appliance (ASA) may be affected by the SQL*Net Inspection Engine Denial of Service Vulnerability. A separate Cisco Security Advisory has been published to disclose the vulnerabilities that affect the Cisco ASA. That advisory is available at: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20131009-asa -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iF4EAREKAAYFAlJVVngACgkQUddfH3/BbTqEHwD+MG4AnaGKJkTqhajTCmuZMSwC q8zMqwatIzdi3sisKJcA/28pIwT+I0BapJppueqTvMKvVfxA0X78/dgGkY82Jdgp =TW/T -END 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/
[c-nsp] Online Insertion and Removal effect on Spanningtree ?
Does anyone know if OIR has any effect on Spanning Tree ? I know it stops the BUS briefly but thats it. We had to remove a mod that had nothing connected but did still have config, and we experienced many STP log messages relating to ROOT change from other connect switches. I could not find any doc stating OIR has any effect on STP. Any ideas or experience with same issue? 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/
[c-nsp] Arbor Networks 9th Annual Infrastructure Security Survey
___ Arbor Networks 9th Annual Infrastructure Security Survey Now Open ___ Arbor Networks would like to invite you to participate in our annual infrastructure security survey, an important initiative that touches service providers, enterprises, government agencies, universities and other network operators around the world. Please go here to participate in the 2013 survey: https://www.surveymonkey.com/s/FGY6KJD We are requesting that you complete and submit the survey by October 31, 2013. The purpose of the survey is to gauge and report on general security issues, practices, procedures and observations from the industry. All data gathered from the survey will be compiled, analyzed and reported in Arbor's 9th annual Worldwide Infrastructure Security Report which will be published in early 2014. Individual responses will be treated anonymously and no respondent names or company names will appear in the report or accompanying presentations and/or marketing materials. For your reference, our 8th annual Worldwide Infrastructure Security Report, issued earlier this year and based on responses to last year's survey is available here: http://pages.arbornetworks.com/rs/arbor/images/WISR2012_EN.pdf Your industry perspectives are important to Arbor and we value your input. Thank you, in advance, for your participation. With best regards, Arbor Networks ___ cisco-nsp 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] DMVPN/mGRE on L3VPN - anyone experience issues with encapsulation overhead/MTU?
People do this all the time: GRE/IPSEC back up to MPLS VPN. Lots of service providers have managed service that does this for you. With modern hardware, fragmentation shouldn't be a big deal. Most providers have end to end jumbo frame so just need to be mindful of who does and who don't. Good luck. On Wed, Oct 9, 2013 at 11:30 AM, JP Senior seni...@bennettjones.com wrote: Hey, all. I'm looking at an option to consolidate and reduce complexity of a multi-provider L3VPN network in a way that lets me also use internet-based VPNs for backup. Right now I have dual provider uplinks at all of my sites to provide me inter-office WAN connectivity. DMVPN is a nice and easy option where I can have everything run in a single routing domain, drasticially simplifying my network topology. Has anyone experience with a network running in such a design? I am concerned about increased latency, and worse, packet overhead. I'm not sure I'll be able to get jumbos on these providers, so I'll have to deal with ipsec/gre overhead. I don't do anything crazy blocking with ICMP, but I'm still hesitant to move forward with such a design. -JP Senior The contents of this message may contain confidential and/or privileged subject matter. If this message has been received in error, please contact the sender and delete all copies. Like other forms of communication, e-mail communications may be vulnerable to interception by unauthorized parties. If you do not wish us to communicate with you by e-mail, please notify us at your earliest convenience. In the absence of such notification, your consent is assumed. Should you choose to allow us to communicate by e-mail, we will not take any additional security measures (such as encryption) unless specifically requested. ___ cisco-nsp 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] DMVPN/mGRE on L3VPN - anyone experience issues with encapsulation overhead/MTU?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JP Senior wrote: Hey, all. I'm looking at an option to consolidate and reduce complexity of a multi-provider L3VPN network in a way that lets me also use internet-based VPNs for backup. Right now I have dual provider uplinks at all of my sites to provide me inter-office WAN connectivity. DMVPN is a nice and easy option where I can have everything run in a single routing domain, drasticially simplifying my network topology. Has anyone experience with a network running in such a design? I am concerned about increased latency, and worse, packet overhead. I'm not sure I'll be able to get jumbos on these providers, so I'll have to deal with ipsec/gre overhead. I don't do anything crazy blocking with ICMP, but I'm still hesitant to move forward with such a design. -JP Senior I have customers who run DMVPN over both L3VPN and Internet as the substrate so that they have consistency in the design and architecture. There can be MTU issues, but that varies by provider. Otherwise, it works great for them. - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJVmAgACgkQE1XcgMgrtya7fQCdGzGb2iQToBCidejusDRQugh8 G/cAnA1ZOaATEI//2+mXlkW09GVwiEzE =g7Eb -END 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] DMVPN/mGRE on L3VPN - anyone experience issues with encapsulation overhead/MTU?
I run a similar topology. On the tunnel interfaces I have ip tcp adjust-mss 1452 and tunnel path-mtu-discovery. No problems encountered; though the traffic profile is basic remote office file and print. On Wed, Oct 9, 2013 at 9:30 AM, JP Senior seni...@bennettjones.com wrote: Hey, all. I'm looking at an option to consolidate and reduce complexity of a multi-provider L3VPN network in a way that lets me also use internet-based VPNs for backup. Right now I have dual provider uplinks at all of my sites to provide me inter-office WAN connectivity. DMVPN is a nice and easy option where I can have everything run in a single routing domain, drasticially simplifying my network topology. Has anyone experience with a network running in such a design? I am concerned about increased latency, and worse, packet overhead. I'm not sure I'll be able to get jumbos on these providers, so I'll have to deal with ipsec/gre overhead. I don't do anything crazy blocking with ICMP, but I'm still hesitant to move forward with such a design. -JP Senior The contents of this message may contain confidential and/or privileged subject matter. If this message has been received in error, please contact the sender and delete all copies. Like other forms of communication, e-mail communications may be vulnerable to interception by unauthorized parties. If you do not wish us to communicate with you by e-mail, please notify us at your earliest convenience. In the absence of such notification, your consent is assumed. Should you choose to allow us to communicate by e-mail, we will not take any additional security measures (such as encryption) unless specifically requested. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Alex Presse How much net work could a network work if a network could net work? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco ASA 8.4.7
Hi folks, With the newest advisory for the ASA: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20131009-asa We are thinking of going uniform with Cisco ASA 8.4.7. Looking at the Resolved Caveats, lots of them got fixed: http://www.cisco.com/en/US/docs/security/asa/asa84/release/notes/asarn84.html#wp631223 Has anyone been running 8.4.7 with good success? I am just looking for minimal NAT, mostly Remote Access VPN and a few hundred site to site VPN. Thanks. -Luan ___ cisco-nsp 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 ASA 8.4.7
We were running 8.4.6 for a while, but have been having good luck so far with 8.4.7 as well. -ryan -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Luan Nguyen Sent: Wednesday, October 09, 2013 3:11 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco ASA 8.4.7 Hi folks, With the newest advisory for the ASA: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20131009-asa We are thinking of going uniform with Cisco ASA 8.4.7. Looking at the Resolved Caveats, lots of them got fixed: http://www.cisco.com/en/US/docs/security/asa/asa84/release/notes/asarn84.html#wp631223 Has anyone been running 8.4.7 with good success? I am just looking for minimal NAT, mostly Remote Access VPN and a few hundred site to site VPN. Thanks. -Luan ___ cisco-nsp 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/
