Re: [c-nsp] Carrier grade NAT44 newest Cisco boxes
The question was what strategy of NAT deployment can be accepted by large ISP if one of the internal condition to use only cisco boxes for NAT ? Hidden cost was always visible to engeneers ) Now It is time to pay ) Has cisco plan to announce in next two year sucsessor of ISM-100 with better performance ? For example, if ISP already has asr9k chassis placed everywere in it's network, it will be happy to know that in 2013 cisco planning to do another card which will seat instead of ISM-100 into the same chassis. Gert Doering пишет: Hi, On Tue, Mar 13, 2012 at 07:01:10PM +0400, Ruslan Pustovoitov wrote: Does this question not worry community ? I think it's great that the hidden costs that come with running IPv4 now start being openly visible... Sorry, what was the question? gert ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] VSS display of show run on standby switch
Hey Guys, I have 2 x 6509's running as a virtual switch (VSS). I can't for the likes of me work out the command to display the serial number details of the Supervisor that is in standby. The Show run displays the details of the active supervisor. OMESW001#sho switch virtual Switch mode : Virtual Switch Virtual switch domain number : 100 Local switch number : 2 Local switch operational role: Virtual Switch Active Peer switch number : 1 Peer switch operational role : Virtual Switch Standby OMESW001# how can I display the show run equivalent on peer switch 1? ___ 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 Border Router Recommendation?
Hi, I have been looking at the ASR1001 but am concerned about the number of routes it supports. The product docs I have found show the router supports 1,000,000 IPv4 or 1,000,000 IPv6 routes (1). From what I have read on here there are only 512k IPv4 or 128k IPv6 routes supported in the FIB and no one is 100% sure how it will behave when this is exhausted. So my question is twofold. Is the realistic lifespan at the current expansion of prefixes (we are currently seeing just under 400k IPv4 routes from our upstreams and around 8k of IPv6) of the ASR1001 (my guess is about a year)? Secondly, what would be the best path to go given I would be looking for something able to support at least 1 million routes in the FIB. It wouldn't require LNS or LAC functionality and be required to support around 3 full BGP feeds. The forwarding rate would need to be around 500mbit moving towards 2 gigabit. Regards, James. 1. http://www.cisco.com/en/US/prod/collateral/routers/ps9343/data_sheet_c78-441072.html ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] VSS display of show run on standby switch
You just want to see the series number of supervisor in standby? Check the show inventory raw command to see whether you can find the answer or not. Xu Hu 2012/3/14 Brad Clausen overkil...@gmail.com Hey Guys, I have 2 x 6509's running as a virtual switch (VSS). I can't for the likes of me work out the command to display the serial number details of the Supervisor that is in standby. The Show run displays the details of the active supervisor. OMESW001#sho switch virtual Switch mode : Virtual Switch Virtual switch domain number : 100 Local switch number : 2 Local switch operational role: Virtual Switch Active Peer switch number : 1 Peer switch operational role : Virtual Switch Standby OMESW001# how can I display the show run equivalent on peer switch 1? ___ 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] Carrier grade NAT44 newest Cisco boxes
Actually in our 3G network, we use the 7609 (two ACE modules) for the NAT, in the live situation, we had 4M users. It is quite stable for now. Also we bought the ASR9K to expand the 3G network, maybe will migrate the NAT to ASR9K. Xu Hu 2012/3/14 Ruslan Pustovoitov ru...@mostelekom.net The question was what strategy of NAT deployment can be accepted by large ISP if one of the internal condition to use only cisco boxes for NAT ? Hidden cost was always visible to engeneers ) Now It is time to pay ) Has cisco plan to announce in next two year sucsessor of ISM-100 with better performance ? For example, if ISP already has asr9k chassis placed everywere in it's network, it will be happy to know that in 2013 cisco planning to do another card which will seat instead of ISM-100 into the same chassis. Gert Doering пишет: Hi, On Tue, Mar 13, 2012 at 07:01:10PM +0400, Ruslan Pustovoitov wrote: Does this question not worry community ? I think it's great that the hidden costs that come with running IPv4 now start being openly visible... Sorry, what was the question? gert __**_ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/**pipermail/cisco-nsp/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] Carrier grade NAT44 newest Cisco boxes
Hi, On Wed, 14 Mar 2012, Xu Hu wrote: Actually in our 3G network, we use the 7609 (two ACE modules) for the NAT, in the live situation, we had 4M users. It is quite stable for now. Also we bought the ASR9K to expand the 3G network, maybe will migrate the NAT to ASR9K. I am curios if and if how you are doing logging for law enforment purposes on that scale ? We in europe have some pressure to have the ability to map the ip/port/timestamp touple back to user. Of course nobody will be able to deliver the port together with the ip and an accurate enough timestamp for this to be meaningfull. I can see this becoming a larger problem when more nats appear on conventional DSL / FTTx / Cable access products as opposed to just low bandwidth mobile networks. Greetings Christian Xu Hu 2012/3/14 Ruslan Pustovoitov ru...@mostelekom.net The question was what strategy of NAT deployment can be accepted by large ISP if one of the internal condition to use only cisco boxes for NAT ? Hidden cost was always visible to engeneers ) Now It is time to pay ) Has cisco plan to announce in next two year sucsessor of ISM-100 with better performance ? For example, if ISP already has asr9k chassis placed everywere in it's network, it will be happy to know that in 2013 cisco planning to do another card which will seat instead of ISM-100 into the same chassis. Gert Doering ?: Hi, On Tue, Mar 13, 2012 at 07:01:10PM +0400, Ruslan Pustovoitov wrote: Does this question not worry community ? I think it's great that the hidden costs that come with running IPv4 now start being openly visible... Sorry, what was the question? gert __**_ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/**pipermail/cisco-nsp/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/ -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer ___ 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] Internet inside a VRF?
Hi, On Wed, Mar 14, 2012 at 01:12:02PM +1300, Pshem Kowalczyk wrote: In my previous role we've done just that. One internet VRF for all transit functions, separate vrfs for peering and customers and import-export statements to tie them all together. What is the benefit? The obvious drawback is much more complicated, more possible ways things can blow up, and more effort to setup and maintain. (We currently run Internet in the global table, and do not currently intent to change that due to if we make it more complicated, people will make more interesting mistakes) 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 pgpIwW5aKLzBF.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] Internet inside a VRF?
Hi, On Tue, Mar 13, 2012 at 09:29:11PM -0400, Dan Armstrong wrote: Two reasons, the first reason is that the config is extremely simple, clean and difficult for a less trained provisioning guy to make a mistake. With route maps, it's error prone to harmonize them across many boxes - and it's relatively easy for somebody to muck one up by accident. I'm not exactly sure I buy the simple and clean argument... unless convinced otherwise, I'd claim that the customer-facing config is about the same complexity with and without VRFs, and the network-side is more complicated with VRFs and MPLS. What sort of route-maps are that, that you think need synchronizing? (genuinely curious) 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 pgpwWS7dI92MC.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] Internet inside a VRF?
On (2012-03-13 21:29 -0400), Dan Armstrong wrote: The other reason is that we have some older folks around that long for the day when the core of a carrier network was ATM based, and the plethora of hops were basically hidden behind a switched network… They feel that customers will freak out and feel the service is inferior if a traceroute goes through many dozen hops. Having this inside a VRF lets us hide the hops inside a POP for instance, and only show the major transit points for clarity. You could also use TTL hiding. One other thing, I didn't see mentioned is that with INET in VRF you can easily do subset of Internet VRFs. This can be useful for example to have IXP Internet in subset which only imports you and your customer RT. So if someone default routes to you, they won't get free transit, but will get, what they should get. You can also sell partial transits, which are enforced by routing. And I'm sure there are plenty of situations where subset of Internet is useful. -- ++ytti ___ 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] Internet inside a VRF?
I guess you can ask: Why do we run mpls anyway or even plan on expanding it all the way to the access layer right? I thought the answer is obvious, TE capabilities, fast failover or common carrier infrastructure that scales well And by common I mean infrastructure that supports all the services you offer not just a couple In pure ipv4 environment how do you make sure your RRs infrastructure offers multiple paths for particular prefix? -well with mpls we just configure each PE with a different RD for the internet VRF -I know of several solutions to this in pure ipv4 but none is this simple adam -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Wednesday, March 14, 2012 10:04 AM To: Pshem Kowalczyk Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Internet inside a VRF? Hi, On Wed, Mar 14, 2012 at 01:12:02PM +1300, Pshem Kowalczyk wrote: In my previous role we've done just that. One internet VRF for all transit functions, separate vrfs for peering and customers and import-export statements to tie them all together. What is the benefit? The obvious drawback is much more complicated, more possible ways things can blow up, and more effort to setup and maintain. (We currently run Internet in the global table, and do not currently intent to change that due to if we make it more complicated, people will make more interesting mistakes) 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 ___ 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] Internet inside a VRF?
Hi, Putting internet in a vrf is not that bad. I agree with some people say that separate the global routing table with vrf is easier, especially for networks that are deploying MPLS routers from scratch. I don't see any advantages from putting internet Prefixes in the global routing table. Best Regards, Michalis Bersimis -- Message: 1 Date: Tue, 13 Mar 2012 21:58:58 -0500 From: Ge Moua moua0...@umn.edu To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Internet inside a VRF? Message-ID: 4f600972.6040...@umn.edu Content-Type: text/plain; charset=windows-1252; format=flowed In RE networks, separation of commodity Internet-1 and Internet-2 traffic. -- Regards, Ge Moua University of Minnesota Alumnus Email: moua0...@umn.edu -- On 3/13/12 8:17 PM, Jose Madrid wrote: I would like to understand why you guys would do this? What is the reasoning behind this? Super granular control? Cant this level of granularity be achieved with route-maps? Sent from my iPhone On Mar 13, 2012, at 8:27 PM, Dan Armstrongd...@beanfield.com wrote: We have all our Internet peers and customers inside a VRF currently, and our Cisco SE thinks we're stark raving mad, and should redesign and put everything back in the global table. This is all on ASR 9Ks and 7600s. On 2012-03-13, at 8:12 PM, Pshem Kowalczyk wrote: Hi, On 14 March 2012 11:59, Dan Armstrongd...@beanfield.com wrote: I know this topic has been discussed a million times, but just wanted to get an updated opinion on how people are feeling about this: In a service provider network, how do people feel about putting the big Internet routing table, all their peers and customers inside a VRF? Keep the global table for just infrastructure links? In my previous role we've done just that. One internet VRF for all transit functions, separate vrfs for peering and customers and import-export statements to tie them all together. All done on ASR1k (mainly 1006, but a few of 1002 as well). kind regards Pshem ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Internet inside a VRF?
Does memory usage not increase by putting all the internet routes in a VRF? Nick -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of michalis.bersi...@hq.cyta.gr Sent: 14 March 2012 09:47 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Internet inside a VRF? Hi, Putting internet in a vrf is not that bad. I agree with some people say that separate the global routing table with vrf is easier, especially for networks that are deploying MPLS routers from scratch. I don't see any advantages from putting internet Prefixes in the global routing table. Best Regards, Michalis Bersimis -- Message: 1 Date: Tue, 13 Mar 2012 21:58:58 -0500 From: Ge Moua moua0...@umn.edu To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Internet inside a VRF? Message-ID: 4f600972.6040...@umn.edu Content-Type: text/plain; charset=windows-1252; format=flowed In RE networks, separation of commodity Internet-1 and Internet-2 traffic. -- Regards, Ge Moua University of Minnesota Alumnus Email: moua0...@umn.edu -- On 3/13/12 8:17 PM, Jose Madrid wrote: I would like to understand why you guys would do this? What is the reasoning behind this? Super granular control? Cant this level of granularity be achieved with route-maps? Sent from my iPhone On Mar 13, 2012, at 8:27 PM, Dan Armstrongd...@beanfield.com wrote: We have all our Internet peers and customers inside a VRF currently, and our Cisco SE thinks we're stark raving mad, and should redesign and put everything back in the global table. This is all on ASR 9Ks and 7600s. On 2012-03-13, at 8:12 PM, Pshem Kowalczyk wrote: Hi, On 14 March 2012 11:59, Dan Armstrongd...@beanfield.com wrote: I know this topic has been discussed a million times, but just wanted to get an updated opinion on how people are feeling about this: In a service provider network, how do people feel about putting the big Internet routing table, all their peers and customers inside a VRF? Keep the global table for just infrastructure links? In my previous role we've done just that. One internet VRF for all transit functions, separate vrfs for peering and customers and import-export statements to tie them all together. All done on ASR1k (mainly 1006, but a few of 1002 as well). kind regards Pshem ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Pulsant. Finally, the recipient should check this email and any attachments for the presence of viruses. Pulsant accept no liability for any damage caused by any virus transmitted by this email. ___ 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] Internet inside a VRF?
On (2012-03-14 10:37 +), Nick Ryce wrote: Does memory usage not increase by putting all the internet routes in a VRF? Implementation detail. In HW FIB it shouldn't make any difference. In SW side, as you'll have slightly longer NLRI and you must have some RT communities it necessarily costs bit more in RIB, but this is imho, negligible. I wouldn't personally worry about it. I believe Cisco CEF book or maybe Behringer's MPLS VPN security book made some assumption about 2x, but it possibly cannot be true. You can mostly think of global table being just another instance in non-naive implementation of multiple FIB/RIB. -- ++ytti ___ 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] Question for LACP/LAG gurus
Im in the same situation as below, trying to get a LACP working between Extreme and an ASR 9k. Does anyone have a workaround for this rather than resetting the system id of the Extreme kit? Nick From: Dmitry Kiselev dmitry at dmitry.nethttps://puck.nether.net/mailman/listinfo/cisco-nsp To: cisco-nsp at puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsp Date: Tue, 12 Apr 2011 14:49:24 +0300 Subject: [c-nsp] Question for LACP/LAG gurus Hello! While building several new LAGs on IOS XR I found strange behaviour of Cisco IOSes for system priority LACP parameter. Most of classic IOSes allow to set value from 0 to 65535, but IOS XR does not: 12.2(55)SE2 Switch(config)#lacp system-priority ? 0-65535 Priority value 12.2(54)SG Switch(config)#lacp system-priority ? 0-65535 Priority value 12.2(33)SRE Router(config)#lacp system-priority ? 0-65535 Priority value IOS XE 12.2(33)XNF2 Router(config)#lacp system-priority ? 0-65535 Priority value IOS XR 4.0.1 Router(config)#lacp system priority ? 1-65535 Priority for this system. Lower value is higher priority. Moreover, IOS XR does not form the LAG if received partner system priority is zero. In this case each bundle port shows the error message Partner System ID/Key do not match that of the Selected links and remain configured state. It would remain a theoretical nuance, but Extreme Networks switches advertise priority=0 by default on all LAGs cousing some troubles in setup. Interesting fact thats in the same time zero is invalid value in Extreme switch configuration :) :) Extreme# configure sharing 7 lacp system-priority ? system_priority System Priority (1..65535) I take a short look inside IEEE 802.1AX-2008 standart and IEEE 802.3-2005 clause 43 and does not see any special case for priority=0. Does anybody in the list familar enough with LACP to explain me why Cisco IOS XR does not like zero here? Thanks -- Dmitry Kiselev Nick Ryce Senior Network Engineer Pulsant Limited T: 0845 119 9900 DDI: +44 131 5144049 W: www.pulsant.co.ukhttps://nbg01-exch-01.lumison.net/owa/redir.aspx?C=3d7cd71066064370b0210c73169f0074URL=http%3a%2f%2fwww.pulsant.co.uk -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Pulsant. Finally, the recipient should check this email and any attachments for the presence of viruses. Pulsant accept no liability for any damage caused by any virus transmitted by this email. ___ 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] N7k CoPP versus rate-limiters
All, We've just taken delivery of our first pair of N7k (and so far I'm impressed). I'm playing with porting our standard 6500 config to an equivalent N7k config, and I'm a bit puzzled by the interaction of CoPP and the hardware rate-limiters. On 6500/Sup720 these two features have well documented limitations and interaction - specifically HW rate-limiters pre-empt CoPP. I can't seem to find detailed information on how that works in the N7k. In general, what should I be using, for what? This is NX-OS 6, with M1 series linecards doing routing (MPLS). ___ 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] Internet inside a VRF?
If you run an MPLS network and are using MPLS to separate security zones within your network (such as a very large enterprise) then this makes perfect sense in the context of your design. Sure, it can be solutioned otherwise. The bottom line is: POC it, buy enough RAM and CPU, and deploy what you POC. If it works as expected without negative side-effects and its aligned with your overall design, then do it. Otherwise, don't. Honestly I wouldn't use anything less than RP2 w/16GB of RAM (a common theme in my posts here) and probably an ESP-40. Again, for the on-board RAM setup... not the throughput. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Jose Madrid jmadr...@gmail.com To: Dan Armstrong d...@beanfield.com Cc: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Sent: Tuesday, March 13, 2012 8:17 PM Subject: Re: [c-nsp] Internet inside a VRF? I would like to understand why you guys would do this? What is the reasoning behind this? Super granular control? Cant this level of granularity be achieved with route-maps? Sent from my iPhone On Mar 13, 2012, at 8:27 PM, Dan Armstrong d...@beanfield.com wrote: We have all our Internet peers and customers inside a VRF currently, and our Cisco SE thinks we're stark raving mad, and should redesign and put everything back in the global table. This is all on ASR 9Ks and 7600s. On 2012-03-13, at 8:12 PM, Pshem Kowalczyk wrote: Hi, On 14 March 2012 11:59, Dan Armstrong d...@beanfield.com wrote: I know this topic has been discussed a million times, but just wanted to get an updated opinion on how people are feeling about this: In a service provider network, how do people feel about putting the big Internet routing table, all their peers and customers inside a VRF? Keep the global table for just infrastructure links… In my previous role we've done just that. One internet VRF for all transit functions, separate vrfs for peering and customers and import-export statements to tie them all together. All done on ASR1k (mainly 1006, but a few of 1002 as well). kind regards Pshem ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Internet inside a VRF?
One additional point as I think most comments assumed such equation: Internet in a VRF = requirement for MPLS in the core. It does not. You can run mGRE encapsulation between ASBRs/PEs and the fact that behind GRE header of the packet sits vpnv4/v6 mpls label would have no bearing on the design of your core. No need to deploy LDP or RSVP-TE then worry that /32s of PE loopbacks are starting to hurt when number of such PEs grows ;) Also those who wish to send all paths between their ASBRs today may just do that by different RD configuration rather then with add-paths network wide OS code upgrade. There is one more advantage of using VRFs for Internet ... in fact just came to me this morning. You know there is all this buzz about securing internet with RPKI which will allow various parties/courts to mess with it and cherry pick who has right to be in the Internet and who does not. So even if you would keep Internet in the global table as today rather then dropping reachability for those forbidden guys due to RPKI telling you to do so (in the even of no other bgp path present) you could just export it to a VRF called Dirty_Internet and provide for those customers who are happy with it a chained lookup (global-vrf) or (vrf-vrf) .. if no route to the dst in the Clean_Internet global table go to vrf. That way we could easily maintain two parallel internets without in fact paying twice for it as only hopefully a very small percentage or nets/paths would be considered dirty. Mechanics of doing it are yet to be drawn on the whiteboard There are number of ways one could go about doing such design. Regards, R. ___ 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] VSS display of show run on standby switch
Haven't touched VSS in 8 months, but I believe you can do a 'sh mod ?' and after mod, you can do options for the individual chassis numbers. Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Brad Clausen Sent: Wednesday, March 14, 2012 3:00 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] VSS display of show run on standby switch Hey Guys, I have 2 x 6509's running as a virtual switch (VSS). I can't for the likes of me work out the command to display the serial number details of the Supervisor that is in standby. The Show run displays the details of the active supervisor. OMESW001#sho switch virtual Switch mode : Virtual Switch Virtual switch domain number : 100 Local switch number : 2 Local switch operational role: Virtual Switch Active Peer switch number : 1 Peer switch operational role : Virtual Switch Standby OMESW001# how can I display the show run equivalent on peer switch 1? ___ 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] VSS display of show run on standby switch
On Wed, Mar 14, 2012 at 10:26:35, Chuck Church wrote: Subject: Re: [c-nsp] VSS display of show run on standby switch Haven't touched VSS in 8 months, but I believe you can do a 'sh mod ?' and after mod, you can do options for the individual chassis numbers. Yup, 'show mod switch all' will list both. Show inv will also get you both with a Chassis # identifier. -ryan ___ 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] VSS display of show run on standby switch
Hi Brad, hkgi-ddcevssa#sho mod switch 2 Switch Number: 2 Role: Virtual Switch Standby -- - Mod Ports Card Type Model Serial No. --- - -- -- --- 1 48 CEF720 48 port 1000mb SFP WS-X6748-SFP xx 2 48 CEF720 48 port 1000mb SFP WS-X6748-SFP xx 3 16 CEF720 16 port 10GEWS-X6716-10GE xx 4 16 CEF720 16 port 10GEWS-X6716-10GE xx 55 Supervisor Engine 720 10GE (Hot) VS-S720-10G xx 6 16 CEF720 16 port 10GEWS-X6716-10GE xx 7 16 CEF720 16 port 10GEWS-X6716-10GE xx 88 CEF720 8 port 10GE with DFCWS-X6708-10GE xx 98 CEF720 8 port 10GE with DFCWS-X6708-10GE xx Regards, Jose On Wed, Mar 14, 2012 at 2:26 PM, Chuck Church chuckchu...@gmail.com wrote: Haven't touched VSS in 8 months, but I believe you can do a 'sh mod ?' and after mod, you can do options for the individual chassis numbers. Chuck -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Brad Clausen Sent: Wednesday, March 14, 2012 3:00 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] VSS display of show run on standby switch Hey Guys, I have 2 x 6509's running as a virtual switch (VSS). I can't for the likes of me work out the command to display the serial number details of the Supervisor that is in standby. The Show run displays the details of the active supervisor. OMESW001#sho switch virtual Switch mode : Virtual Switch Virtual switch domain number : 100 Local switch number : 2 Local switch operational role: Virtual Switch Active Peer switch number : 1 Peer switch operational role : Virtual Switch Standby OMESW001# how can I display the show run equivalent on peer switch 1? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Recommended IPv6 Resources
On Tue, 13 Mar 2012, Steve McCrory wrote: I'm more than prepared to hunt for resources and have a play with IPv6 for myself, I just wanted a pointer in the direction of good, informative, up-to-date material. Your point is well taken :) IPv6, like many other technologies, has launched numerous religious debates (read through the NANOG list archives for many examples ;) ), so there is lots of information available, but there is also lots of potential mis-information. There are also many areas where either vendor support is lean (inet6 firewall filters in Junos), or their documentation is lean (Cisco IPv6 inspection capabilities in the ASA comes to mind). jms ___ 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] Carrier grade NAT44 newest Cisco boxes
We in europe have some pressure to have the ability to map the ip/port/timestamp touple back to user. Of course nobody will be able to deliver the port together with the ip and an accurate enough timestamp for this to be meaningfull. Bulk Port Allocation (also called Port Range Allocation) is probably what you're looking for. It reduces logging requirements by several orders of magnitudes and your timestamping doesn't have to be as precise. This is a must to deploy any CGN, IMHO. Coming soon to your favorite Cisco CGN implementation, apparently... I can see this becoming a larger problem when more nats appear on conventional DSL / FTTx / Cable access products as opposed to just low bandwidth mobile networks. Mobile networks aren't that low bandwidth anymore. They have the same issues with logging. /JF ___ 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: Cisco ASA 5500 Series Adaptive Security Appliance Clientless VPN ActiveX Control Remote Code Execution Vulnerability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco Security Advisory: Cisco ASA 5500 Series Adaptive Security
Appliance Clientless VPN ActiveX Control Remote Code Execution
Vulnerability
Advisory ID: cisco-sa-20120314-asaclient
Revision 1.0
For Public Release 2012 March 14 16:00 UTC (GMT)
+
Summary
===
The Cisco Clientless VPN solution as deployed by Cisco ASA 5500
Series Adaptive Security Appliances (Cisco ASA) uses an ActiveX
control on client systems to perform port forwarding operations.
Microsoft Windows-based systems that are running Internet Explorer or
another browser that supports Microsoft ActiveX technology may be
affected if the system has ever connected to a device that is running
the Cisco Clientless VPN solution. A remote, unauthenticated attacker
who could convince a user to connect to a malicious web page could
exploit this issue to execute arbitrary code on the affected machine
with the privileges of the web browser.
The affected ActiveX control is distributed to endpoint systems by
Cisco ASA. However, the impact of successful exploitation of this
vulnerability is to the endpoint system only and does not compromise
Cisco ASA devices.
Cisco has released free software updates that address this
vulnerability.
Workarounds that mitigate this vulnerability are available.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120314-asaclient
Affected Products
=
Cisco Clientless VPN is a feature available on Cisco ASA 5500 Series
Adaptive Security Appliances.
Vulnerable Products
+--
Cisco ASA 5500 Series Adaptive Security Appliances that are running
one of the following versions contain the affected ActiveX component:
+---+
|Affected Version |Affected Release|
|--+|
| Cisco Adaptive Security Appliance Software |7.1 |
|7.x |7.2 |
|--+|
| |8.0 |
| |8.1 |
| Cisco Adaptive Security Appliance Software |8.2 |
|8.x |8.3 |
| |8.4 |
| |8.6 |
+---+
Note: Cisco ASA Software version 7.0 and 7.1 have reached end of
software maintenance. Customers who are using Cisco ASA Software
version 7.0 or 7.1 should contact their Cisco support team for
assistance in upgrading to a supported version of Cisco ASA
Software.
Note: The affected implementation of the Cisco Clientless VPN
solution was introduced with the release of Cisco ASA Software
version 7.1. This issue does not affect devices running Cisco
PIX Software.
Administrators may determine whether the Cisco Clientless VPN solution
is enabled on their devices by issuing the show running-config webvpn
command. The following example shows the response when the Cisco
Clientless VPN solution is enabled:
ciscoasa# show running-config webvpn
webvpn
enable outside
End user systems running Microsoft Windows may be affected if they
have used the Cisco Clientless VPN feature on an affected device from
a browser that supports ActiveX technology. Devices that contain the
cscopf.ocx ActiveX control registered with a class ID (CLSID) of
{B8E73359-3422-4384-8D27-4EA1B4C01232} are affected. The affected
controls are marked both Safe for Scripting (SFS) and Safe for
Initialization (SFI), which may present additional attack vectors
when a system has registered and cached the affected control.
Products Confirmed Not Vulnerable
+
* Cisco Firewall Service Modules are not affected by this
vulnerability
* Cisco Adaptive Security Appliance Services Modules are not
affected by this vulnerability
* Cisco IOS Software-based devices that use the Cisco Clientless
VPN solution (WebVPN) are not affected by this vulnerability
No other Cisco products are currently known to be affected by this
vulnerability.
Details
===
Cisco Adaptive Security Appliances (ASA) contain a feature known as
the Cisco Clientless VPN solution. The Cisco Clientless VPN feature
allows users to use a web browser to create an SSL VPN tunnel from an
endpoint device to a Cisco ASA device. When connected, the ASA
pushes several ActiveX and Java applications to the endpoint device
to allow a number of features to operate.
When a browser
[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-20120314-asa Revision 1.0 For Public Release 2012 March 14 16:00 UTC (GMT) +- Summary === Cisco ASA 5500 Series Adaptive Security Appliances (ASA) and Cisco Catalyst 6500 Series ASA Services Module (ASASM) are affected by the following vulnerabilities: * Cisco ASA UDP Inspection Engine Denial of Service Vulnerability * Cisco ASA Threat Detection Denial of Service Vulnerability * Cisco ASA Syslog Message 305006 Denial of Service Vulnerability * Protocol-Independent Multicast 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 others. Cisco has released free software updates that address these vulnerabilities. Workarounds are available to mitigate some of the vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120314-asa Note: The Cisco Catalyst 6500 Series Firewall Services Module (FWSM) may be affected by some of the vulnerabilities above. A separate Cisco Security Advisory has been published to disclose the vulnerabilities that affect the Cisco FWSM. The FWSM advisory is available at: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120314-fwsm Affected Products = Cisco ASA 5500 Series Adaptive Security Appliances and Cisco Catalyst 6500 Series ASA Services Module are affected by multiple vulnerabilities. Affected versions of Cisco ASA Software will vary depending on the specific vulnerability. Consult the Software Versions and Fixes section of this security advisory for more information about the affected version. Cisco PIX Security Appliances may be affected by some of the vulnerabilities described in this security advisory. Cisco PIX has reached end of maintenance support. Cisco PIX Security Appliance customers are encouraged to migrate to Cisco ASA 5500 Series Adaptive Security Appliances. Consult the dedicated section for Cisco PIX Security Appliances in the Vulnerable Products section of this security advisory for more information about affected versions. Vulnerable Products +-- For specific version information, refer to the Software Versions and Fixes section of this advisory. Cisco ASA UDP Inspection Engine Denial of Service Vulnerability +-- The Cisco ASA UDP inspection engine that is used to inspect UDP-based protocols contains a vulnerability that could allow a remote unauthenticated attacker to trigger a reload of the Cisco ASA. All UDP protocols that are being inspected by the Cisco ASA UDP inspection engine may be vulnerable. The following protocols are known to use the Cisco ASA UDP inspection engine: * Domain Name System (DNS) * Session Initiation Protocol (SIP) * Simple Network Management Protocol (SNMP) * GPRS Tunneling Protocol (GTP) * H.323, H.225 RAS * Media Gateway Control Protocol (MGCP) * SunRPC * Trivial File Transfer Protocol (TFTP) * X Display Manager Control Protocol (XDMCP) * IBM NetBios * Instant Messaging (depending on the particular IM client/solution being used) Note: UDP inspection engines may be enabled by default on Cisco ASA Software. Please consult your user guide for more information. The default inspected ports are listed at the following link: http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/inspect_overview.html Note: The Cisco ASA UDP inspection can be applied to non-default UDP ports via class-map and policy-map commands. Any instance of use of the Cisco ASA UDP inspection engines may be vulnerable to this vulnerability, thus, configurations that include non-default UDP ports but use the Cisco ASA UDP inspection engine are considered vulnerable. To determine whether any of the above inspections are enabled, issue the show service-policy | include inspection engine name command and confirm that the command returns output. The following example shows a Cisco ASA configured to inspect IBM NetBIOS traffic: ciscoasa# show service-policy | include netbios Inspect: netbios, packet 0, drop 0, reset-drop 0 Cisco ASA Threat Detection Denial of Service Vulnerability +- The Cisco ASA Threat Detection feature, when configured with the Scanning Threat Mode feature and with shun option enabled, contains a vulnerability that could allow a remote unauthenticated attacker to trigger a reload of the Cisco ASA. This feature is not enabled by default. To determine whether the Cisco ASA Threat Detection with Scanning Threat feature
[c-nsp] Cisco Security Advisory: Cisco Firewall Services Module Crafted Protocol Independent Multicast Message Denial of Service Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cisco Firewall Services Module Crafted Protocol Independent Multicast Message Denial of Service Vulnerability Advisory ID: cisco-sa-20120314-fwsm Revision 1.0 For Public Release 2012 March 14 16:00 UTC (GMT) +- Summary === The Cisco Catalyst 6500 Series Firewall Services Module (FWSM) contains a Protocol Independent Multicast (PIM) Denial of Service Vulnerability. Cisco has released free software updates that address this vulnerability. There are no workarounds available that mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120314-fwsm Note: The Cisco Adaptive Security Appliance (ASA) and the Cisco Catalyst 6500 ASA Services Module (ASASM) are also affected by this vulnerability. A separate Cisco Security Advisory has been published to disclose the vulnerabilities that affect the ASA and ASASM. That advisory is available at: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120314-asa Affected Products = The Cisco Catalyst 6500 Series Firewall Services Module is affected by this vulnerability. Not all versions of released FWSM Software are affected. Consult the Software Versions and Fixes section of this security advisory for more information. Vulnerable Products - --- For specific version information, refer to the Software Versions and Fixes section of this advisory. Protocol Independent Multicast Denial of Service Vulnerability +- The Cisco FWSM is affected by a vulnerability that may cause affected devices to reload during the processing of a PIM message when multicast routing is enabled. Multicast routing is disabled by default, however when multicast routing is enabled on the Cisco FWSM, PIM is automatically enabled on all interfaces. The following command enables multicast routing: fwsm(config)# multicast-routing To verify whether PIM is enabled on an interface use the show pim interface command. The following example shows PIM enabled on the inside interface: fwsm# sh pim interface Address Interface PIM Nbr Hello DR DR Count Intvl Prior 172.16.1.66inside on 0 30 1 this system Products Confirmed Not Vulnerable + With the exception of the Cisco ASA and the Cisco Catalyst 6500 ASA Services Module, no other Cisco products are currently known to be affected by this vulnerability. Details === The following section gives additional details about this vulnerability. Protocol Independent Multicast Denial of Service Vulnerability +- Multicast routing is a bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to multiple recipients. Protocol Independent Multicast (PIM) is a multicast routing protocol that is independent of any IP routing protocol. PIM can leverage any unicast routing protocols that are in use, including Exterior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), or static routes, to populate the unicast routing table. PIM uses this unicast routing information to perform the multicast forwarding function, and is IP protocol-independent. Although PIM is called a multicast routing protocol, it actually uses the unicast routing table to perform the Reverse Path Forwarding (RPF) check function instead of building a completely independent multicast routing table. PIM does not send or receive multicast routing updates between routers as do other routing protocols. A vulnerability exists in the way PIM is implemented that may cause affected devices to reload during the processing of a PIM message when multicast routing is enabled. The vulnerability is due to improper handling of PIM messages. An attacker could exploit this vulnerability by sending a crafted PIM message to the affected system. This vulnerability is documented in Cisco bug ID CSCtu97367, and has been assigned Common Vulnerabilities ans Exposures (CVE) ID CVE-2012-0356. Vulnerability Scoring Details = Cisco has scored the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this security advisory is in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps organizations determine the urgency and priority of a response. Cisco has provided a base and temporal score. Customers can also compute environmental scores that help determine the impact of the vulnerability
[c-nsp] ip Multicast MoH with zone Based Firewalls?
I have a Voice deployment with a remote site that has multicast Music on hold. The 2821 that it goes through also has Zone based Firewalls so I can do GRE over IPSec.(which is not the interface that the Multicast Moh is using) my problem is that my Music on hold is not working. sh ip mroute shows: (*, 239.1.1.1), 00:50:22/00:02:58, RP x.y.1.252, flags: SJC Incoming interface: GigabitEthernet0/1.902, RPF nbr x.z.9.254 == WAN Metro E Outgoing interface list: GigabitEthernet0/0.1026, Forward/Sparse-Dense, 00:00:01/00:02:58 ==Phone network 239.1.1.1 is my Multicast MoH The RP is correct. both interfaces .902 and 1026 are in the INSIDE zone with a Zone policy of class default pass I'm running 15.1(3)T2, Is this a zone based FW issue? a Multicast issue? or a Bug? I'm not sure which way to go. other then drive to the remote site and do a packet capture. Other ideas? I'm trying not to drive =) TIA Scott ___ 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] ip Multicast MoH with zone Based Firewalls?
On 14/03/12 17:56, Scott Voll wrote: I have a Voice deployment with a remote site that has multicast Music on hold. The 2821 that it goes through also has Zone based Firewalls so I can do GRE over IPSec.(which is not the interface that the Multicast Moh is using) my problem is that my Music on hold is not working. sh ip mroute shows: (*, 239.1.1.1), 00:50:22/00:02:58, RP x.y.1.252, flags: SJC Incoming interface: GigabitEthernet0/1.902, RPF nbr x.z.9.254 == WAN Metro E Outgoing interface list: GigabitEthernet0/0.1026, Forward/Sparse-Dense, 00:00:01/00:02:58 ==Phone network 239.1.1.1 is my Multicast MoH The RP is correct. both interfaces .902 and 1026 are in the INSIDE zone with a Zone policy of class default pass I'm running 15.1(3)T2, Is this a zone based FW issue? a Multicast issue? or a Bug? I'm not sure which way to go. other then drive to the remote site and do a packet capture. Other ideas? I'm trying not to drive =) Disclaimer: I know nothing about ZBFw. There isn't really enough information here. You'd need to specify the topology in a bit more detail. Where is the source of the MoH? Have you traced the PIM join state from the source to the RP, and from source to receiver, and from RP to receiver? Since you don't have an (s,g) entry, I'm guessing the RP is either not receiving the Register packet, or the packet isn't being sent down the shared-tree to the edge router, thus an (s,g) join isn't working. MTU might be an issue here, if the MoH packets are large. This is a bit of a pain with PIM registers, and whether the inner or outer packet is fragmented varies by IOS version IIRC. More details, please ;o) ___ 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] Internet inside a VRF?
Bear in mind that IOS and IOS-XR do per prefix label allocation by default and that some vendors do not cope well with a high number of labels from what I can remember. Regards Le 12-03-14 06:37, « Nick Ryce » nick.r...@lumison.net a écrit : Does memory usage not increase by putting all the internet routes in a VRF? Nick -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of michalis.bersi...@hq.cyta.gr Sent: 14 March 2012 09:47 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Internet inside a VRF? Hi, Putting internet in a vrf is not that bad. I agree with some people say that separate the global routing table with vrf is easier, especially for networks that are deploying MPLS routers from scratch. I don't see any advantages from putting internet Prefixes in the global routing table. Best Regards, Michalis Bersimis -- Message: 1 Date: Tue, 13 Mar 2012 21:58:58 -0500 From: Ge Moua moua0...@umn.edu To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Internet inside a VRF? Message-ID: 4f600972.6040...@umn.edu Content-Type: text/plain; charset=windows-1252; format=flowed In RE networks, separation of commodity Internet-1 and Internet-2 traffic. -- Regards, Ge Moua University of Minnesota Alumnus Email: moua0...@umn.edu -- On 3/13/12 8:17 PM, Jose Madrid wrote: I would like to understand why you guys would do this? What is the reasoning behind this? Super granular control? Cant this level of granularity be achieved with route-maps? Sent from my iPhone On Mar 13, 2012, at 8:27 PM, Dan Armstrongd...@beanfield.com wrote: We have all our Internet peers and customers inside a VRF currently, and our Cisco SE thinks we're stark raving mad, and should redesign and put everything back in the global table. This is all on ASR 9Ks and 7600s. On 2012-03-13, at 8:12 PM, Pshem Kowalczyk wrote: Hi, On 14 March 2012 11:59, Dan Armstrongd...@beanfield.com wrote: I know this topic has been discussed a million times, but just wanted to get an updated opinion on how people are feeling about this: In a service provider network, how do people feel about putting the big Internet routing table, all their peers and customers inside a VRF? Keep the global table for just infrastructure links? In my previous role we've done just that. One internet VRF for all transit functions, separate vrfs for peering and customers and import-export statements to tie them all together. All done on ASR1k (mainly 1006, but a few of 1002 as well). kind regards Pshem ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Pulsant. Finally, the recipient should check this email and any attachments for the presence of viruses. Pulsant accept no liability for any damage caused by any virus transmitted by this email. ___ 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] cisco PPPoE Intermediate agent SNMP info
Hello, You guys (and gals) rock, thanks for being here. So I am noticing now that as I am using pppoe intermediate agent tags, I don't seem to be able to get my 7201 to show me any pppoe intermediate agent info (circuit-id and remote-id for example) for active sessions. The 7201 is certainly passing these along to my radius server and such, but 'show sss sessions detailed' has nothing to indicate what tags were present with the sessions listed, and there also doesn't appear to be anything available with SNMP either. It seems to me that knowing which circuit-id was associated with a session would be a logical thing to want. It does appear that cisco does send this information in the accounting packets, but it's otherwise unavailable. This means I would have to keep a seperate table if I want this all together with 'current sessions' information. Does anyone have any other ideas for this? Mike- ___ 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] Internet inside a VRF?
Hi, On 14 March 2012 22:04, Gert Doering g...@greenie.muc.de wrote: Hi, On Wed, Mar 14, 2012 at 01:12:02PM +1300, Pshem Kowalczyk wrote: In my previous role we've done just that. One internet VRF for all transit functions, separate vrfs for peering and customers and import-export statements to tie them all together. What is the benefit? The obvious drawback is much more complicated, more possible ways things can blow up, and more effort to setup and maintain. Easy separation into 'infrastructure' and 'services' spaces. From that perspective internet is just another service that's being offered. Ability to offer connectivity to resources only as required; so for example someone needs only domestic/peering and not full transit - they connection vrf only imports particular RT and it's all sorted. kind regards Pshem ___ 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] Internet inside a VRF?
On 15/03/2012, at 8:23 AM, Pshem Kowalczyk wrote: Ability to offer connectivity to resources only as required; so for example someone needs only domestic/peering and not full transit - they connection vrf only imports particular RT and it's all sorted. Are people really doing this? - I would imagine that you run into routing table problems very quickly on things like 6500/ 7600s. Regards Andrew ___ 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] Internet inside a VRF?
On 15 March 2012 10:29, Andrew Miehs and...@2sheds.de wrote: On 15/03/2012, at 8:23 AM, Pshem Kowalczyk wrote: Ability to offer connectivity to resources only as required; so for example someone needs only domestic/peering and not full transit - they connection vrf only imports particular RT and it's all sorted. Are people really doing this? - I would imagine that you run into routing table problems very quickly on things like 6500/ 7600s. That particular setup is using ASR1ks, not 6500/7600. kind regards Pshem ___ 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] Interoperability issue between ME-3800X and Huawei OSN 6800 (1000BaseLX)
Hi Guys, Does anyone have experienced problems interconnecting Cisco Router with DWDM Huawei equipments through 1000BaseLX? I am currently trying to connect a ME-3800X using the SFP+ Multi-rate port (Ten0/1) with a GLC-LH-SM versus Huawei OSN 6800 DWDM and I am experiencing problem bringing the b2b interface Up. I have tried turning on and off the Auto-Negotiation on the Cisco Router without success. Curiously, when I change the link to a 1GigaEth port (Gi0/1) in the ME-3800X the link goes UP and end2end connectivity is established. I was wondering whether some change have to be done on the DWDM equipment in order to achieve the negotiation with the SFP+ port. Thanks in advance for any comment you may suggest. Regards. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
