Re: [c-nsp] ASR901 EoMPLS Customer COS bits trashed
Hello Caillin, We have also seen some issues with the ASR901 QoS In fact the config is very restricting at the moment.. What I know for sure is that the ingress cos markings are copied to the MPLS EXP bit, so you can try to remark your customer traffic at the other end George On Wed, Oct 10, 2012 at 7:50 AM, Caillin Bathern caill...@commtelns.comwrote: Hi list, I am seeing some odd behaviour in the lab and I am wondering if anyone else knows why this is happening or any alternative... I have a simple setup - CE---PE(ASR901)---EoMPLS---PE(ASR901)---CE - I also have inline packet capturing devices on all physical links and MPLS explicit null turned on to ensure EXP marking is carried through. A single VLAN (10) in a service instance is been xconnected through on the ASR901s as follows: pseudowire-class eth encapsulation mpls interworking ethernet ! interface GigabitEthernet0/1 service instance 10 ethernet encapsulation dot1q 10 xconnect 6.6.6.6 10 encapsulation mpls pw-class eth ! The CE is a network tester sending VID10 with COS 3, this traffic is received on the remote CE however my COS 3 marking is lost... This behaviour is consistent with tag pop/no tag pop, Ethernet or VLAN interworking, service policies or no service policies. Why are my customer COS markings being destroyed by the ASR901 when within an EoMPLS circuit and is there a way to fix this? Cheers, Caillin ___ 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] Half duplex VRF
Hi Arie, Below is the desired excerpt. We can't see the VRF config being applied to the interfaces but its visible in show ip int virtual-access. I have tried two different way in RADIUS attributes but the results are the same. LNS#show ppp all Interface/ID OPEN+ Nego* Fail- StagePeer AddressPeer Name - --- Vi4 LCP+ CHAP+ IPCP+ LocalT 192.168.254.200 \ sp...@cerberusnetworks.co.uk Vi3 LCP+ CHAP+ IPCP+ LocalT 192.168.254.100 \ m...@cerberusnetworks.co.uk LNS#show run int vir LNS#show run int virtual-acc LNS#show run int virtual-access 3 Building configuration... Current configuration : 78 bytes ! interface Virtual-Access3 ip mtu 1492 ip verify unicast reverse-path end LNS#show run int virtual-access 4 Building configuration... Current configuration : 78 bytes ! interface Virtual-Access4 ip mtu 1492 ip verify unicast reverse-path end = LNS#show ip int virtual-access 3 Virtual-Access3 is up, line protocol is up Interface is unnumbered. Using address of Loopback2 (2.2.2.1) Broadcast address is 255.255.255.255 Peer address is 192.168.254.100 MTU is 1492 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is enabled IP Flow switching is disabled IP CEF switching is enabled IP CEF switching turbo vector IP CEF turbo switching turbo vector VPN Routing/Forwarding U Downstream VPN Routing/Forwarding D Associated unicast routing topologies: ipv4 topologies in downstream VRF D : Topology base, operation state is UP ipv4 topologies in upstream(forwarding) VRF U: Topology base, operation state is UP === Thanks Hitesh On Tue, Oct 9, 2012 at 9:52 PM, Arie Vayner (avayner) avay...@cisco.comwrote: Hitesh, how does your virtual-access look like for the spokes? Can you please share the “show run interface virtual-access xx” for the spokes? ** ** Tnx Arie ** ** *From:* Hitesh Vinzoda [mailto:vinzoda.hit...@gmail.com] *Sent:* Tuesday, October 09, 2012 09:05 *To:* Arie Vayner (avayner) *Cc:* Cisco Mailing list *Subject:* Re: [c-nsp] Half duplex VRF ** ** Hi Arie, ** ** I have attached topology, .Net file and configs of related devices. R8 and R9 are simulating spokes whereas Internet-RTR is simulating Hub. ** ** Cheers ** ** Hitesh On Tue, Oct 9, 2012 at 8:37 PM, Arie Vayner (avayner) avay...@cisco.com wrote: Hitesh, can you maybe share some of your configs? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of Hitesh Vinzoda Sent: Tuesday, October 09, 2012 07:04 To: Cisco Mailing list Subject: [c-nsp] Half duplex VRF I am trying to setup half duplex vrf to save vrf's on the LNS. Does anyone has working configuration for spokes and Hub connected on the same PE router i.e. LNS. So far i able to export-import the routes but the traces from one spoke to other goes directly via LNS instead of via Hub. Please advise. TIA Hitesh ___ 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 archive in addition to RANCID
Il 10/10/2012 2.52, Ian Henderson wrote: * Having two methods ensures that if one method breaks, we still have useful logs/archives. This is particularly nice in our environment I particularly appreciate this design principle. Please consider doing a periodic SCP of important files which are otherwise not backed up: - nvram:ifIndex-table, if you use ifindex persistency - flash:env_vars, for switches (as Matt pointed out) - flash:vlan.dat, if for some unlikely reason you use VTP Rancid does a dir, so you can see (grep, etc) there if these files exist on your switches. Also please take the time to try to restore a device from the backup you have: everybody can do a backup, but only the brave can actually restore. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ 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 archive in addition to RANCID
On 10/10/2012 01:52 AM, Ian Henderson wrote: Hi folks, I'm working on updating our base templates using some more modern features and am considering if IOS' built in configuration archiver/change logger have a place in our network. Is anybody using the config archiver in addition to/in place of RANCID? No, because it's slow on 6500 sup720, which are our primary platform. Of course, that's because NVGEN is slow, but when I tested it, the archive stuff had a few niggles that would occasionally trigger a background NVGEN. Ditto the incremental config stuff - slightly buggy when I tested it, would occasionally pull a full NVGEN for no obvious reason. Syslog command logging in addition to/in place of TACACS? Yes, instead of, because TACACS is mostly inappropriate for our needs. That said - I don't see any reason to ever disable this. syslogging the commands is, at worse, redundant. And it gets you logging if someone has to use the emergency non-TACACS user. Thoughts on pros/cons? Are you using EEM to catch config changes that aren't followed by a 'wr mem'? Nagios check against the config operation MIB to check that the last config operation was a wr mem, with some time delay to allow people 10 minutes to commit. Works on all Cisco platforms AFAIK including NX-OS, but does false-positive immediately after a reload b/c the last operation was a read. Any other neat tricks? sec to tail the router logs at your syslog server and trigger operations only when needed e.g. backups - don't cron them, run one immediately after someone exits config mode, possibly even annotating the SVN checkin with their username. More generally - sec to tail all your router logs. Write a whitelist of don't care syslog messages, and watch the rest like a hawk. It's invaluable. My thoughts so far: * RANCID is a single solution that works for all vendors and all versions of IOS, no need for separate dirty hacks per vendor, but new vendor/device type maintenance can be tricky. * With a sizeable RANCID installation, collection interval needs to be pushed out to 4 hours plus, which means we could miss changes within the interval. Really? We use a home-grown system for this, and back up 1200 devices every hour. I'm confident we could go faster. How sizeable does an install have to be for RANCID to be this slow? Does it do devices in series or something? * RANCID does automated diff, having a directory full of router-datetime files isn't as easy to manipulate. Well, no. Just letting the files accumulate isn't very useful IMO. For what it's worth - in our home-grown config backup system, JunOS devices ftp each config write to a spool directory. The config backup system pulls each write in date order, and commits them to version control individually. Thus, we feed the VC system from the archive spool. * TACACS command logging catches commands performed outside config mode. Yes. It might also be moderately useful to disable really dangerous commands e.g. the switchport trunk allowed vlan X variant, without add or remove. Any additional insight? TBH I'm not really sure what you're asking. Should I use 'archive' instead of RANCID? - erm, no. They serve different purposes. Maybe feed RANCID from the archive spool, but replace - not a chance. Should I use 'archive' instead of TACACS? - I doubt it, for much the same reason. The archive stuff is nice - turn it all on, if you're happy with it - but it's very raw and low level, and doesn't replace mature systems. IIRC RANCID does loads more than just the configs - doesn't it back up inventory and such like via show commands? ___ 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 archive in addition to RANCID
On 10/10/2012, at 8:16 PM, Phil Mayers p.may...@imperial.ac.uk wrote: TBH I'm not really sure what you're asking. Yep, sorry was a bit of a brain dump. :) Thanks for your comments. This basically tells me that archive doesn't have any super awesome features that we don't already get from RANCID, and that its not completely solid yet (re 6500). Syslog command logging though is 100 times more convenient than TACACS for short term requirements, while TACACS+gzip+disk storage sorts out the long term/compliance requirements. Really? We use a home-grown system for this, and back up 1200 devices every hour. At the moment, ~rancid/var lives on NFS, and the machine does a bunch of other things that chew resources. I've got plans on improving this, but one disaster at a time. :) Rgds, - I. ___ 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] Not a valid host address error
Hi all, I want to know in what condition this error occurres when defining ip addresses on interfaces? I test many IP addresses and diverse error messages happens which I don't know the reasons. Is there any reference which I could find the invalid pattern of ip addresses? some of my tests are: Router(config-if)#ip address 172.0.3.2 255.255.255.255 Bad mask /32 for address 172.0.3.2 Router(config-if)#ip address 255.0.3.2 255.255.255.255 Not a valid host address - 255.0.3.2 Router(config-if)#ip address 255.0.3.2 255.255.255.0 Not a valid host address - 255.0.3.2 Router(config-if)#ip address 254.0.3.2 255.255.255.0 Not a valid host address - 254.0.3.2 Router(config-if)#ip address 224.10.3.2 255.255.255.0 Not a valid host address - 224.10.3.2 Router(config-if)#ip address 224.10.3.2 255.0.0.0 Not a valid host address - 224.10.3.2 Router(config-if)#ip address 224.10.3.2 239.0.0.0 Not a valid host address - 224.10.3.2 Router(config-if)#ip address 224.0.0.0 239.0.0.0 Not a valid host address - 224.0.0.0 Router(config-if)#ip address 195.0.0.0 239.0.0.0 Bad mask 0xEF00 for address 195.0.0.0 Router(config-if)#ip address 223.0.0.0 239.0.0.0 Bad mask 0xEF00 for address 223.0.0.0 thanks in advance ___ 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] Not a valid host address error
Hi, On Wed, Oct 10, 2012 at 04:08:03PM +0330, h bagade wrote: I want to know in what condition this error occurres when defining ip addresses on interfaces? I test many IP addresses and diverse error messages happens which I don't know the reasons. Is there any reference which I could find the invalid pattern of ip addresses? networking 101? - don't use IP addresses out of Class D or E space - don't use netmasks that are not left-contiguous (no 0-bits mixed into 1-bits) - don't use /32 masks on anything that's not a loopback - don't use IP addresses that would be the network or broadcast address in a given subnet In essence, except for the non-contiguous netmask thing don't do things that are not permitted by the networking-101 text book. And don't use IPv4 either. 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 pgpSpmJ83JMay.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] IOS archive in addition to RANCID
Wed, Oct 10, 2012 at 10:16:09AM +0100, Phil Mayers: * With a sizeable RANCID installation, collection interval needs to be pushed out to 4 hours plus, which means we could miss changes within the interval. Really? We use a home-grown system for this, and back up 1200 devices every hour. I'm confident we could go faster. How sizeable does an install have to be for RANCID to be this slow? Does it do devices in series or something? at one time we polled 700+ devices hourly on an 450mhz*2 ultrasparc2. clearly, he has configuration issues. ___ 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] Traffic shaping does not work (and is not supported) on Port-Channel interfaces on Software based routers
All, FYI, yet another occurrence of Cisco TAC coming to the conclusion that yes it does not work, and no, they dont have to fix it, because they have decided that it is not supported. Is it an unreasonable expectation to expect product features to interoperate unless clearly stated that they may not? Is it an unreasonable expectation to expect TAC support contracts to deliver results and resolutions instead of yet another thing we wont support? Joe CSCtx75955 Bug Details Shaping does not work on port-channel interfaces on ISR, ISR G2 and 7200 Symptom: Traffic shaping doesn't work on port-channel interfaces and sub-interfaces on software-based routers, such as ISR, ISR G2 or Cisco 7200. Conditions: It was observed in IOS 15.1(4)M3a, but this defect is probably present in all IOS versions. Workaround: None ___ 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] Traffic shaping does not work (and is not supported) on Port-Channel interfaces on Software based routers
Hi, On Wed, Oct 10, 2012 at 10:05:50AM -0400, Joe Maimon wrote: Is it an unreasonable expectation to expect TAC support contracts to deliver results and resolutions instead of yet another thing we wont support? But they *do* deliver results. Documentation gets updated all the time, documenting what features are missing or do not work on rainy tuesdays. gert still pissed about the MPLS static crossconnect thing on SXI -- 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 pgpJm4DIkkOVU.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] Traffic shaping does not work (and is not supported) on Port-Channel interfaces on Software based routers
Gert Doering wrote: Hi, On Wed, Oct 10, 2012 at 10:05:50AM -0400, Joe Maimon wrote: Is it an unreasonable expectation to expect TAC support contracts to deliver results and resolutions instead of yet another thing we wont support? But they *do* deliver results. Documentation gets updated all the time, documenting what features are missing or do not work on rainy tuesdays. gert still pissed about the MPLS static crossconnect thing on SXI Documentation that a feature is wont-fix unsupported dated after the case was opened is inadmissible. Their TAC costs must be absurdly smaller than their engineer costs, the amount of time they waste on this nonsense. Of all things Cisco is good at, pissing of its users ranks #1 on the list. Joe ___ 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] Traffic shaping does not work (and is not supported) on Port-Channel interfaces on Software based routers
Of all things Cisco is good at, pissing of its users ranks #1 on the list. I'm hoping that their move to concentrate on switching and core business rather than eg digital cameras (what were they thinking with that? Did John Chambers ask his PA to buy a flip video and it was misheard?) will start to fix this Alan ___ 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] Traffic shaping does not work (and is not supported) on Port-Channel interfaces on Software based routers
Hi, On Wed, Oct 10, 2012 at 11:10:55AM -0400, Joe Maimon wrote: Of all things Cisco is good at, pissing of its users ranks #1 on the list. *That* seems to be what they really mastered in the last 10 years. (Now what I'm not sure is what the piss-of-customers-BU is competing with, seeems I don't understand the grand master plan yet) 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 pgpLAhXKyjYWf.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/
[c-nsp] 7200 npe-g2 lacp
I can see this platform supports etherchannel, but does it support lacp? I think now, but wanted to check Thanks Darren ___ 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 the Cisco WebEx Recording Format Player
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Multiple Vulnerabilities in the Cisco WebEx Recording Format Player Advisory ID: cisco-sa-20121010-webex Revision 1.0 For Public Release 2012 October 10 16:00 UTC (GMT) - -- Summary === The Cisco WebEx Recording Format (WRF) player contains six buffer overflow vulnerabilities. In some cases, exploitation of the vulnerabilities could allow a remote attacker to execute arbitrary code on the system with the privileges of a targeted user. The Cisco WebEx WRF Player is an application used to play back WRF WebEx meeting recordings that have been recorded on a WebEx meeting site or on the computer of an online meeting attendee. The Cisco WebEx WRF Player can be automatically installed when the user accesses a recording file that is hosted on a WebEx meeting site. The Cisco WebEx WRF Player can also be manually installed for offline playback after downloading the application from: http://www.webex.com/play-webex-recording.html. If the Cisco WebEx WRF Player was automatically installed, it will be automatically upgraded to the latest, nonvulnerable version when users access a recording file that is hosted on a WebEx meeting site. If the Cisco WebEx WRF Player was manually installed, users will need to manually install a new version of the Cisco WebEx WRF Player after downloading the latest version from: http://www.webex.com/play-webex-recording.html. Cisco has updated affected versions of the WebEx meeting sites and Cisco WebEx WRF Player to address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20121010-webex -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlB1h6AACgkQUddfH3/BbTrjWAD/Xo3bSaXFymHXWKgoGNJQTRcp MFilgSgS+0Hp09ncDC0A/R+0E3BmJFwMukJw6IPAQkp+AjYus1naLVDcQMjh7svJ =tuKg -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] MPLS on 6500 VSS - Any major issues?
I'm about to setup MPLS and MPLS VPN on a set of 6500 VSS systems shortly. I was wondering if there are any obvious gotchas that I should be concerned about. We're not doing MPLS-TE or QoS here, pretty straight forward setup. Got this error message configuring BGP for a VRF before 'mpls ip' was even configured and got a little concerned: Oct 9 10:41:50.119: %LFD-SW1_CFC3-6-RESOURCE: MPLS supported in hardware forwarding only Oct 9 10:41:50.123: %LFD-SW2_CFC3-6-RESOURCE: MPLS supported in hardware forwarding only VS-S720 Supervisors, 1 per chassis. SXJ1 Adv IP Services software. WS-X6708-10GE and WS-X6724-SFP line cards. Thanks in advance. MICHAEL DIKKEMA / Senior Technical Specialist - Network / POSTMEDIA.COM ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco Security Advisory: Multiple Vulnerabilities in Cisco Firewall Services Module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Multiple Vulnerabilities in Cisco Firewall Services Module Advisory ID: cisco-sa-20121010-fwsm Revision 1.0 For Public Release 2012 October 10 16:00 UTC (GMT) - -- Summary === The Cisco Firewall Services Module (FWSM) for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers is affected by the following vulnerabilities: DCERPC Inspection Buffer Overflow Vulnerability DCERPC Inspection Denial Of Service Vulnerabilities These vulnerabilities are not interdependent; a release that is affected by one vulnerability is not necessarily affected by the other. Exploitation of these vulnerabilities could allow an unauthenticated, remote attacker to trigger a reload of the affected device, or to execute arbitrary commands. Repeated exploitation could result in a denial of service (DoS) condition. Cisco has released free software updates that address these vulnerabilities. There are no workarounds that mitigate these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20121010-fwsm Note: The Cisco Catalyst 6500 Series ASA Services Module, and the Cisco ASA 5500 Series Adaptive Security Appliance may also be affected by these vulnerabilities. The vulnerabilities affecting the Cisco Catalyst 6500 Series ASA Services Module and Cisco ASA 5500 Series Adaptive Security Appliance have been disclosed in a separate Cisco Security Advisory. The Advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20121010-asa -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlB1h6AACgkQUddfH3/BbTrdbQD/WPf0vA8pJbKyFgfDQ0rol2r4 AAAdCeOQlELptysCaYsBAIZP/vuW1jX43H6pLgx9xBum9wcNBvhzG1m9Bip+nGbH =e0NQ -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 ASA 5500 Series Adaptive Security Appliances and Cisco Catalyst 6500 Series ASA Services Module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Multiple Vulnerabilities in Cisco ASA 5500 Series Adaptive Security Appliances and Cisco Catalyst 6500 Series ASA Services Module Advisory ID: cisco-sa-20121010-asa Revision 1.0 For Public Release 2012 October 10 16:00 UTC (GMT) - -- Summary === Cisco ASA 5500 Series Adaptive Security Appliances (ASA) and Cisco Catalyst 6500 Series ASA Services Module (ASASM) may be affected by the following vulnerabilities: DHCP Memory Allocation Denial of Service Vulnerability SSL VPN Authentication Denial of Service Vulnerability SIP Inspection Media Update Denial of Service Vulnerability DCERPC Inspection Buffer Overflow Vulnerability Two DCERPC Inspection Denial Of Service Vulnerabilities These vulnerabilities are independent of each other; a release that is affected by one of the vulnerabilities may not be affected by the others. Successful exploitation of any of these vulnerabilities could allow an unauthenticated remote attacker to trigger a reload of the affected device. Exploitation of the DCERPC Inspection Buffer Overflow Vulnerability could additionally cause a stack overflow and possibly the execution of arbitrary commands. Cisco has released free software updates that address these vulnerabilities. Workarounds are available for some of these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20121010-asa Note: The Cisco Firewall Services Module for Cisco Catalyst 6500 and Cisco 7600 Series (FWSM) may be affected by some of the vulnerabilities listed above. 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-20121010-fwsm The Cisco ASA 1000V Cloud Firewall and Cisco ASA-CX Context-Aware Security are not affected by any of these vulnerabilities. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlB1jRsACgkQUddfH3/BbTo1RwD+NHNKsAkrc/dZ+XAhDtqAyVIY xaVp6BpwmKAnBbDtwVQA/jXPlWJbmNmSOiHTAI30KkXahf9Bi9+bIvnQyeUI6aUM =Ncu5 -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] Traffic shaping does not work (and is not supported) on Port-Channel interfaces on Software based routers
On Wednesday, October 10, 2012 at 5:21 PM, Gert Doering wrote: (Now what I'm not sure is what the piss-of-customers-BU is competing with, seeems I don't understand the grand master plan yet) JTAC? :P --Daniel. ___ 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] Traffic shaping does not work (and is not supported) on Port-Channel interfaces on Software based routers
On 10/10/12 15:48, Gert Doering wrote: Hi, On Wed, Oct 10, 2012 at 10:05:50AM -0400, Joe Maimon wrote: Is it an unreasonable expectation to expect TAC support contracts to deliver results and resolutions instead of yet another thing we wont support? But they *do* deliver results. Documentation gets updated all the time, documenting what features are missing or do not work on rainy tuesdays. Yes indeed. On *some* occasions, they even: a) Update all extant versions of a doc with a (serious) caveat b) Don't change the last updated time on the doc c) Deny that it's a bug, because see, it's documented We've caught them doing this a couple of times. I think it's a mixture of incompetence and left hand, meet right hand rather than outright lying. But it still INFURIATES me. ___ 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] Half duplex VRF
So basically your PPP connections are in the global routing table... What is the profile you are downloading from RADIUS (debug radius) for them? You most likely should be downloading the ip vrf forwarding U downstream D command using the RADIUS attribute lcp:interface-config=ip vrf forwarding U downstream D... http://www.cisco.com/en/US/docs/ios/12_3/feature/guide/ghdpvrf.html#wp1099907 Arie From: Hitesh Vinzoda [mailto:vinzoda.hit...@gmail.com] Sent: Wednesday, October 10, 2012 00:44 To: Arie Vayner (avayner) Cc: Cisco Mailing list Subject: Re: [c-nsp] Half duplex VRF Hi Arie, Below is the desired excerpt. We can't see the VRF config being applied to the interfaces but its visible in show ip int virtual-access. I have tried two different way in RADIUS attributes but the results are the same. LNS#show ppp all Interface/ID OPEN+ Nego* Fail- StagePeer AddressPeer Name - --- Vi4 LCP+ CHAP+ IPCP+ LocalT 192.168.254.200 \ sp...@cerberusnetworks.co.ukmailto:sp...@cerberusnetworks.co.uk Vi3 LCP+ CHAP+ IPCP+ LocalT 192.168.254.100 \ m...@cerberusnetworks.co.ukmailto:m...@cerberusnetworks.co.uk LNS#show run int vir LNS#show run int virtual-acc LNS#show run int virtual-access 3 Building configuration... Current configuration : 78 bytes ! interface Virtual-Access3 ip mtu 1492 ip verify unicast reverse-path end LNS#show run int virtual-access 4 Building configuration... Current configuration : 78 bytes ! interface Virtual-Access4 ip mtu 1492 ip verify unicast reverse-path end = LNS#show ip int virtual-access 3 Virtual-Access3 is up, line protocol is up Interface is unnumbered. Using address of Loopback2 (2.2.2.1) Broadcast address is 255.255.255.255 Peer address is 192.168.254.100 MTU is 1492 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is enabled IP Flow switching is disabled IP CEF switching is enabled IP CEF switching turbo vector IP CEF turbo switching turbo vector VPN Routing/Forwarding U Downstream VPN Routing/Forwarding D Associated unicast routing topologies: ipv4 topologies in downstream VRF D : Topology base, operation state is UP ipv4 topologies in upstream(forwarding) VRF U: Topology base, operation state is UP === Thanks Hitesh On Tue, Oct 9, 2012 at 9:52 PM, Arie Vayner (avayner) avay...@cisco.commailto:avay...@cisco.com wrote: Hitesh, how does your virtual-access look like for the spokes? Can you please share the show run interface virtual-access xx for the spokes? Tnx Arie From: Hitesh Vinzoda [mailto:vinzoda.hit...@gmail.commailto:vinzoda.hit...@gmail.com] Sent: Tuesday, October 09, 2012 09:05 To: Arie Vayner (avayner) Cc: Cisco Mailing list Subject: Re: [c-nsp] Half duplex VRF Hi Arie, I have attached topology, .Net file and configs of related devices. R8 and R9 are simulating spokes whereas Internet-RTR is simulating Hub. Cheers Hitesh On Tue, Oct 9, 2012 at 8:37 PM, Arie Vayner (avayner) avay...@cisco.commailto:avay...@cisco.com wrote: Hitesh, can you maybe share some of your configs? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Hitesh Vinzoda Sent: Tuesday, October 09, 2012 07:04 To: Cisco Mailing list Subject: [c-nsp] Half duplex VRF I am trying to setup half duplex vrf to save vrf's on the LNS. Does anyone has working configuration for spokes and Hub connected on the same PE router i.e. LNS. So far i able to export-import the routes but the traces from one spoke to other goes directly via LNS instead of via Hub. Please advise. TIA Hitesh ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto: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] %IPC-2-INVALIDZONE: Invalid IPC Zone 0x60000000 on WS-C3750X-24P-S
Anyone else seeing these on 3750X's from time to time? Running 15.0(1)SE3 Oct 9 19:49:25.728 PDT: %IPC-2-INVALIDZONE: Invalid IPC Zone 0x6000. -Traceback= 545BFCz CDDE70z 5AD80z 5AE68z 284DA88z 28478FCz Peter Kranz Founder/CEO - Unwired Ltd http://www.unwiredltd.com/ www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207- mailto:pkr...@unwiredltd.com pkr...@unwiredltd.com ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Clocking for T1's on AS5400 virtually guarantees slips?
Okay, so here's where we stand after working on this for a few days. We have several circuits that are coming into an AS5400 that are getting slips, whereas most of them don't. Most of the circuits come in as T1 channels on a T3. Most of those don't get slips, some do. We also have two t1 circuits for which we have bypassed our mux, so they are T1's that plug into dedicated T1 ports on the AS5400. One gets slips, one doesn't. We can change which lines are getting slips and which ones aren't by changing the tdm clock priority to match one of the lines. Basically, we can bring the backplane clock into sync with one line, it won't get slips, several of the others will. The problem is that I have not found a way to tell all the circuits except the one setting the backplane clock how to set their timing via the clock. T1's on the AS5400 only set clocking to line. You can't tell the T1's to sync to the internal clock. If you could, we could set the clock that way, set the remote end to line, and everything would then be synced to the clocking of the line that was setting the primary TDM clock. If this is true, there is no way to accept t1's from multiple sources in which the clocking may not agree with each other, nor is there any way to provide clocking for an outgoing T1. The AS5400 simply won't work for this, because while it sets the internal clock according to the primary tdm clock circuit, there is no way to tell the other T1's to synchronize according to the internal clock. They are virtually guaranteed to slip. What we want is to be the clock source for all the T1's except for specific trunks we having coming from the phone company. Most specifically it matters for PRI's we are providing to customers. We need to be the clock source because in those cases the phone company simply passes the T1's through without providing any clocking themselves. ___ 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] Clocking for T1's on AS5400 virtually guarantees slips?
I could be smoking crack here so I apologize if I'm wrong but doesn't the local Telco provide clock on all T1s that you can recover? Even in the case where you're providing PRI service doesn't the local loop the carrier provides contain line clocking that you can recover? What am I missing? On Oct 10, 2012, at 3:15 PM, Joseph Mays m...@win.net wrote: Okay, so here's where we stand after working on this for a few days. We have several circuits that are coming into an AS5400 that are getting slips, whereas most of them don't. Most of the circuits come in as T1 channels on a T3. Most of those don't get slips, some do. We also have two t1 circuits for which we have bypassed our mux, so they are T1's that plug into dedicated T1 ports on the AS5400. One gets slips, one doesn't. We can change which lines are getting slips and which ones aren't by changing the tdm clock priority to match one of the lines. Basically, we can bring the backplane clock into sync with one line, it won't get slips, several of the others will. The problem is that I have not found a way to tell all the circuits except the one setting the backplane clock how to set their timing via the clock. T1's on the AS5400 only set clocking to line. You can't tell the T1's to sync to the internal clock. If you could, we could set the clock that way, set the remote end to line, and everything would then be synced to the clocking of the line that was setting the primary TDM clock. If this is true, there is no way to accept t1's from multiple sources in which the clocking may not agree with each other, nor is there any way to provide clocking for an outgoing T1. The AS5400 simply won't work for this, because while it sets the internal clock according to the primary tdm clock circuit, there is no way to tell the other T1's to synchronize according to the internal clock. They are virtually guaranteed to slip. What we want is to be the clock source for all the T1's except for specific trunks we having coming from the phone company. Most specifically it matters for PRI's we are providing to customers. We need to be the clock source because in those cases the phone company simply passes the T1's through without providing any clocking themselves. ATT1.c ___ 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] 7200 npe-g2 lacp
-Ursprüngliche Nachricht- Von: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] Im Auftrag von Darren O'Connor Gesendet: mercredi 10 octobre 2012 17:53 An: cisco-nsp@puck.nether.net Betreff: [c-nsp] 7200 npe-g2 lacp I can see this platform supports etherchannel, but does it support lacp? I think now, but wanted to check Looked at a 7201 c7200p-spservicesk9-mz.122-33.SRE6.bin Configuring an int port-channel 1 and putting the currently unused gig0/3 into channelgroup 1 results in flapping of the mgmt interface fas0/0 (o.k, it's the same controller-chip as for gig0/3): %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to down %SYS-5-CONFIG_I: Configured from console by jm on vty0 %LINK-3-UPDOWN: Interface GigabitEthernet0/3, changed state to down %ENTITY_ALARM-6-INFO: ASSERT CRITICAL Fa0/0 Physical Port Link Down %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to down %LINK-3-UPDOWN: Interface GigabitEthernet0/3, changed state to up %ENTITY_ALARM-6-INFO: CLEAR CRITICAL Fa0/0 Physical Port Link Down GigabitEthernet0/3 added as member-1 to port-channel1 %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to up GigabitEthernet0/3 taken out of port-channel1 %LINK-3-UPDOWN: Interface GigabitEthernet0/3, changed state to down %ENTITY_ALARM-6-INFO: ASSERT CRITICAL Fa0/0 Physical Port Link Down %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to down %LINK-3-UPDOWN: Interface GigabitEthernet0/3, changed state to up %ENTITY_ALARM-6-INFO: CLEAR CRITICAL Fa0/0 Physical Port Link Down %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to up %LINK-5-CHANGED: Interface Port-channel1, changed state to administratively down %SYS-5-CONFIG_I: Configured from console by jm on vty0 Hope the other two CPU Gig Ports do not flap when you configure one of them to go into a port-channel. Ok, yes, I know, the NPE-G2 does not have the Gig0/3 port. Not found any hint on lacp, seems to be a static thing. Hope this help's, Juergen. ___ 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] Not a valid host address error
Thanks all. Thanks Gert for your complete answer. It cleared the vague parts but one still remains! what about ip address like 0.2.3.1 255.255.255.0! what's the rule for this one? On Wed, Oct 10, 2012 at 4:25 PM, Gert Doering g...@greenie.muc.de wrote: Hi, On Wed, Oct 10, 2012 at 04:08:03PM +0330, h bagade wrote: I want to know in what condition this error occurres when defining ip addresses on interfaces? I test many IP addresses and diverse error messages happens which I don't know the reasons. Is there any reference which I could find the invalid pattern of ip addresses? networking 101? - don't use IP addresses out of Class D or E space - don't use netmasks that are not left-contiguous (no 0-bits mixed into 1-bits) - don't use /32 masks on anything that's not a loopback - don't use IP addresses that would be the network or broadcast address in a given subnet In essence, except for the non-contiguous netmask thing don't do things that are not permitted by the networking-101 text book. And don't use IPv4 either. 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-35655025 g...@net.informatik.tu-muenchen.de ___ 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] Change BGP default-originate to IGP?
Thanks for the tips, we'll have a play with some of the options suggested around originating the default. On 05/10/2012, at 11:52 AM, Anton Kapela wrote: also +1 to inter-border router ibgp sessions over some other layer2 path/port pair/etc -- one should always have that, unless you can't for some strange reason. On 27/09/2012, at 11:24 PM, David Prall wrote: As well could put a GRE Tunnel or VLAN between the two ASR's and run iBGP between the two. You control the path between the two routers, so the tunnel can be over a jumbo frame capable path. I'm glad a iBGP session between the ASRs over a GRE tunnel was mentioned, as that's exactly what we have running and I was questioning whether this was a bad practice or not... Thanks, Tom ___ 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] Change BGP default-originate to IGP?
-Original Message- From: Tom Lanyon [mailto:tom+c-...@oneshoeco.com] I'm glad a iBGP session between the ASRs over a GRE tunnel was mentioned, as that's exactly what we have running and I was questioning whether this was a bad practice or not... Thanks, Tom [dprall] It's the Duct Tape of Networking David -- http://dcp.dcptech.com ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Not a valid host address error
On Wed, 2012-10-10 at 23:55 +0330, h bagade wrote: what about ip address like 0.2.3.1 255.255.255.0! what's the rule for this one? that one is in the book as well. richard ___ 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] Feedback for ES Cards
Hello Friends, I have recently joined this group and working with telecom company in India. I would like to know your feedback for Cisco 20 ports ES Ethernet cards, we are using these cards for trunk connectivity with swich and fould lots of limitation wrt QOS policy, its resources get exhausted and applied policy is not being honored. Any feedback from members on this group. Regards, kshitiz ___ 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] Half duplex VRF
Hi Arie, This is already in place and the virtual-access interfaces belongs to this vrf and so do their PPP host router. This routes are not visible in upstream vrt U which is great but these routes do appear in Downstream vrf D so that is the reason they route locally and doesnt go towards hub CE. The illustrations that i have seen before have CE sites connected on different PE routers whereas in my case the CE routers are connected to same PE and hence we want to avoid local routing on the LNS. Please let me know your thoughts over this. Thanks Hitesh On Wed, Oct 10, 2012 at 11:27 PM, Arie Vayner (avayner) avay...@cisco.comwrote: So basically your PPP connections are in the global routing table… What is the profile you are downloading from RADIUS (debug radius) for them? ** ** You most likely should be downloading the “ip vrf forwarding U downstream D” command using the RADIUS attribute “lcp:interface-config=ip vrf forwarding U downstream D”… http://www.cisco.com/en/US/docs/ios/12_3/feature/guide/ghdpvrf.html#wp1099907 ** ** Arie ** ** *From:* Hitesh Vinzoda [mailto:vinzoda.hit...@gmail.com] *Sent:* Wednesday, October 10, 2012 00:44 *To:* Arie Vayner (avayner) *Cc:* Cisco Mailing list *Subject:* Re: [c-nsp] Half duplex VRF ** ** Hi Arie, ** ** Below is the desired excerpt. We can't see the VRF config being applied to the interfaces but its visible in show ip int virtual-access. I have tried two different way in RADIUS attributes but the results are the same. ** ** LNS#show ppp all Interface/ID OPEN+ Nego* Fail- StagePeer AddressPeer Name - --- Vi4 LCP+ CHAP+ IPCP+ LocalT 192.168.254.200 \ sp...@cerberusnetworks.co.uk Vi3 LCP+ CHAP+ IPCP+ LocalT 192.168.254.100 \ m...@cerberusnetworks.co.uk LNS#show run int vir LNS#show run int virtual-acc LNS#show run int virtual-access 3 Building configuration... ** ** Current configuration : 78 bytes ! interface Virtual-Access3 ip mtu 1492 ip verify unicast reverse-path end ** ** LNS#show run int virtual-access 4 Building configuration... ** ** Current configuration : 78 bytes ! interface Virtual-Access4 ip mtu 1492 ip verify unicast reverse-path end = ** ** LNS#show ip int virtual-access 3 Virtual-Access3 is up, line protocol is up Interface is unnumbered. Using address of Loopback2 (2.2.2.1) Broadcast address is 255.255.255.255 Peer address is 192.168.254.100 MTU is 1492 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is enabled IP Flow switching is disabled IP CEF switching is enabled IP CEF switching turbo vector IP CEF turbo switching turbo vector VPN Routing/Forwarding U Downstream VPN Routing/Forwarding D Associated unicast routing topologies: ipv4 topologies in downstream VRF D : Topology base, operation state is UP ipv4 topologies in upstream(forwarding) VRF U: Topology base, operation state is UP === Thanks Hitesh ** ** On Tue, Oct 9, 2012 at 9:52 PM, Arie Vayner (avayner) avay...@cisco.com wrote: Hitesh, how does your virtual-access look like for the spokes? Can you please share the “show run interface virtual-access xx” for the spokes? Tnx Arie *From:* Hitesh Vinzoda [mailto:vinzoda.hit...@gmail.com] *Sent:* Tuesday, October 09, 2012 09:05 *To:* Arie Vayner (avayner) *Cc:* Cisco Mailing list *Subject:* Re: [c-nsp] Half duplex VRF Hi Arie, I have attached topology, .Net file and configs of related devices. R8 and R9 are simulating spokes whereas Internet-RTR is simulating Hub. Cheers Hitesh On Tue, Oct 9, 2012 at 8:37 PM, Arie Vayner (avayner) avay...@cisco.com wrote: Hitesh, can you maybe share some of your configs? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto: cisco-nsp-boun...@puck.nether.net] On Behalf Of Hitesh Vinzoda Sent: Tuesday, October 09, 2012 07:04 To: Cisco Mailing list Subject: [c-nsp] Half duplex VRF I am trying to setup half duplex vrf to save vrf's on the LNS. Does anyone has working
