Re: [c-nsp] EVC/EFP - Longest match VLAN stack length
Hi I have not verified but the more specific one should be before the general rule. So you should switch them around. interface TenGigabitEthernet0/1 service instance 10 ethernet encapsulation dot1q 10 second-dot1q 555 rewrite ingress tag pop 1 symmetric bridge-domain 10555 service instance 20 ethernet encapsulation dot1q 10 second-dot1q any rewrite ingress tag pop 1 symmetric bridge-domain 1 service instance 30 ethernet encapsulation dot1q 10 rewrite ingress tag pop 1 symmetric bridge-domain 10 In this case, though not tested, a packet tagged 10+555 would be sent too bd10555 and 10+any to bd1 and then 10+non to bd10. //Mattias Gyllenvarg Obduro Network AB On Wed, Dec 11, 2013 at 3:51 PM, Arash Alizadeh aras...@hotmail.se wrote: Hi, I wonder if anyone knows if you in two seperate EFP's could match the same outermost tag where one matches a single-tagged frame and the other one matches it when it's stacked . I.e: interface TenGigabitEthernet0/1 service instance 1 ethernet encapsulation dot1q 10 rewrite ingress tag pop 1 symmetric bridge-domain 10 ! service instance 2 ethernet encapsulation dot1q 10 second-dot1q any rewrite ingress tag pop 1 symmetric bridge-domain 20 ! Unfortunately I'm not able to try this myself and I havn't found anything on the web covering this scenario. Thanks in advance. Arash ___ 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/ -- *Med Vänliga Hälsningar* *Mattias Gyllenvarg* ___ 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] C6500 IPv6 redistribute with route-map?
There's drawbacks to customer prefixes in BGP - and one of them is convergence is slower plus more potential for loops while reconverging... And here I would object that with PIC-Core and PIC-Edge BGP is as fast as OSPF/ISIS doing IP FRR. 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] C6500 IPv6 redistribute with route-map?
We are looking at deploying dedicated route reflectors on 1U Dell or HP servers against inside ESXi or Qemu/KVM hypervisors, mostly to benefit from the super quick multi- core CPU's and tons of fast RAM that you just don't get in routers. I'll report back how this goes, in a few months, as it will be relatively large scale. Mark. Hi Mark, Do you plan on running virtual XR, XE or JUNOS or even some customized BGP daemon on those? I'm very interested on how it will work out for you. I'm all pro for virtualizing BGP control plane, makes so much sense. 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] C6500 IPv6 redistribute with route-map?
On Thursday, December 12, 2013 10:30:06 AM Adam Vitkovsky wrote: And here I would object that with PIC-Core and PIC-Edge BGP is as fast as OSPF/ISIS doing IP FRR. I have seen extraordinary BGP performance in modern code in IOS and Junos, particularly in NG-MVPN scenarios where BGP is handling PIM messages. BGP PIC, Next Hop Addressing Tracking and Fast Fallover have all improved BGP performance to the point where it doesn't matter that much. Perhaps, some day, when I'm really lazy, I'll work on some empirical data for various scenarios. 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] C6500 IPv6 redistribute with route-map?
On Thursday, December 12, 2013 10:42:01 AM Adam Vitkovsky wrote: Hi Mark, Do you plan on running virtual XR, XE or JUNOS or even some customized BGP daemon on those? I'm very interested on how it will work out for you. I'm all pro for virtualizing BGP control plane, makes so much sense. CSR1000v on ESXi for IOS XE, or vRR on Qemu/KVM for Junos. I'll let you know how we go; but yes, all that RAM and CPU that will be available in a 1U server vs. a (decent) router like the ASR1001 or Juniper RE-1800X4 is too hard to resist. 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] C6500 IPv6 redistribute with route-map?
I'll let you know how we go; but yes, all that RAM and CPU that will be available in a 1U server vs. a (decent) router like the ASR1001 or Juniper RE-1800X4 is too hard to resist. Or even imagine a pool of these geographically distributed with multiple links to core at each site. VM-overlay on the pool and run RRs on top of that and you'll end up with RRs infrastructure that is never down and will scale endlessly. 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] C6500 IPv6 redistribute with route-map?
Hi, On Thu, Dec 12, 2013 at 10:04:20AM +0100, Adam Vitkovsky wrote: I'll let you know how we go; but yes, all that RAM and CPU that will be available in a 1U server vs. a (decent) router like the ASR1001 or Juniper RE-1800X4 is too hard to resist. Or even imagine a pool of these geographically distributed with multiple links to core at each site. VM-overlay on the pool and run RRs on top of that and you'll end up with RRs infrastructure that is never down and will scale endlessly. My imagination works a bit differently from yours, it seems. My imagination sees outage in the VM management infrastructure which leads to all RRs being down at the same time, and no network left to bring them back... *shiver* (OTOH using the technologies Mark mentioned, having a VM layer makes sense - if the routing engine is not software run on top of a general purpose OS but a routing engine VM running on top of a hypervisor... but then more along the lines of what Nick proposed, with a dedicated metal running the hypervisor, and no fancy VM management-move-around-automatism engine playing tricks in the background) 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 pgph7PXFMBqrC.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] C6500 IPv6 redistribute with route-map?
On 12/12/13 09:08, Gert Doering wrote: My imagination sees outage in the VM management infrastructure which leads to all RRs being down at the same time, and no network left to bring them back... *shiver* Agreed - anyone using the helpful automagic stuff like vCentre for something like an RR is crazy. We've had issues with it exploding and the VMs being unmanageable. OTOH a standalone hypervisor with no external dependencies can be pretty much bulletproof; our DNS and DHCP servers run on KVM boxes, and they're rock solid. One advantage is reboot times - modern servers take an age to POST, but a KVM guest can reboot in under 30 seconds. ___ 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] C6500 IPv6 redistribute with route-map?
On Thursday, December 12, 2013 11:04:20 AM Adam Vitkovsky wrote: Or even imagine a pool of these geographically distributed with multiple links to core at each site. VM-overlay on the pool and run RRs on top of that and you'll end up with RRs infrastructure that is never down and will scale endlessly. My design is similar to what I'd do with a normal router, i.e., 2x route reflectors per PoP, local iBGP clients in each PoP to each router reflector, and a full iBGP mesh between route reflectors across the various PoP's. All I'm getting from doing this on servers and not routers is the CPU and RAM advantage. 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] C6500 IPv6 redistribute with route-map?
On Thursday, December 12, 2013 11:08:20 AM Gert Doering wrote: (OTOH using the technologies Mark mentioned, having a VM layer makes sense - if the routing engine is not software run on top of a general purpose OS but a routing engine VM running on top of a hypervisor... but then more along the lines of what Nick proposed, with a dedicated metal running the hypervisor, and no fancy VM management-move-around-automatism engine playing tricks in the background) Yes; I wished you could boot IOS(X*) or Junos on bare metal, given they all support x86_64 hardware, but the vendors have opted to keep tight control of things by fitting the OS inside a VM. So the leanest and most manageable deployment you can have with this is: - Metal - Hypervisor - Router OS CSR1000v is supported on ESXi only today, and to load it up, you require vSphere client. I'd rather you didn't, but it's thin enough and manageable, so as long as you keep it simple, you should be stable. Junos will run on Qemu or KVM natively, so no external management required, although there are some you can use. 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] C6500 IPv6 redistribute with route-map?
On 12/12/2013 09:44, Mark Tinka wrote: All I'm getting from doing this on servers and not routers is the CPU and RAM advantage. + the possibility of genuine oob if you have a separate oob infrastructure. 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] C6500 IPv6 redistribute with route-map?
On Thursday, December 12, 2013 11:50:38 AM Nick Hilliard wrote: + the possibility of genuine oob if you have a separate oob infrastructure. That too, yes. Three links into each server - 2x links into the core backbone which is what the router OS will see for IS-IS + iBGP, and 1x Ethernet link mapped to the router OS software console port which is connected to a network that handles the OoB portion. You can also add more OoB access by hooking up to the server's iLO port to the same or another OoB network. 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] C6500 IPv6 redistribute with route-map?
On 12/12/2013 09:31, Phil Mayers wrote: Agreed - anyone using the helpful automagic stuff like vCentre for something like an RR is crazy. We've had issues with it exploding and the VMs being unmanageable. Agreed. For network-critical stuff, I wouldn't touch that management crap with a bargepole. When it fails (not if), the hilarity level is off the scale. Layering an underlying infrastructure on top of this would be a recipe for the sort of failure that would cause stupid levels of downtime, recoverable only by onsite high level engineering people. 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] C6500 IPv6 redistribute with route-map?
My imagination sees outage in the VM management infrastructure which leads to all RRs being down at the same time, and no network left to bring them back... *shiver* Agreed - anyone using the helpful automagic stuff like vCentre for something like an RR is crazy. We've had issues with it exploding and the VMs being unmanageable. I rather meant some proven solution like e.g. Amazon uses to provide cloud computing services. Something that is steady. And you can always have two separate clouds so in case one dies for some reason you'll still remain with one RR per POP. 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] C6500 IPv6 redistribute with route-map?
On 12/12/2013 10:03, Adam Vitkovsky wrote: I rather meant some proven solution like e.g. Amazon uses to provide cloud computing services. No, no and more no. Total layering violation and abandonment of KISS principal. Not clever. 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] C6500 IPv6 redistribute with route-map?
Hi, On Thu, Dec 12, 2013 at 11:03:04AM +0100, Adam Vitkovsky wrote: I rather meant some proven solution like e.g. Amazon uses to provide cloud computing services. Like, proven until it falls over? Not like bits and pieces of the Amazon (or Azure) cloud hasn't fallen apart with cascading failures... But there's a famous quote here - I recommend this to all my competitors. Network stability is overvalued anyway :-) 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 pgpPJIiReCdkS.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] C6500 IPv6 redistribute with route-map?
On Thu, 12 Dec 2013, Mark Tinka wrote: CSR1000v is supported on ESXi only today, and to load it up, you require vSphere client. I'd rather you didn't, but it's FWIW - not anymore: http://www.cisco.com/en/US/docs/routers/csr1000/software/configuration/csroverview.html#wp1081607 I happily run a pair of them in my home lab in kvm on Mac Mini running Ubuntu. The install was as simple as creating the appropriately sized HDD disk image and booting the VM off the ISO. With KVM, you get the usual option of VNC console into it. Warning: not a speed daemon. By far. But, it's also not been long since it was released, so I am hoping this is not the final performance point. --a p.s. I also ran the latest version on my laptop in Fusion with no apparent problem, but I did not test much besides some MAP-T stuff - I had been doing internet in a box mode of development with everything hosted on my laptop: client, cpe, internet, and csr1kv being all in different VMs crossconnected internally withing Fusion. So don't take that toying as a supported config for business-critical stuff. ___ 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] C6500 IPv6 redistribute with route-map?
On Thursday, December 12, 2013 12:06:54 PM Nick Hilliard wrote: No, no and more no. Total layering violation and abandonment of KISS principal. Not clever. +1. Don't know why anyone would run their critical infrastructure on a remote cloud :-). 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] C6500 IPv6 redistribute with route-map?
On Thu, Dec 12, 2013 at 2:01 PM, Mark Tinka mark.ti...@seacom.mu wrote: On Thursday, December 12, 2013 12:06:54 PM Nick Hilliard wrote: No, no and more no. Total layering violation and abandonment of KISS principal. Not clever. +1. Don't know why anyone would run their critical infrastructure on a remote cloud :-). We are waiting as fast as we can for the cloud to come back up :) ___ 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] N7k CoPP not MPLS-aware?
On 15/11/13 12:02, Saku Ytti wrote: On (2013-11-15 09:48 +), Phil Mayers wrote: Has anyone else seen this? Our N7k CoPP policy seems to be letting packets through which are arriving MPLS-labelled. In particular, this means it's completely ineffective at protecting the CPU in an L3VPN, since all packets inside the VPN arrive labelled. Alas this is the rule, 7600 having working CoPP is the exception. In 2006-03-16 I opened TAC case 603198067 complaining how 'explicit-null' breaks CoPP in GSR, VXR, NSE100, 5400, result was that it was expected behaviour. Sadly you are correct. CSCty29692 is the relevant bug ID, and the traffic is hitting the MPLS L2 limiter in my testing. Oh well. ___ 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] ASR9K RSPAN via bundle-ether
Hi, Looking for a quick pointer here, I need to get a remote SPAN session active from one of our ASR9K units across a few Cat6K chassis and into an analyser. We use RSPAN across all the 6Ks without any issues, and from my understanding the ASR needs to egress the captured packets out of a sub-interface and tag them with the RSPAN vlan which the 6K is expecting. Then the 6K will flood the packets in the RSPAN vlan and get them to our analyser like normal. Now on the assumption that is correct so far, I’ll move on to the actual issue. The only link between this particular ASR and the Cat6k is via a 4x10GB bundle-ether, which has a number of sub-interfaces on it. The spanning feature on the ASR does not support egress mirroring to a destination port which is a bundle-ether, which is handy – so, the question is, what if I were to target the egress towards one of the physical 10GB member ports within the bundle, as a sub-interface of the physical port? From the Cat6k perspective it won’t care as the packets are arriving it will just forward them on the RSPAN vlan. So the only (big) issue is whether or not the ASR will be happy to have one port within the bundle setup to egress mirrored packets? Oh, and I'm familiar with the mirror-to-pseudowire method, but in this scenario it isn't a particularly nice option for reasons not covered above. So - any thoughts or suggestions are most welcome - Cheers! Robert Williams Custodian Data Centre Email: rob...@custodiandc.com http://www.CustodianDC.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] 4500X weird issue...
Follow-up to the follow-up :) Long story short... Switch essentially had no flash and dir, etc gave errors. TAC had us boot from tftp image via ROMMON. Booted up, found config, write mem worked, founds it's VSS partner, and dropped to standby. Rebooted the other switch, this one became primary, and all is well. Still don't understand why even ROMMON couldn't find a flash, yet tftp booting IOS seemed to make everything well again. But not looking a gift horse in the mouth, just wondering in case this shows up again. I really don't like the restart breaking things scenario :) Jeff On 12/10/2013 8:45 PM, Jeff Kell wrote: Follow-up... the secondary booted up OK. We're looking at a possible RMA on the failing one (TAC case open) rather than cracking the case on a virgin switch to mess with flash :). Jeff On 12/6/2013 11:25 PM, Jeff Kell wrote: We received our first pair of 4500X switches, and proceeded to try to prepare them for deployment. They came up OK on console access, we got a very basic configuration setup, linked them together, and did an initial VSS pairing. With that successful, we put in a management IP address for the management port, saved everything, and proceeded to move them to the server room. Upon power-up at the new location, they won't boot... * * * Rom Monitor NVRAM configuration is being initialized to * * default values. This may be because it was never initialized.* * * Writing to Primary Region failed Writing to Backup Region failed ___ 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] asa, internal web filter
Hello, We currently have our gateway / web filter routing setup in this manor: lan --- 2921 ---asa(firewall) ---internet | -- web filter So the traffic destined to the internet that is not supposed to be filtered goes right through the router to the asa. The traffic that is destined to be filtered gets policy routed to the web filter which then gets routed back to the 2921 and out to the asa. This is a bad design, I will admit that. What I want to do is this: lan - 2921 --- asa(firewall) --- internet || --- web filter --- With this change the traffic will not have to go back to the router and then back out to the asa. This will cut the traffic going through the router in half, which will result in lower cpu usage. My question about changing this is as follows. The asa has a route to the lan networks that are getting filtered. Lets say they are 172.16.0.0/16. There is an eigrp relationship between the router and asa. If I use a route-map to policy route certain networks to the web filter connected in the new way, will the return traffic go back through the web filter or will it go back directly to the router? I don't have a spare ASA to test this with. One other thing to note is the web filter is a proxy so the http and https traffic changes the source ip after its passed through. The rest of the traffic is untouched. Thanks, Dan. ___ 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] 4500X weird issue...
On Friday, December 13, 2013 01:05:20 AM Jeff Kell wrote: Still don't understand why even ROMMON couldn't find a flash, yet tftp booting IOS seemed to make everything well again. But not looking a gift horse in the mouth, just wondering in case this shows up again. I really don't like the restart breaking things scenario :) TFTP would work because it's like assuming your flash is the network. Saving to NVRAM will still work because the NVRAM storage is different from flash (well, typically). So what is the situation now? Can you reboot from flash, or do you really have no flash? 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/
[c-nsp] Nexus 5k Switch Archive configuration file
Hi All,
How can we accomplish below command in Cisco Nexus switch ? Basically I
want to send the configuration file to ftp server once I save the config.
Also trying to search on Cisco link, haven't found anything related yet.
Much appreciate if you could give the link or config.
-
system {
archival {
configuration {
transfer-on-commit;
archive-sites {
ftp://username:password@172.30.36.59;;
}
}
}
Thanks.
--
Samol Khoeurn
(855) 077 55 64 02 / (855) 067 41 88 66
Network Engineer
Cisco: CCNA/CCNP SP/CCIP/
Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
www.linkedin.com/in/samolkhoeurn
___
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/
