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] VASI interface and NAT on ASR1k
Matt: As of IOS-XE 3.5, I am happy to report that match-in-vrf is supported. This means you can merrily apply ip nat outside to a VASI interface. We use VASI interfaces for this purpose. VRFs are paired and linked together via VASI. The global MPLS interfaces are ip nat inside and the VASI interfaces are ip nat outside. This gives us NAT overload in both directions. Keep in mind that *all* NATs must be configured with the match-in-vrf keyword. Additionally the VASI interface gives us an air-gap between disparate private networks. Static routes are put into the VRFs pointing to the VASI interface (and thus to the opposite VRF in the pair). These are redistributed into BGP against a route-map. This route-map matches on a tag: ip route vrf CUST-A-TO-B-VRF x.x.x.x ... tag 1000 If the tag is 1000, it gets redistributed with a local-preference of 1000. If its 500 it gets redistributed with a tag of 500. So we have a redundant ASR with the same config, different route-tags. If the primary dies (or otherwise loses both links into the P core) then traffic will automatically re-route through the secondary ASR. I believe you can get up to 500 pairs of VRFs in this scenario (only can configure 500 VASI pairs at this time). The ASR itself is limited to an embarrassing 16k configured static NATS (b!). Lastly, if you intend to scale this configuration, then you will need to get an RP2 w/16GB of RAM and an ESP-40. Not for throughput mind you, but because of how ridiculously memory hungry IOS-XE is. The ESP-20 has 1GB of high-speed RAM shared between forwarding logic and NAT sessions. With minimal routes you can support close to a million concurrent NAT sessions. But if you put 500k routes across 500 VRFs on that box, you will only be able to support 400k of concurrent NAT sessions. You'll want to go ahead and configure timeouts of one hour for NAT sessions in general on the box. The ESP-40, on the other hand, has a different memory area for forwarding-logic vs NAT sessions. Presumably the forward-logic will not step on the NAT, and you can get the million concurrent sessions. Lastly there are only two real options to consider when buying a processor for the ASR 1K: RP2 w/8GB of RAM or RP2 w/16GB of RAM. Frankly Cisco shouldn't be selling anything less because of how much memory is required of newer versions of code. Plus the performance of the RP1 from the CLI is *awful.* Or you could just go the way of linux and hack out a solution using iptables in containers and veth interface pairs... if it meets your requirements... *ahem* shameless plug: http://packetpushers.net/network-interrupted Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Matthew Melbourne m...@melbourne.org.uk To: cisco-nsp@puck.nether.net Sent: Monday, March 12, 2012 11:14 AM Subject: [c-nsp] VASI interface and NAT on ASR1k Hi, Does anyone have any pointers to some real-world use cases for VASI interfaces on an ASR1k? I have a corner case where I can't use MP-BGP to import a route from one VRF into another, when the next-hop of the route is in a separate VRF (the case is VRF-aware IPsec with FVRF/iVRF configuration). It looks like the issue can be worked around using VASI interfaces (i.e. a vasileft/vasiright pair). I have used a /30 to address the VASI interfaces and this appears to work, but is this best practice? NAT may be another useful requirement in this scenario, but I have seen other cisco-nsp postings which suggests 'ip nat outside' shouldn't be configured on an interface which isn't in the global table. A suggestions is that ip nat enable and hence NVI be used in preference to classic NAT for VASI interfaces? VASI does appear to be a rather poorly documented feature in IOS-XE :) Cheers, Matt -- Matthew Melbourne ___ 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] DLSw+ performance
All: Short article on improving DLSw+ performance/scalability... http://packetpushers.net/dlsw-performance/ No, I'm not kidding. Yes I know its 2012. :-) Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ ___ 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] non-existing input errors on 6500/SXI...?
Look at the rest of the ports on your box for xmit errors... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Gert Doering g...@greenie.muc.de To: Andrew Miehs and...@2sheds.de Cc: Gert Doering g...@greenie.muc.de; cisco-nsp@puck.nether.net Service Providers cisco-nsp@puck.nether.net Sent: Saturday, October 22, 2011 1:51 PM Subject: Re: [c-nsp] non-existing input errors on 6500/SXI...? Hi, On Sat, Oct 22, 2011 at 11:57:38AM +0200, Andrew Miehs wrote: And what about show counters interface gig 1/9 Does that shed any more light? No... 14. RcvErr = 2440160 25. InErrors = 2440160 ... but nothing else that is in the same range (greater then 0 and somewhere near 1-2 millions). 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/ ___ 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] general question on VRFs and FIBs...
All: I actually received quite a few responses off-list to this question. We have to deal with many different audit/compliance agencies each with their own guidelines. One of their guidelines is that security zones should reside on physically separate switches. However, in an MPLS based on environment they allow for VRF/VSI separation on the same physical device. The reason is that each instance has its own RIB and its own FIB structures. At least, this is what I've heard now from multiple auditors over the last 6 or 7 years while working for different companies. I'm questioning this in general because we are looking at OpenFlow. In particular, the question came up Are separate structures really necessary? What if the FIB lookup was entirely hash-based (source-port included) and each entry in the hash table had a mask-structure associated with it (for src/dst mac and IPs?). I previously blogged that a (totally hypothetical) multi-tenant network built entirely with PBR or FBF would not pass audit because of a lack of separate RIB and separate FIB structures for each tenant in the network. Why wouldn't this pass audit? OpenFlow is similar. In this potential OpenFlow design there would still be separate VRFs on the controllers, but ultimately the forwarding would be compiled into this single hash table structure. So I'm questioning a basic assumption here: Are separate FIB structures for each VPN required? What I am hearing is mainly ASIC/NPU/FPGA design/performance concerns. Robert expressed some concerns over one VPN potentially impacting other VPNs with something like route instability or table corruption of some kind.. crashing was the word he used :-). I did spray a few lists with this question, but they are lists where the right people generally lurk... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth From: Robert Raszuk rob...@raszuk.net To: Gert Doering g...@greenie.muc.de Cc: Derick Winkworth dwinkwo...@att.net; juniper-...@puck.nether.net juniper-...@puck.nether.net; cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Sent: Tuesday, September 27, 2011 3:58 AM Subject: Re: [c-nsp] general question on VRFs and FIBs... Hi Gert, address first, VRF second. Well no one sane would do that ;) I believe what Derick was asking was why not have incoming_interface/table_id - prefix lookup. And while in software each VRF has separate RIB and FIB data structures for reasons already discussed on L3VPN IETF mailing list in actual hardware on a given line card however this may no longer be the case. Also side note that most vendors still did not implement per interface/per vrf MPLS labels (even in control plane) so all labels are looked up in a global table with just additional essentially control plane driven twicks to protect from malicious attacks in the case of CSC/Inter-AS. Cheers, R. Hi, On Mon, Sep 26, 2011 at 01:18:05PM -0700, Derick Winkworth wrote: I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one FIB table with a column that identifies the VRF instance? I'm not finding it, but I'm guessing its because of performance issues? Lookup would fail for overlapping address space if you lookup address first, VRF second. How do you find the right entry if you have 10.0.0.0/8 vrf red 10.0.0.0/16 vrf green 10.0.1.0/24 vrf blue and try to look up 10.0.0.1 in vrf red? You'll find the /24 entry, which is tagged vrf blue. Alternatively, you'd need to explode the /8 entry for vrf red if *another* VRF adds a more specific for that /8. 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/ ___ 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] (no subject)
testing IOS-XE in lab. versions 3.1.4a and 3.4.0a. we're seeing each VPNv4 route consume about 3.75mb of memory.on the RP. please tell me this is a joke. ___ 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] (no subject)
Wow. Nevermind. I failed at basic math. Its ~4k per VPN route. Still, that adds up quick. I think if you plan on using an ASR 1k as a PE and you have over 250k VPNv4 routes then you should go with an RP2 and 8GB of RAM just to be safe.. RP1 takes a *long* time to load 200k+ routes. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Derick Winkworth dwinkwo...@att.net To: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Sent: Wed, August 31, 2011 6:06:51 PM Subject: [c-nsp] (no subject) testing IOS-XE in lab. versions 3.1.4a and 3.4.0a. we're seeing each VPNv4 route consume about 3.75mb of memory.on the RP. please tell me this is a joke. ___ 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] Brocade Vs Cisco
Engineer to your requirements. Cisco and Juniper are good vendors to have for variety. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Gert Doering g...@greenie.muc.de To: Ryan Finnesey rfinne...@gmail.com Cc: cisco-nsp@puck.nether.net Sent: Fri, August 12, 2011 2:52:44 AM Subject: Re: [c-nsp] Brocade Vs Cisco Hi, On Thu, Aug 11, 2011 at 09:00:32PM -0400, Ryan Finnesey wrote: What would be your preference between just Cisco or Juniper depends on what you want to do with it Recently, OS and TAC support quality at Juniper seriously went down the drain, so the original reason to want Juniper high quality operating system and very motivated company to iron out the remaining wrinkles seems to have been lost... OTOH, Cisco is still stuck in we have too many operating systems and we spend half our resources with BU in-fighting mode - which, I guess, will now be fixed by firing 10.000 folks from engineering so they won't get in the way of the in-fighting anymore... Right now, I'm not sure I'm trusting either company enough. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germanyg...@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] QoS question
You might be able to figure it out with show ip cache verbose flow which requires you to enable ip flow ingress on the interfaces in question... You will see in there a byte for TOS. You might be able to infer from this how the traffic is getting marked/classified and thus what queue it egresses... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com --- On Thu, 7/28/11, Muhammad Atif Jauhar atif.jau...@gmail.com wrote: From: Muhammad Atif Jauhar atif.jau...@gmail.com Subject: [c-nsp] QoS question To: cisco-nsp@puck.nether.net Date: Thursday, July 28, 2011, 1:15 PM Hi All, I am new to QoS technology. I have one question: I have below connectivity and configuration example: Client -- Switch-1 -- Router-1 --- Router-2 --- Network Cloud --- Server Router-1 Router-2 are managed by me. Switch-1 is not managed by me. Router-1 has configured for QoS marking on interface with Switch-1 and Bandwidth management QoS configuration is configured on interface with Router-2. In Router-1 we didn't marking traffic from Client to Server in QoS configuration. I have question: Is there any way in Router-1 or Router-2 to observe traffic from Client toward Server is come under which QoS queue. -- Regards, Muhammad Atif Jauhar (+60-10-2155076) ___ 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] more money we don't have to fucking spend
http://news.yahoo.com/obama-east-africa-famine-needs-world-respond-211611984.html Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.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] more money we don't have to fucking spend
doh! wrong list SORRY Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Randy randy_94...@yahoo.com To: cisco-nsp@puck.nether.net; Derick Winkworth dwinkwo...@att.net Sent: Fri, July 29, 2011 6:45:06 PM Subject: Re: [c-nsp] more money we don't have to fucking spend CCIE and JNCIE-M not withstanding - How is this relevant to the *cisco-nsp* list. Can we stay on topic please. ./Randy --- On Fri, 7/29/11, Derick Winkworth dwinkwo...@att.net wrote: From: Derick Winkworth dwinkwo...@att.net Subject: [c-nsp] more money we don't have to fucking spend To: cisco-nsp@puck.nether.net Date: Friday, July 29, 2011, 4:24 PM http://news.yahoo.com/obama-east-africa-famine-needs-world-respond-211611984.html l Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.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/ ___ 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] How Q-in-Q should work in VMWare...
Curious on feedback about this: http://blinking-network.blogspot.com/2011/07/physical-cabling-dependencies-inhibit.html Basically, I think VMWare should support MPLS or Q-in-Q in a meaninful way (no VLAN 4095 hackery). Sadly the Nexus 1000v supports neither (or so I'm told). Even if it or vSwitch did support it, it probably wouldn't work the right way. VLAN differentiation in a multi-tenant environment should not have physical dependencies on the ESX host. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.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] Firewalls as-a-service in an MPLS infrastructure...
From Fortinets website: # Chassis-based models can support up to 3000 VDOMs # Talked to Fortinet rep and confirmed it. its not that they recommend 250, its just that beyond 250 there is no support for some of the advanced features Fortinet considers their special sauce (e-mail scanning, etc). I'm pretty sure the actual maximum number of allowed VRs/zones on a 3k SRX is 1000. Or it will be soon. I'll verify that later this evening. The number of LSYS is in fact 32. However you don't get all those zones/vrs/nats/FW rules per lsys, those are just spread out across the LSYS... The ASA I think can support up to 500 contexts now, but with contexts enabled I'm hearing there is no crypto support. I'm not sure this is an impediment for us but I can see it being an issue for folks. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Matthew M North matthew.no...@gmail.com To: Chandler Bassett cbass@gmail.com Cc: dwinkwo...@att.net; juniper-...@puck.nether.net; cisco-nsp@puck.nether.net Sent: Thu, July 7, 2011 9:57:21 PM Subject: Re: [c-nsp] Firewalls as-a-service in an MPLS infrastructure... Fortinet does thousands of thier VDOMs (virtual-firewalls) on a single unit... Thousands-no. They do 250 VDOMs on the high end units (3000 series), 500 VDOMs I heard on the 5001B (with some special licensing, haven't see or tested yet, they recommend max 250). Juniper SRX you can use VRs security zones. On Junos 10.4+ get 250 VRs. 5800 you can get 500 VRs. Have gotten # for lsys yet. On Thu, Jul 7, 2011 at 2:35 PM, Chandler Bassett cbass@gmail.com wrote: I thought the ASA blade was for the 6500's? On Wed, Jul 6, 2011 at 11:47 AM, Derick Winkworth dwinkwo...@att.netwrote: Thoughts on this blog entry? I wonder if Cisco will support BGP on ASA soon.. I know people have been asking for it. It would be nice if it had something Netconf on it too... The new ASA blade is coming out for Nexus I hear, anyone know how many virtual-firewalls it will support? Juniper's SRX will do LSYS soon.. 32 per box. That seems like a low number. Fortinet does thousands of thier VDOMs (virtual-firewalls) on a single unit... ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Firewalls as-a-service in an MPLS infrastructure...
Thoughts on this blog entry? I wonder if Cisco will support BGP on ASA soon.. I know people have been asking for it. It would be nice if it had something Netconf on it too... The new ASA blade is coming out for Nexus I hear, anyone know how many virtual-firewalls it will support? Juniper's SRX will do LSYS soon.. 32 per box. That seems like a low number. Fortinet does thousands of thier VDOMs (virtual-firewalls) on a single unit... ___ 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] GRE tunnel to do span vlan across two datacenters?
If you are not already running MPLS, then I would rule VPLS out... though there are some benefits to biting the bullet and learning MPLS and virtualizing your network with it. L2TPv3 is a better option than GRE, in my opinion. Also having dark fiber means large MTUs yes? I think that would be preferable... --- On Wed, 7/6/11, Jason Gurtz jasongu...@npumail.com wrote: From: Jason Gurtz jasongu...@npumail.com Subject: [c-nsp] GRE tunnel to do span vlan across two datacenters? To: cisco-nsp@puck.nether.net Date: Wednesday, July 6, 2011, 11:08 AM A firm has proposed creating a GRE tunnel between two datacenters (using a 3750X stack at each) to create the spanned vlans needed for VMWare failover application. Clearly there is tunnel overhead but I sense there are other failure modes here that aren't so clear to me--I am familiar in concept with GRE tunnels but don't have a heck of a lot of opex. Can anyone share more insight on the merit (or lack of) with this proposed design? I am aware (via this list, thanks!) of several shortcomings surrounding 3750 based stacks, but cisco alternatives seem pricier still or too big. There is dark fiber available, what about VPLS w/ LDP or L2TP solution? Current network is L3 at the access layer w/ OSPF (4507-sup6 access, 4900M cores): A1 /\ / \ C1--C2 \ / \/ A2 Maybe it is better to just overlay stp back on to the network w/root and alt-root at C1/C2 (V1 and V2 are the proposed 3750X stacks)? Scary to me, but an an argument can be made for less complexity -vs.- tunnling/vpn based approach. A1 .V1 /\ . ' / /. ' \ / C1--C2 \` . / \ \/ ' . \ A2 'V2 OTOH, by the time this actually gets done maybe TRILL will be out ;) Hopefully this enterprisy topic is not too OT! ~JasonG ___ 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] GRE tunnel to do span vlan across two datacenters?
I thought about that, but then decided not to recommend it. Its definitely the simplest, but its also not really the best design in my opinion. If only Cisco had a smaller unit that could do MPLS VPNs *and* VPLS. That would seem more strategic in nature than patching it now with a vlan or pseudowire. Isn't the ASR supposed to be getting some VPLS support here soon? Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com --- On Wed, 7/6/11, Gert Doering g...@greenie.muc.de wrote: From: Gert Doering g...@greenie.muc.de Subject: Re: [c-nsp] GRE tunnel to do span vlan across two datacenters? To: Jason Gurtz jasongu...@npumail.com Cc: cisco-nsp@puck.nether.net Date: Wednesday, July 6, 2011, 12:23 PM Hi, On Wed, Jul 06, 2011 at 12:08:53PM -0400, Jason Gurtz wrote: A firm has proposed creating a GRE tunnel between two datacenters (using a 3750X stack at each) to create the spanned vlans needed for VMWare failover application. I'd double-check that the 3750X can do that. The 3750-with-no-X can *not*. There is dark fiber available, what about VPLS w/ LDP or L2TP solution? If there's fiber available, why not just trunk the VLANs across? 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 -Inline Attachment Follows- ___ 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] SQL*Net and firewalls..
New blog post I hope others find helpful... http://blinking-network.blogspot.com/2011/06/sqlnet-aka-oracle-tns-and-firewalls.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] Service Provider Networks: Cisco vs XYZ
1. Yes there are studies and comparisons. They are usually skewed/biased favorably towards the company that is paying to have the study/comparison done. 2. Juniper/Alcatel-Lucent I think today are the primary competing vendors you want to look at. 3. Tackling the service-provider problem is different than the enterprise problem. There is a reason why other vendors have had success in this space. Sometimes they really do make better products for the application/deployment scenario in question. --- On Thu, 6/23/11, ar ar_...@yahoo.com wrote: From: ar ar_...@yahoo.com Subject: [c-nsp] Service Provider Networks: Cisco vs XYZ To: cisco-nsp cisco-nsp@puck.nether.net Date: Thursday, June 23, 2011, 10:37 PM Hi Peeps. I am pro-Cisco on building IP/MPLS service provider networks. I've proven its capabilities. However, does anyone has a study/comparison or testing with other brands? Brocade,Huawei,Juniper,HP? ___ 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] NAT-as-a-Service in an MPLS network...
For those interested, see new blog entry: http://blinking-network.blogspot.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] VASI NAT on ASR/IOS-XE solved... I hope.
Best viewed with a fixed width font... Bottom line if you intend to use the ASR in this fashion then by all means start harassing your account team to have match-in-vrf type functionality implemented on the ASR. Still the solution below works (as far as we have tested it), its just not as elegant as it could be... ___ / ___ ASR PE \ | / \ | | | A |-+ | | \___/ | | | ___ _|_ | | / \ / \ | | | B |---| D | | | \___/ \___/ | | ___ | | | / \ | | | | C |-+ | | \___/ | \___/ | |to P-cloud | NAT with VASI on IOS-XE--- In the diagram above we have a NAT on an MPLS stick solution. VRFs A, B, and C are each connected to VRF D over a pair of VASI interfaces. The MPLS interface facing the P-cloud is ip nat inside and all six of the VASI interfaces are ip nat outside. VASI promises to more easily enable services between VRFs in a router. One of those services is NAT. In this post to C-NSP I'll describe how to do NAT over VASI. Suppose somewhere out in network D there are two servers. They house the same application and for whatever reason some customers are on one server and some customers are on the other server. Both servers have RFC1918 addressing: 10.1.1.1 and 10.1.1.2. Customers are told to go after some URL that resolves to a public address: 40.40.40.40. Customer A comes in sourced on a public address they own and so you do not need to NAT their source. Their address is 30.30.30.30. This customer should go to server 10.1.1.2. Also, server 10.1.1.2 needs to be able initiate outbound to this customer. Customer B comes in sourced on their own private addressing so you need to NAT their source to an RFC1918 address native to network D. You will overload them to 10.140.1.1. This customer should go to server 10.1.1.2. The server does not initiate out to this customer. The customer has changed their local DNS so the URL resolves to 192.168.50.9. They would like you to NAT the server to this IP instead of 40.40.40.40. You have already NAT'd Customer C somewhere else in the network to an RFC1918 subnet native to network D. Their address is 10.150.1.1. This customer should go to server 10.1.1.1. The server does not initiate out to the customer. Customer A -- ip nat inside source static 30.30.30.30 30.30.30.30 vrf VRF-A extendable ip nat outside source static 10.1.1.2 40.40.40.40 vrf VRF-A extendable ip route vrf VRF-A 40.40.40.0 255.255.255.0 vasileft1 ip route vrf VRF-D 30.30.30.30 255.255.255.255 vasiright1 Customer B -- ip access-list extended CUSTOMERB-NAT-ACL permit ip any any ip nat pool CUSTOMERB 10.140.1.1 10.140.1.1 netmask 255.255.255.0 ip nat inside source list CUSTOMERB-NAT-ACL pool CUSTOMERB vrf VRF-B overload ip nat outside source static 10.1.1.2 192.168.50.9 vrf VRF-B extendable ip route vrf VRF-B 192.168.50.9 255.255.255.255 vasileft2 ip route vrf VRF-D 10.140.1.1 255.255.255.255 vasiright2 Customer C -- ip nat outside source static 10.1.1.1 40.40.40.40 vrf VRF-C extendable ip route vrf VRF-C 40.40.40.0 255.255.255.0 vasileft3 ip route vrf VRF-D 10.150.1.1 255.255.255.255 vasiright3 Discussion -- The ASR has a couple of limitations you should be aware of. First is that there is no match-in-vrf capability in IOS-XE. According to the release notes ip nat outside is not supported on a VRF subinterface. This contradicts VASI documentation that shows VASI interfaces in VRFs with ip nat outside configured. This limitation means that outside NAT statements in a VRF could be ignored as followed: (a) ip nat outside is configured on a VRF interface and (b) you initiate a session from a host in the outside domain of the VRF and (c) there is no *inside* NAT translation in the VRF for the destination. If you initiate a session from the inside domain then the outside NATs will always be applied as appropriate. The second limitation is that because there is no match-in-vrf capability on the ASR, you can not reuse global addresses in inside NAT statements. This is true even if the statements are for different VRFs. This is a callback to traditional NAT PE setups where you were always NATing traffic as it passed from an inside interface in a VRF to an outside interface in the global routing table. With these limitations in mind, lets talk about the NAT statements above. First, in order to have the same public address 40.40.40.40 translated to different addresses in network D you need to use extendable outside NAT statements. You configure these in the customer VRFs as appropriate. This is because of limitation #2 above. For
Re: [c-nsp] VASI NAT on ASR/IOS-XE solved... I hope.
That came out all jacked up, obviously. Will attempt to fix. --- On Wed, 5/11/11, Derick Winkworth dwinkwo...@att.net wrote: From: Derick Winkworth dwinkwo...@att.net Subject: [c-nsp] VASI NAT on ASR/IOS-XE solved... I hope. To: cisco-nsp@puck.nether.net Date: Wednesday, May 11, 2011, 9:49 AM Best viewed with a fixed width font... Bottom line if you intend to use the ASR in this fashion then by all means start harassing your account team to have match-in-vrf type functionality implemented on the ASR. Still the solution below works (as far as we have tested it), its just not as elegant as it could be... ___ / ___ ASR PE \ | / \ | | | A |-+ | | \___/ | | | ___ _|_ | | / \ / \ | | | B |---| D | | | \___/ \___/ | | ___ | | | / \ | | | | C |-+ | | \___/ | \___/ | |to P-cloud | NAT with VASI on IOS-XE--- In the diagram above we have a NAT on an MPLS stick solution. VRFs A, B, and C are each connected to VRF D over a pair of VASI interfaces. The MPLS interface facing the P-cloud is ip nat inside and all six of the VASI interfaces are ip nat outside. VASI promises to more easily enable services between VRFs in a router. One of those services is NAT. In this post to C-NSP I'll describe how to do NAT over VASI. Suppose somewhere out in network D there are two servers. They house the same application and for whatever reason some customers are on one server and some customers are on the other server. Both servers have RFC1918 addressing: 10.1.1.1 and 10.1.1.2. Customers are told to go after some URL that resolves to a public address: 40.40.40.40. Customer A comes in sourced on a public address they own and so you do not need to NAT their source. Their address is 30.30.30.30. This customer should go to server 10.1.1.2. Also, server 10.1.1.2 needs to be able initiate outbound to this customer. Customer B comes in sourced on their own private addressing so you need to NAT their source to an RFC1918 address native to network D. You will overload them to 10.140.1.1. This customer should go to server 10.1.1.2. The server does not initiate out to this customer. The customer has changed their local DNS so the URL resolves to 192.168.50.9. They would like you to NAT the server to this IP instead of 40.40.40.40. You have already NAT'd Customer C somewhere else in the network to an RFC1918 subnet native to network D. Their address is 10.150.1.1. This customer should go to server 10.1.1.1. The server does not initiate out to the customer. Customer A -- ip nat inside source static 30.30.30.30 30.30.30.30 vrf VRF-A extendable ip nat outside source static 10.1.1.2 40.40.40.40 vrf VRF-A extendable ip route vrf VRF-A 40.40.40.0 255.255.255.0 vasileft1 ip route vrf VRF-D 30.30.30.30 255.255.255.255 vasiright1 Customer B -- ip access-list extended CUSTOMERB-NAT-ACL permit ip any any ip nat pool CUSTOMERB 10.140.1.1 10.140.1.1 netmask 255.255.255.0 ip nat inside source list CUSTOMERB-NAT-ACL pool CUSTOMERB vrf VRF-B overload ip nat outside source static 10.1.1.2 192.168.50.9 vrf VRF-B extendable ip route vrf VRF-B 192.168.50.9 255.255.255.255 vasileft2 ip route vrf VRF-D 10.140.1.1 255.255.255.255 vasiright2 Customer C -- ip nat outside source static 10.1.1.1 40.40.40.40 vrf VRF-C extendable ip route vrf VRF-C 40.40.40.0 255.255.255.0 vasileft3 ip route vrf VRF-D 10.150.1.1 255.255.255.255 vasiright3 Discussion -- The ASR has a couple of limitations you should be aware of. First is that there is no match-in-vrf capability in IOS-XE. According to the release notes ip nat outside is not supported on a VRF subinterface. This contradicts VASI documentation that shows VASI interfaces in VRFs with ip nat outside configured. This limitation means that outside NAT statements in a VRF could be ignored as followed: (a) ip nat outside is configured on a VRF interface and (b) you initiate a session from a host in the outside domain of the VRF and (c) there is no *inside* NAT translation in the VRF for the destination. If you initiate a session from the inside domain then the outside NATs will always be applied as appropriate. The second limitation is that because there is no match-in-vrf capability on the ASR, you can not reuse global addresses in inside NAT statements. This is true even if the statements are for different VRFs. This is a callback to traditional NAT PE setups where you were always NATing traffic as it passed from an inside interface in a VRF to an outside interface in the global routing table. With these limitations in mind, lets
[c-nsp] VASI NAT on ASR/IOS-XE solved... attempt #2
Best viewed with a fixed width font... Bottom line if you intend to use the ASR in this fashion then by all means start harassing your account team to have match-in-vrf type functionality implemented on the ASR. Still the solution below works (as far as we have tested it), its just not as elegant as it could be... ___ / ___ ASR PE \ | / \ | | | A |-+ | | \___/ | | | ___ _|_ | | / \ / \ | | | B |---| D | | | \___/ \___/ | | ___ | | | / \ | | | | C |-+ | | \___/ | \___/ | |to P-cloud | NAT with VASI on IOS-XE --- VASI promises to more easily enable services between VRFs in a router. One of those services is NAT. In this post to C-NSP I'll describe how to do NAT over VASI. In the diagram above we have a NAT on an MPLS stick solution. VRFs A, B, and C are each connected to VRF D over a pair of VASI interfaces. The MPLS interface facing the P-cloud is ip nat inside and all six of the VASI interfaces are ip nat outside. Suppose somewhere out in network D there are two servers. They house the same application and for whatever reason some customers are on one server and some customers are on the other server. Both servers have RFC1918 addressing: 10.1.1.1 and 10.1.1.2. Customers are told to go after some URL that resolves to a public address: 40.40.40.40. Customer A comes in sourced on a public address they own and so you do not need to NAT their source. Their address is 30.30.30.30. This customer should go to server 10.1.1.2. Also, server 10.1.1.2 needs to be able initiate outbound to this customer. Customer B comes in sourced on their own private addressing so you need to NAT their source to an RFC1918 address native to network D. You will overload them to 10.140.1.1. This customer should go to server 10.1.1.2. The server does not initiate out to this customer. The customer has changed their local DNS so the URL resolves to 192.168.50.9. They would like you to NAT the server to this IP instead of 40.40.40.40. You have already NAT'd Customer C somewhere else in the network to an RFC1918 subnet native to network D. Their address is 10.150.1.1. This customer should go to server 10.1.1.1. The server does not initiate out to the customer. Customer A -- ip nat inside source static 30.30.30.30 30.30.30.30 vrf VRF-A extendable ip nat outside source static 10.1.1.2 40.40.40.40 vrf VRF-A extendable ip route vrf VRF-A 40.40.40.0 255.255.255.0 vasileft1 ip route vrf VRF-D 30.30.30.30 255.255.255.255 vasiright1 Customer B -- ip access-list extended CUSTOMERB-NAT-ACL permit ip any any ip nat pool CUSTOMERB 10.140.1.1 10.140.1.1 netmask 255.255.255.0 ip nat inside source list CUSTOMERB-NAT-ACL pool CUSTOMERB vrf VRF-B overload ip nat outside source static 10.1.1.2 192.168.50.9 vrf VRF-B extendable ip route vrf VRF-B 192.168.50.9 255.255.255.255 vasileft2 ip route vrf VRF-D 10.140.1.1 255.255.255.255 vasiright2 Customer C -- ip nat outside source static 10.1.1.1 40.40.40.40 vrf VRF-C extendable ip route vrf VRF-C 40.40.40.0 255.255.255.0 vasileft3 ip route vrf VRF-D 10.150.1.1 255.255.255.255 vasiright3 Discussion -- The ASR has a couple of limitations you should be aware of. First is that there is no match-in-vrf capability in IOS-XE. According to the release notes ip nat outside is not supported on a VRF subinterface. This contradicts VASI documentation that shows VASI interfaces in VRFs with ip nat outside configured. This limitation means that outside NAT statements in a VRF could be ignored as followed: (a) ip nat outside is configured on a VRF interface and (b) you initiate a session from a host in the outside domain of the VRF and (c) there is no *inside* NAT translation in the VRF for the destination. If you initiate a session from the inside domain then the outside NATs will always be applied as appropriate. The second limitation is that because there is no match-in-vrf capability on the ASR, you can not reuse global addresses in inside NAT statements. This is true even if the statements are for different VRFs. This is a callback to traditional NAT PE setups where you were always NATing traffic as it passed from an inside interface in a VRF to an outside interface in the global routing table. With these limitations in mind, lets talk about the NAT statements above. First, in order to have the same public address 40.40.40.40 translated to different addresses in network D you need to use extendable outside NAT statements. You configure these in the customer VRFs as appropriate. This is because of
[c-nsp] VASI fail on ASR...
All: Is anyone using VASI and NAT together on the ASR? The VASI documentation that is publicly available (plus some other documentation you can through your SE) seems to indicate that VASI can enable services like NAT between VRFs. However, the NAT part just isn't true. As of right now, no version of XE supports VRFs configured on the NAT outside interface and NAT outside interfaces are not MPLS aware. This basically makes it impossible to use NAT with VASI. You can't put ip nat outside on a VASI interface in a VRF (or any interface) and putting ip nat inside on the VASI interface is pointless because NAT is not MPLS aware on outside interfaces. Previously I posted on this list (based on the documentation that I was provided) that the match-in-vrf keyword that is available on the 7200 is not needed on the ASR because supposedly this behavior was the default behavior of the ASR. This is not true. It is not the default behavior and match-in-vrf is not supported at all in XE. Essentially you can only use VRF NAT in XE in the traditional NAT PE way with the NAT outside interface being in the main routing instance and NATing between a VRF and the main routing instance with all the restrictions that have always applied to this kind of NAT. So.. I ask again is anyone actually using NAT with VASI on an ASR and what does that config look like? ___ 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] Hierarchical QoS issue...
I have a hqos setup with a parent and child policy. You can set the queue-limit at both the parent and child levels. I am wondering if anyone had any insight other thoughts and what to set the queue-limit to at the parent and child level? Lets say on a 150mbps shaper that is pushing voice/web/e-mail/bulk traffic %15/%30/%40/%15 would be a typical mix at any given point... ___ 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] VRF-ish solution for L2 interfaces?
There are virtual-switches on Juniper MXs which do precisely what you are asking for. Each virtual-switch has the entire VLAN space and their own spanning-tree configuration. From: Garry g...@gmx.de To: randal k cisco...@data102.com Cc: cisco-nsp cisco-nsp@puck.nether.net Sent: Wed, April 6, 2011 2:33:36 PM Subject: Re: [c-nsp] VRF-ish solution for L2 interfaces? On 06.04.2011 18:16, randal k wrote: NSP'ers, For unfortunate reasons I am asking the collective if there is a way to do VRF-lite style segragation for layer-2 interfaces. Situation is that I have a 6509, and I need to make a single blade on the chassis have a completely separate VLAN database from the rest of the chassis, effectively letting me use a VLAN twice on the chassis without allowing them to talk to each other. Could something like the UNI/NNI port types that are used on ME-switches like the ME3400 be a possibility? If you have a switch with several ports configured as UNI ports in the same VLAN, they won't be able to talk to each other, even though they are in the same VLAN. All traffic is required to go out via NNI uplink ports ... (not sure whether this feature is available on the 6500 series though) -garry ___ 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] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips)
This could lead to some frustration when connecting to devices with auto-mdi... as auto-neg is required for auto-mdi to work... From: Tassos Chatzithomaoglou ach...@forthnet.gr To: cisco-nsp@puck.nether.net Sent: Fri, August 20, 2010 11:38:34 AM Subject: Re: [c-nsp] The myths of autonegotiate vs forced (was: full duplex mismatch speed - dynamips) We have EoSDH equipment (by NSN) which is indeed not able to auto-negotiate. The strange thing is that older cards supported auto-negotiation, while newer ones do not -- Tassos Andriy Bilous wrote on 20/08/2010 13:45: I started to believe after your post that it could be true as we have the same hand over from our EoSDH. That is on fiber and having speed nonegotiate on those ports annoys the hell out of me. Another case - multispeed media-converters which are rare guest by ISPs I guess. The lack of optical sockets on old ISRs forced many people to use them and having autoneg there isn't the best thing one could do. On Fri, Aug 20, 2010 at 10:20 AM, Mark Tinkamti...@globaltransit.net wrote: On Friday, August 20, 2010 03:34:24 pm Mikael Abrahamsson wrote: +1 on the use autoneg unless you really have to force duplex. We have a customer that connects to us over Gig-E, but their end is an EoSDH implementation. As it were, that SDH box either won't auto-neg (which I can't believe), or they're too scared to make it so. They're just about the only customer we're hard-coding for, and less than 1% of our customers don't connect to us via Ethernet. Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] The myths of autonegotiate vs forced
Its an ASIC thing. What you can configure the port to do is only negotiate at a subset of speeds it is capable of. I think this is actually a feature of the ASIC, not software per se. I'm guessing. From: Peter Rathlev pe...@rathlev.dk To: Jim Getker (getker) get...@cisco.com Cc: cisco-nsp@puck.nether.net Sent: Fri, August 20, 2010 3:36:27 PM Subject: Re: [c-nsp] The myths of autonegotiate vs forced On Fri, 2010-08-20 at 14:58 -0500, Jim Getker (getker) wrote: The 6K gigabit copper ports support speed auto 10 100. Hm... it actually does support speed auto 10 100, but speed auto 100 returns an error (WS-X6748-GE-TX): Switch(config)#int gi1/1 Switch(config-if)#speed auto 100 Speed autonegotiation subset is not supported on this interface Switch(config-if)#speed auto 10 100 Switch(config-if)# This confuses a novice like me. Maybe the output could be adjusted a little? :-) (And why support 10/100 only and not 100 only anyway? Standards compliance of some kind?) -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] VRF-Aware NAT in ASR1k
I believe the limit is 500 *pairs* of interfaces... We are using the ASR too for this exact thing. From: Matthew Melbourne m...@melbourne.org.uk To: Neil Fenemor neil.fene...@fx.net.nz Cc: cisco-nsp@puck.nether.net Sent: Sat, August 7, 2010 9:04:37 AM Subject: Re: [c-nsp] VRF-Aware NAT in ASR1k Yes, I saw VASI Enhancements Phase I in the latest ASR 3.1S release notes. There is a limit of 500 VASI interfaces which may be an issue for multiple customer VRFs. Basically, the requirement is to NAT hosts within hosted customer private networks (VRFs) to another private range which makes them available and routable from our management systems, and additionally provides limited Internet access to update servers, etc. -Original Message- From: Neil Fenemor [mailto:neil.fene...@fx.net.nz] Sent: 07 August 2010 02:55 To: Matthew Melbourne Subject: Re: [c-nsp] VRF-Aware NAT in ASR1k Hi Matthew, Have you looked at VASI at all? It's a reasonably recent addition to the ASR1k codebase, but does some interesting things. Cheers, neil On 6/08/2010, at 8:52 PM, Matthew Melbourne wrote: Hi, Is it possible to implement VRF-Aware NAT on the ASR1k, specifically NAT between two different VRFs? Ideally, I have a requirement to NAT between customers' VRFs and a management VRF and from customers' VRFs to the global table (for limited Internet access). Cheers, Matt -- Matthew Melbourne ___ 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/ -- Neil Fenemor Señor Network Engineer FX Networks (m) 021 978 078 (e) neil.fene...@fx.net.nz (w) http://www.fx.net.nz/ (p) 04 498 9565 (f) 04 498 9649 Level 3 FX Networks House 138 The Terrace Wellington No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3056 - Release Date: 08/07/10 07:28:00 ___ 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] VRF-Aware NAT in ASR1k
You do not have to use NVI. We require the VASI functionality, so if we run out.. then we will have to buy more ASRs. Each customer has their own VRF and there are between 1 and 4 VRFs they are all converging on. Its all VRF lite for us, so the VASI interfaces are always outside NAT interfaces, and the customer-facing and services-facing interfaces are inside (providing us overload in both directions). Not every customer talks to all 3 or 4 of the service area VRFs. So its up in the air as to how many customers will be supported with 500 pairs. In your case, you have one service area: the mgmt VRF. So you could support about 500 customers potentially on one ASR using VASI. Also keep in mind that the NAT sessions themselves are not stored in main memory, but a much smaller high-speed memory area. The 20G ESP supports 512k sessions globally, the 10G supports 256k and below that is 128k I believe... From: Matthew Melbourne m...@melbourne.org.uk To: Derick Winkworth dwinkwo...@att.net; Neil Fenemor neil.fene...@fx.net.nz Cc: cisco-nsp@puck.nether.net Sent: Sat, August 7, 2010 10:22:07 AM Subject: RE: [c-nsp] VRF-Aware NAT in ASR1k So, are you doing something like: interface vasileft1 vrf forwarding MGMT ... interface vasiright1 vrf forwarding CUST-1 ... interface vasileft2 vrf forwarding MGMT ... interface vasiright2 vrf forwarding CUST-2 ... Do you have to perform NAT using NVI between VRFs. The limitation here may be that ~500 pairs may not be enough. The only other option I can see is to NAT the hosts within the Customer VRFs into the global table and provide some upstream firewalling for external connectivity? Cheers, Matt From: Derick Winkworth [mailto:dwinkwo...@att.net] Sent: 07 August 2010 15:53 To: Matthew Melbourne; Neil Fenemor Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] VRF-Aware NAT in ASR1k I believe the limit is 500 *pairs* of interfaces... We are using the ASR too for this exact thing. From: Matthew Melbourne m...@melbourne.org.uk To: Neil Fenemor neil.fene...@fx.net.nz Cc: cisco-nsp@puck.nether.net Sent: Sat, August 7, 2010 9:04:37 AM Subject: Re: [c-nsp] VRF-Aware NAT in ASR1k Yes, I saw VASI Enhancements Phase I in the latest ASR 3.1S release notes. There is a limit of 500 VASI interfaces which may be an issue for multiple customer VRFs. Basically, the requirement is to NAT hosts within hosted customer private networks (VRFs) to another private range which makes them available and routable from our management systems, and additionally provides limited Internet access to update servers, etc. -Original Message- From: Neil Fenemor [mailto:neil.fene...@fx.net.nz] Sent: 07 August 2010 02:55 To: Matthew Melbourne Subject: Re: [c-nsp] VRF-Aware NAT in ASR1k Hi Matthew, Have you looked at VASI at all? It's a reasonably recent addition to the ASR1k codebase, but does some interesting things. Cheers, neil On 6/08/2010, at 8:52 PM, Matthew Melbourne wrote: Hi, Is it possible to implement VRF-Aware NAT on the ASR1k, specifically NAT between two different VRFs? Ideally, I have a requirement to NAT between customers' VRFs and a management VRF and from customers' VRFs to the global table (for limited Internet access). Cheers, Matt -- Matthew Melbourne ___ 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/ -- Neil Fenemor Señor Network Engineer FX Networks (m) 021 978 078 (e) neil.fene...@fx.net.nz (w) http://www.fx.net.nz/ (p) 04 498 9565 (f) 04 498 9649 Level 3 FX Networks House 138 The Terrace Wellington No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3056 - Release Date: 08/07/10 07:28:00 ___ 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/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3056 - Release Date: 08/07/10 07:28:00 ___ 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] Match-in-VRF
This limits the scope of a NAT rule/translation to the VRF specified in the NAT rule. The most common issue is that outside NATs were always global, even if you specified a VRF. You could not re-use the same translated address (pool) for another VRF / different real address... Essentially this command ensures you have real per-VRF inside and outside translations which means you can re-use real and NAT'd addresses on a per VRF basis without any issues. This is now the default/native behavior of IOS XE. There is no match-in-vrf on that platform because it is not needed. From: Oliver Boehmer (oboehmer) oboeh...@cisco.com To: David Warner davidwarner1...@yahoo.com.au; cisco-nsp@puck.nether.net Sent: Wed, August 4, 2010 3:25:32 AM Subject: Re: [c-nsp] Match-in-VRF Was hoping someone could advise with regards to what the NAT keywords match-in-vrf achieves? We typically use this in production. However, Ive just been labbing NAT config using VRF lite and it doesnt appear to change behaviour and Cisco literature is unclear. With or without it, translations occur in the relevant VRF. not an expert, but do you use overlapping pools between vrfs? If you are not, you don't need match-in-vrf.. take a look at http://docwiki.cisco.com/wiki/Category:NAT oli ___ 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] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs
Does it have to be a switch? As of 12.4(24)T3 you can do this on ISRs and 7200s... From: Frank Bulk - iName.com frnk...@iname.com To: sth...@nethelp.no Cc: cisco-nsp@puck.nether.net Sent: Thu, July 8, 2010 10:09:59 PM Subject: Re: [c-nsp] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs Thanks for explaining the semantical differences. What I'm looking to do is the termination -- wouldn't the ME3400 do the trick? Frank -Original Message- From: sth...@nethelp.no [mailto:sth...@nethelp.no] Sent: Thursday, July 08, 2010 3:56 AM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs What is the cheapest Cisco desktop switch that supports Q-in-Q? Is it the ME-3400G-2CS-A? We prefer the encapsulation dot1q x second-dot1q y approach. Your last sentence doesn't make sense here. Q-in-Q generally refers to *tunneling* one VLAN trunk through an L2 network by adding an extra VLAN tag in front of the existing VLAN tag. encapsulation dot1q x second-dot1q y is used to *terminate* a dual tagged VLAN connection (typically an IP termination). This is very different from *tunneling*. So - do you want tunneling or termination? I don't believe there are any Cisco desktop switches which can IP terminate a dual tagged VLAN connection. There are, of course, plenty of desktop switches which will do 802.1Q tunneling. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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] Shared vs Independent VLAN learning with Q-in-Q
Does anyone know if there are any Cisco platforms that support IVL with Q-in-Q so the mac lookup is a 72-bit field essentially (both VLANs and MAC address). Just curious... ___ 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] Experience on MPLS-TP (MPLS Transport profile
I'm curious about what MPLS-TP will turn out to be. Its still somewhat nebulous I think. I have been following the FCoMPLS updates and saw where they said they would leverage MPLS-TP for the 'reliable' portion of MPLS... Yet I haven't exactly seen where there is anything like that defined clearly in MPLS-TP. ___ 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] maximum configurable static NATs on a 7200/NPE-G2...
You're right... I ran a script last night that configured 58000 static NATs. Of course, service compress-config was necessary :-) but it took it with no problems... From: Rodney Dunn rod...@cisco.com To: Derick Winkworth dwinkwo...@att.net Cc: cisco-nsp@puck.nether.net Sent: Fri, April 2, 2010 7:34:35 AM Subject: Re: [c-nsp] maximum configurable static NATs on a 7200/NPE-G2... Memory from what I recall. Rodney On 4/1/10 4:47 PM, Derick Winkworth wrote: All: Anyone know what the maximum number of configurable static NATs is on a 7200/NPE-G2? Is it just a function of memory or is there a hard limit somewhere? Derick ___ 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] match-in-vrf with NVI
I did this last night, and while it took the config without complaining, the second one overwrote the first one in running-config. What I am really looking for is this functionality in NVI.. ip nat source static 10.1.1.9 205.141.232.13 vrf SUB001-VRF match-in-vrf ip nat source static 10.1.1.4 205.141.232.13 vrf SUB002-VRF match-in-vrf That would be outstanding. From: Arie Vayner (avayner) avay...@cisco.com To: Derick Winkworth dwinkwo...@att.net; cisco-nsp@puck.nether.net Sent: Fri, April 2, 2010 1:44:08 AM Subject: RE: [c-nsp] match-in-vrf with NVI Derick, From what I can see, since 12.2(33)XND you can configure duplicate outside NAT mapping with different VRFs without the need for the match-in-vrf keyword. It would just use the VRF names in the NAT statements: So this config should work: router(config)#ip nat outside source static network 172.1.1.0 16.1.1.0 /24 vrf Cust_A router(config)#ip nat outside source static network 172.1.1.0 16.1.1.0 /24 vrf Cust_B Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth Sent: Thursday, April 01, 2010 22:33 To: cisco-nsp@puck.nether.net Subject: [c-nsp] match-in-vrf with NVI All: Anyone know when the match-in-vrf keyword will be supported with NAT NVI? I really would like to see this! Derick ___ 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] match-in-vrf with NVI
All: Anyone know when the match-in-vrf keyword will be supported with NAT NVI? I really would like to see this! Derick ___ 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] maximum configurable static NATs on a 7200/NPE-G2...
All: Anyone know what the maximum number of configurable static NATs is on a 7200/NPE-G2? Is it just a function of memory or is there a hard limit somewhere? Derick ___ 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] match-in-vrf with NVI
Come to think of it, does anyone know when match-in-vrf will be supported at all on the ASR? It might have made it into the 2.5 release... Can anyone verify that? From: Derick Winkworth dwinkwo...@att.net To: cisco-nsp@puck.nether.net Sent: Thu, April 1, 2010 2:32:39 PM Subject: [c-nsp] match-in-vrf with NVI All: Anyone know when the match-in-vrf keyword will be supported with NAT NVI? I really would like to see this! Derick ___ 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] 12.4 IOS recommendation for 7206
Agreed on the 12.4(15)T train. Pick the latest release of this. No new features have been introduced in this train since T7 or T8 I believe. Going forward, all releases will be bug-fix only. As I understand it. From: Dale Shaw dale.shaw+cisco-...@gmail.com To: aptg...@gmail.com Cc: cisco-nsp@puck.nether.net Sent: Mon, December 14, 2009 3:03:43 PM Subject: Re: [c-nsp] 12.4 IOS recommendation for 7206 Hi, On Tue, Dec 15, 2009 at 7:42 AM, sky vader aptg...@gmail.com wrote: Any recommendation for a stable enterprise IOS [for 7200] supporting following feature set. [...] There was a thread on this in the last week or so. I'm personally happy with 12.4(15)T - we run it on 12 or so 7200s (NPE-400s, NPE-G1s and NPE-G2s) and it's pretty solid. We don't run MPLS, BGP or OSPF on them (we're an EIGRP shop), but all your other boxes are ticked. cheers, Dale ___ 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] ASR1004 vs 7606(RSP720-CXL)
..and now you have a sh*tpile of boxes in your environment running different versions of software with varying features for management and so forth. And if your like most IT companies, some mgmt turd will eventually let maintenance go on some of these boxes are not stick with the architectural plan and it will turn into spaghetti because they look at all these boxes and they think we have tons of empty slots and ports. I guess to some extent this is unavoidable. From: Dobbins, Roland rdobb...@arbor.net To: Cisco-nsp cisco-nsp@puck.nether.net Sent: Fri, November 27, 2009 10:03:45 PM Subject: Re: [c-nsp] ASR1004 vs 7606(RSP720-CXL) On Nov 28, 2009, at 11:48 AM, Justin Shore wrote: A 65/7600 with IPSec SPAs, FWSMs 67xx 10G LCs feeding Nexus or 4900 top-of-rack switches would be such a solution. Note that w/N7K, you get usable NetFlow, per-interface uRPF configuration, and less ACL constraints, all of which are extremely useful. If customers insist on placing stateful firewall chokepoints and such in front of their servers, 6500s can be used as service switches. They can handle IPSEC, as well. So, this simply leaves MPLS termination as the primary issue, does it not? If this is the case, then placing an MPLS-capable box at the DC distribution gateway level takes care of this, yes? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken ___ 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] Router advice
Its not like we can run Cisco IOS on any other vendor's equipment. If I buy an ISR from Cisco, I have to pay them additional money to use the software that only Cisco can create.. for that box? Its an arbitrary blood-rock scheme. You pay twice to use the equipment you buy from them. Its an argument against licensing in general in cases where you are dealing with *both* closed software and closed hardware from the same vendor. Nevertheless, its reality now. It would be interesting to see key-generators or IOS jailbreakers soon. From: Doug McIntyre mer...@geeks.org To: cisco-nsp@puck.nether.net Sent: Sun, November 22, 2009 1:21:27 AM Subject: Re: [c-nsp] Router advice On Thu, Nov 19, 2009 at 11:53:22AM -0800, Seth Mattinen wrote: Doug McIntyre wrote: On Wed, Nov 18, 2009 at 01:28:53PM -0800, Seth Mattinen wrote: Ivan wrote: You may also want to check out the new ISR models (ISR G2 http://www.cisco.com/go/isrg2). I get the impression from reading about the new universal image that they phone home for license keys before it will activate features. Is this accurate? No, you get base level features out of the box, and you can activate the advanced features that are licensed on a trial basis for x days until you can get your PACs from the Cisco license website and apply it permamently to that box. Are they backup-able? That is, can you get the device back to full functionality from local copies without access to the website? What happens if hardware gets stolen or somebody yanks the flash card and loses it? Can you still keep spares in storage? The PACs are tied to the serial number of the box. You can backup the number you get back from the PAC tool, but if you swap hardware, then you need to go to TAC to get a new PAC. Sure, you can stock spares, then if you need to bring up a spare box, you get 30 days of trial license, and you go to TAC and tell them you need a new PAC because the old box is borked, and you work it out with TAC. If any of your disaster items happen, you go back to TAC and explain while running live on your 30 day trial license to get new PACs. Its a very simple solution that in practice works easily. You seem to want to pick on this thread for Cisco's license enforcement. I don't work for them. But I can certainly see a need for it from their point of view. I do already use Cisco licensing on other hardware that has been doing this exact thing for sometime (ie. SanOS and PIX), and haven't encountered any the sky-is-falling problems with any of it. It seems fair to me, compared to what I'd guess are many IOS boxes not being properly licensed for what they are running due to Cisco's pretty open licensing policies of years past. ___ 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] backup lsp/second path-option priority...
I am trying to configure something like this: A primary LSP with 5g bandwidth... and lower priority.. A secondary LSP with 500m bandwidth and higher priority.. Essentially, if all links are up, then the primary paths will be used and we will have maximum bandwidth utilization... If we loose a link, then the secondary LSPs will kick in for those failed primaries, and if necessary, the secondary LSP will preempt other primary LSPs. Any thoughts on how to accomplish this in IOS? Thanks... ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco vs. Juniper
### The MX-FPC swallows two whole DPC slots. In an MX240, that's just a waste of time. You're better of getting an M120 or M40e (M40e if you don't need STM-64/OC-192). This makes the MX480 or MX960 more appealing when used with the MX-FPC. But then, that's not in the same space as the ASR1000 series anymore. # Really? The price difference between a 240 and 480 has always made me wonder why someone wouldn't just buy the 480. The difference is small. We'll have to wait and see what the answer is going to be to the ASR. I suspect it will be the SRX, because of the integrated services and flow-based QoS. From: Mark Tinka mti...@globaltransit.net To: Brian Spade bitkr...@gmail.com Cc: sth...@nethelp.no; cisco-nsp@puck.nether.net Sent: Wed, November 4, 2009 4:37:16 AM Subject: Re: [c-nsp] Cisco vs. Juniper On Wednesday 04 November 2009 09:10:33 am Brian Spade wrote: Mark, what's your thoughts on the MX240? I'm curious now since you state not to get you started. :-) Really... :-)? Well, the MX240 is probably the smallest of the bunch (not considering the MX80, as it probably won't be modular enough to provide SONET/SDH support). Again, Cisco are slightly better in the segment, at present. Juniper might do well to refresh the M7i/M10i. And I've said this to them, time and time again. As much as I adore Juniper, and with due respect to the ingenious design of the M7i/M10i platform, the ASR1000 levels (and perhaps, exceeds) the playing field in this platform space. Cheers, Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Network Liberation Movement???
http://networkliberationmovement.net/ 15 hours some big announcement? Anyone know what this is? ___ 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] [j-nsp] juniper trinity
You are mistaken. They use the ez-chip in non Q cards as well for the MX. I think you only need to look at what the Q card does and you will see it does not marry up very well to the traffic management feature of the ez-chip... I think the previous poster was correct. Ethernet framing and MAC lookup is all they are used for. From: Roger Gabarit roger.gaba...@gmail.com To: Richard A Steenbergen r...@e-gerbil.net Cc: Juniper-Nsp juniper-...@puck.nether.net; cisco-nsp@puck.nether.net Sent: Saturday, October 24, 2009 5:56:18 AM Subject: Re: [j-nsp] [c-nsp] juniper trinity On Fri, Oct 23, 2009 at 12:54:40PM -0700, Marlon Duksa wrote: This Trio or Trinity, whatever they call it is internally grown technology...a combination if EZChip + I-chip functionality. Plus I don't think it is a good strategy for Juniper to use third party vendors as this will not give them differentiation... I've heard people make this argument, but it is absurd. The only thing EZChip is used for on the MX is basic Ethernet framing and MAC lookup. No doubt it was much cheaper and easier for Juniper to use an off the shelf chip for this than to spin their own just to do this. To go from there to claiming that the rest of the forwarding/queuing/etc will be the same as a Cisco platform is absolutely insane, the only thing they have in common is the Ethernet frame. I'm sorry not to agree on this one. Unless you can prove me that I'm wrong :) - Juniper uses the chips on the MX series only in -Q- Line Cards. So when you use something only in advanced QoS line cards, there's something related to QoS, definitely. - Check the description of EZChip NPs on their website ( http://www.ezchip.com), they are built to provide the Ethernet framing and MAC lookup AND traffic management). Neither Cisco nor Juniper would buy a chip to have it do only 20% of what it could do. Cisco uses the chip in the ES+/ES40 and in ASR 9k cards. Quote : EZchip’s NP-2 is a highly-flexible network processor with integrated traffic managers providing wire-speed packet processing and advanced flow-based bandwidth control. The NP-2 offers the speed of an ASIC combined with the flexibility of a programmable microprocessor. It provides the silicon core of next-generation Carrier Ethernet Switches and Routers (CESR). Through programming the NP-2 delivers a variety of applications such as L2 switching, Q-in-Q, PBT, T-MPLS, VPLS, MPLS and IPv4/IPv6 routing. The integrated traffic management provides advanced QoS for flow-based service level agreements (SLA) and enabling triple-play services (voice, video, data). All that stuff makes me think that the 2 vendors will not release any 100G ports (*with advanced QoS*) on MX or ASR until the EZChip NP4 is produced (not only prototypes). That gives by the way 2 years advance to Alcatel-Lucent from that point of view, because their 100G NP has been ready since last year. Funny market :) But well, let's wait for Juniper's next week announcement. Roger ___ juniper-nsp mailing list juniper-...@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-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] BFD static in VRF...
Anyone else try doing this? I'm on 12.2(33)SRC4 on a 7200 w/NPE-G2 and for some reason the vrf option in ip route static bfd is not showing up... I don't see anything in the release notes about this or in bug toolkit... Anyone thoughts? ___ 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 for 7206VXR, SRD2a or SRC4?
12.4(15)T10 Its the third or fourth bug-fix only release in the 12.4(15)T line of code... You have a lot of features you want to enable... I would try this one first.. From: luismi asturlui...@gmail.com To: Gert Doering g...@greenie.muc.de Cc: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Sent: Monday, September 21, 2009 5:25:43 AM Subject: Re: [c-nsp] IOS for 7206VXR, SRD2a or SRC4? yes, I know we are going to use... EIGRP, BGP, ACL, PBR, reflexive ACLs, HSRP, GRE tunnels, multicast, VRFs, EEM, SLA, SNMP, Netflow... I would like to go also for BFD, OSPF and/or MP-BGP in the future. ___ 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] EIGRP SoO question
I'm trying to wrap my head around how this works. There is BGP SOO. This is where routes are tagged as they are redistributed into BGP so that other PEs attached to the same customer site do not push the routes back into the site. This accounts for the PE - CE direction. In the opposite direction, it seems there are actually two different mechanisms. There is a) EIGRP SOO. This is an EIGRP extension/tag that the PE uses so it does not re-introduce a route back into the PE iBGP cloud. Routes are tagged going into a site, and if the site is dual-homed and the route comes back to another PE that is appropriately configured, this other PE will see the tag and not re-advertise that route back into BGP. b) BGP cost community. This attribute carries the EIGRP metric of the route that is being redistributed into BGP. At another PE (presumable a PE attached to a multihomed site), this attribute tells BGP to compare the EIGRP cost embedded in the attribute directly to an EIGRP route learned from the CE. This attribute is compared before any other BGP attribute. So I guess why do we need both (a) and (b)? The documentation for this is shoddy. Derick Winkworth CCIE #15672 ___ 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] TCP Reset
What Cisco devices are in the path? We had to configure an ACL on a 7200 denying inbound TCP RSTs, because of a bug where there there 7200 (if it was doing PAT) was erroneously sending the RST to the wrong connection. Long story short, NAT session #1 would properly terminate on the 7200, but the server would think the port was still open. The server would timeout and send a RST four minutes later. Within that four minute window the 7200 would reuse the same source port for a NAT session #2. When the server's four minute timer went off for the first session, and the RST was sent... the 7200 would send the RST to the client in the second session, thus erroneously terminating a valid TCP session. There is a bug ID for this somewhere Hitesh Vinzoda wrote: Dear All, I m facing a problem from some clients behaving suspiciously when they telnet to squid proxy. ( 10.4.188.180) After TCP Syn request by client the server is responding with RST. Wireshark logs from client is attached. Comments are invited for this case. Thanks in advance Ronnie ___ 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/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.35/2123 - Release Date: 05/19/09 17:59:00 ___ 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] Certification Ethics
Keep in mind that the value of the CCIE isn't that you can recall an infinite number of facts about bits, bytes, headers, protocol states, protocol errors, protocol election rules, model numbers, product specifications, and router commands, and the output of every router command... at any given moment without context or warning. If you came up to me in the middle of the day out of nowhere and asked Whats the difference between PIMv1 and PIMv2 DR election? I would have to stop and think. I would probably tell you to go look it up. Because that is what I do when I don't know or can't remember. Its not about how much useless information you can cram into your head. Its how you apply the facts once you have them. These facts by themselves are useless without a problem you can apply them too. You would be a bad engineer if you didn't verify anyway that it works the way you expect it too... Which means I would likely say I'm not sure, lets look it up. I re-memorize what I need to know to recert every 21 months. In between those times, if I don't touch IPv6, then I probably will forget it very fast. I'm busy. I have other things to remember and think about. So hearing you say that some CCIE, or multiple CCIEs, didn't remember fact x and therefore you call into question the value of the CCIE as a certification... I guess that demonstrates how badly you are missing the point. Derick Winkworth CCIE #15672 Peter Rathlev wrote: On Mon, 2009-05-11 at 16:16 -0500, Chris T wrote: -Am I completely out of line here? If so, please tell me how. I have heard about things not completely unlike what you describe. I have myself been very bored the two times I tried attending CLP courses so I don't do that anymore. It's a waste of time. I assume Cisco is only naturally interested in people attending the courses. From what I've heard they make more than a few pennies from selling licenses to approved material. -What is an appropriate time to study for a single Cisco test (not expert level)? I understand there is a great amount of variance, but ballpark figures are what? 100 hours? 500 hours? 1000 hours? Hm... I used a weekend of preparation for each of three of the exams for CCIP (BSCI, QOS and MPLS) reading through mostly Cisco Press material. I took the BGP exam without preparation, though I took O'Reilly's book on BGP with me to bed. Of the four exams the BSCI was the most challenging since it covered a lot of subjects, some of which I hadn't had any practical experience with, like IPv6. I'm always a little nervous at exams, but I've had no problems only using what I had learned by working with the technology. -What practice test material do YOU think is or is not fair for preparation for a Cisco certification test? Anything you can come by without breaking laws is fair. :-) If you've asked Cisco specifically about some learning partner and they didn't want to even consider looking at it, it's fair game. I personally don't think the certifications are worth very much in the first place. I've been having discussions with CCIEs that had misunderstood some of the most basic things (like MED being an intransitive attribute) and it didn't just happen once. If I were to judge someone in e.g. a hiring situation I would primarily look at what (s)he'd been working with and then use maybe half an hour assessing their technical merit. (I'm not in that position though, and that's probably for the best.) The certifications do open some doors though. Management is impressed and it gives leverage in many situations, like trust me, I'm a professional or when negotiating salaries. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.325 / Virus Database: 270.12.24/2107 - Release Date: 05/10/09 07:02:00 ___ 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] GET-VPN and BGP
We have deployed several networks now with GET, and now that we are used to it.. there is no looking back at DMVPN. When it comes to troubleshooting on the CE device, I feel GET is much easier. There is no overlay network with GET. Mike Louis wrote: Dear list, I am working with a customer who is migrating from a static MPLS VPN to a BGP based MPLS VPN. Today they currently have a hub and spoke IPSEC VPN running overtop of their MPLS WAN. Once they migrate to BGP they would like to have a solution that will support the any-to-any connectivity the MPLS WAN offers and be able to scale well to many sites 50. What are my options here. Configuring point to point static IPSEC tunnels are not practical. I see DMVPN and GET-VPN as practical options. Any thoughts or opinions on why they should consider one or the other? Any feedback is greatly appreciated. Mike Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ 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/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.3/1974 - Release Date: 02/26/09 14:51:00 ___ 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] EIGRP router-id in VRF
All: We went to production with a solution that we labbed, but now we are seeing some odd behavior. We added VRFs to our configuration and the EIGRP router-id for routes redistributing into EIGRP from BGP was always the highest IP address in the *VRF*, not the loopback interface in the global routing table. In fact, I see this is the behavior now for the initial customers we turned up. We turn up a third customer in the same fashion as far as I can tell, but now the router-id is the loopback in the global routing table. Can someone clarify what the deal is here? ___ 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] Router requirement
7200vxr Pete Barnwell wrote: Hi, Wonder if anybody can help me with selecting the right router for CPE? It needs to be able to handle 100Mb/s delivered over FE, doing a bit of QoS and a few ACLs but no dynamic routing protocols. Thanks Pete ___ 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/ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.10.23/1953 - Release Date: 02/14/09 18:01:00 ___ 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] OT: CCIE Lab
You should subscribe to the CCIE groupstudy list. See http://www.groupstudy.com/ Studying. Practice. Lots of practice. I purchased the InternetworkExpert end-to-end program and I completed all 30 of the practice labs plus a couple of mock labs (Brian and Brian were great!). I did the live on-line classes and I watched the prerecorded ones repeatedly. I listened to the audio classes repeatedly. I also took the first week of the NetMasterClass training. Bruce, Val, and Bob are great! I took notes in several different forms. I used a tool called freemind to make a massive mind-map. I took traditional notes and highlighted items in various texts. I made close to one thousand flashcards for particular items I needed help remembering. All said, I spent 8 months, 4-12 hours a day, 5-6 days a week preparing for the lab. Then I took and passed the lab. Personally the one thing that helped me the most, more than anything, was to admit that I knew far less about networking than I previously thought. I humbled myself greatly and I approached every topic as if I was learning it anew. I had a lot of false notions about how things actually worked. Also, you will realize during the actual hands-on application of the various topics... that there are a lot of dead trees in the form of books (including CiscoPress books) that are written very poorly or are just plain wrong. Even Cisco's documentation is very poor or wrong in a lot of places. The only way to really wrap your head around some things is to read from multiple sources about it AND to then build it in a lab and debug it.. in various scenarios and environments. A particularly enlightening exercise to try and reduce any scenario or functionality to the absolute minimum amount of commands needed to do it. Then think carefully on what you removed and what the actual purpose of it is. Then take copious notes. The end. Mad Unix wrote: Can you please tell me, what *you* did to master Ccie Lab? your iput really appreciated. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.10.23/1952 - Release Date: 02/13/09 18:29:00 ___ 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] 6500 stable code
You need to reduce the number of features you are actively using in the switch, pick an IOS, put in the lab, fully regression-test it with load-testing (and test all possible functions and failures of all protocols and features) then deploy. Oh wait... thats not possible is it? You need to do this soon right? You don't have a year to develop a test plan and scripts and fully test it? By the time you do that, the software you are testing will have been deferred or have an advisory on it for major defects. hmmm... Well spin the barrel, close your eyes, and pull the trigger. From: Jon Lewis jle...@lewis.org To: cisco-nsp@puck.nether.net Sent: Wednesday, January 28, 2009 2:01:25 PM Subject: [c-nsp] 6500 stable code I'm getting ready to spin the IOS roullette wheel again with a 6500 that's been running 12.2(18)SXF12a as a hot spare. Safe Harbor says 12.2(18)SXF13 is Recommended and the last version of SXF they plan to say anything about. The pdf link http://www.cisco.com/en/US/docs/safe_harbor/campus/12_18_sxf13/Campus_12.2(18)SXF13.pdf is dead. In the software center, I see there have been a few additional releases, and in fact if I try to get 12.2(18)SXF13, I get a warning that there have been serious issues found in it and 12.2(18)SXF14 is recommended. When I try to get 12.2(18)SXF14, I see it's got even more issues, and 12.2(18)SXF15 is recommendedThe first one I get to that doesn't give me warnings of serious issues and reommend the next release is 12.2.18-SXF15a. So...has anyone been running 12.2.18-SXF15a (which is apparently the latest of SXF) in a BGP/OSPF environment and care to chime in about its stability or lack thereof? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Logical Router Segmentation
Juniper supports it well. The EX series 1U switches are pretty decent actually. But, again... he might be able to get this done without VRFs... Brad Hedlund (brhedlun) wrote: The term VRF-Lite comes from when Cisco started delivering VRF capabilities across all Catalyst L3 platforms, even the low end. Many vendors do support VRF on their high end routers and switches, but few have comprehensive VRF support from the high end all the to the low end. MBGP is not required for L3 VPN's. That's the beauty of VRF-Lite end to end. A customer can deploy a handfull of L3 VPN's within their own campus without MPLS or BGP. Sent from my iPhone Brad Hedlund On Jan 11, 2009, at 10:20 AM, Brandon Bennett benn...@gmail.com wrote: Vrf-lite is just a Cisco term for utilizing VRFs when no MPLS is present. Any vendor who supports VRFs support VRF-lite. In all honesty it's a stupid term as VRF technology isn't tied to MPLS at all. Yes vrf is required for l3 vpns but so is mBGP and we don't have mBGP-lite :) -Brandon Sent from my iPhone On Jan 10, 2009, at 10:58 AM, Brad Hedlund brhed...@cisco.com wrote: On 1/10/09 8:57 AM, Chris Burwell cburw...@gmail.com wrote: I am fairly certain the 8212zl can accomplish what was described here, the problem will be finding documentation on how to configure everything. Chris, I would be curious to see what you come up with. The 8212 feature list on HP's website doesn't show anything similar to VRF-Lite. I'm pretty sure VRF-Lite like capabilities are unique to Cisco. Let me know if you find otherwise. Cheers, Brad Hedlund bhedl...@cisco.com http://www.internetworkexpert.org ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.5/1886 - Release Date: 1/10/2009 6:01 PM ___ 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] Logical Router Segmentation
You might be able to do this without vrf-lite, with something like PBR... You only have two domains and each domain only has two logical interfaces. So you could create four policies, one for each interface that sets the egress interface that you want all traffic coming into that interface to go to... so in the case of the internet interface... the policy would just direct all inbound packets to the firewall ethernet interface... Chris Burwell wrote: Brad, Thank you for the suggestion! http://www.hiddenone.net/Topology.pdf That PDF has two pages. Page one represents our current topology and page two represents what I would like to do. The red lines on page two represent what would be outside of our network (the two connections). - Chris On Fri, Jan 9, 2009 at 7:10 PM, Brad Hedlund brhed...@cisco.com wrote: On 1/9/09 5:52 PM, Chris Burwell cburw...@gmail.com wrote: I am looking for a bit of guidance on logically segmenting an existing router. I appreciate any help! Chris, I think it would help if you drew this up in a Visio, saved it as a PDF, and uploaded it to a URL for folks to look at as they read your overview and questions. Cheers, Brad Hedlund bhedl...@cisco.com http://www.internetworkexpert.org ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.5/1885 - Release Date: 1/9/2009 7:59 PM ___ 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] FWSM - BGP stub vs RHI
RHI is multi-context, BGP stub is not... last I recall. Also I don't think RHI is a licensed feature, its just available with the IOS... BGP stub is licensed for some reason. Vikas Sharma wrote: Hi, In FWSM inplementation, which one is preffered BGP stub or RHI. My low confidecnce in RHI bcos it is the new feature and not deployed extensively. Regards, Vikas Sharma ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.1/1869 - Release Date: 12/30/2008 12:06 PM ___ 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] IPSec L2L tunnel - traffic from IVRF to other VRFs
If security is an issue, put any old router in that will do VRFs and configure it with IOS FW or ACLs... You can put an IOS FW on a stick with VLAN's going to it... Or put an actual firewall in place... From: Ramcharan, Vijay A vijay.ramcha...@verizonbusiness.com To: cisco-nsp@puck.nether.net Sent: Wednesday, December 24, 2008 2:40:53 PM Subject: [c-nsp] IPSec L2L tunnel - traffic from IVRF to other VRFs I've read the doc at http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_vrf _aware_ipsec_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1027 175 and ignoring the restriction about mapping VRF to VRF traffic have tried (unsuccessfully) to circumvent this restriction. Is it at all possible to terminate an IPSec L2L tunnel in VRF A and then have traffic exit that VRF A to reach resources located in VRF B or possibly the global routing table? I see the security implications naturally of allowing traffic from remote sites to leak across VRFs but if it's not possible then is there some way of providing a central service type of resource to a bunch of different sites (assume each site goes into a different VRF) which connect to that resource via IPSec tunnels? [Site A]---IPSec tunnel over Internet---[Hub Router--VRF A--] | [VRF B] | (Central Service) Vijay Ramcharan ___ 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] RSP4 as route server? - seeking suggestions and opinions
Or Vyatta maybe... Masood Ahmad Shah wrote: You can also use JUNOS olive. http://juniper.cluepon.net/index.php/Olive Regards, Masood -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Cory Ayers Sent: Sunday, December 21, 2008 1:45 AM To: Ang Kah Yik Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] RSP4 as route server? - seeking suggestions and opinions I've only been recently tasked with looking into possible (re)uses for this box so I'm not sure how it managed to handle 2 sets of full routes either. 256M RAM will barely handle one BGP feed filtered to /23 (140k routes) The first thing that came to mind when tasked with this was actually Quagga/OpenBGPD. There appears to be a discussion on Linux Gigabit routers on the NANOG-ML but the discussion seems skewed towards forwarding performance rather than BGP scalability. If you're just looking for data gathering, go with Quagga. We've got an old SOHO box (533Mhz, 512M RAM, 512M Flash drive) running a lean install of Fedora with 8 BGP feeds (somewhat filtered) inbound, and another session to route-views. This replaced a 7200 NPE-300 w/256M that couldn't keep up a few years back. Cory ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.19/1859 - Release Date: 12/20/2008 2:34 PM ___ 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] HWIC-3G-* experience?
(1) We've had good experience with this. Decent throughput, but high amount of jitter/latency. Its just another internet access method at this point... it works fine. Really its about the carrier... (2) Cables and antennas as needed for getting the signal required can be expensive if you go through the wrong channels (like Cisco... don't do it!) (3) Sprint has a flat-rate plan thats 100 bucks or so for unlimited usage. They offer great deals on cables and antennas. They also do free site-surveys, noone else does that we talked to. (4) ATT. Variable bill rates. ATT can work something out through their account reps where you will never be charged more than a certain amount every month, but its supposed to be for backup only so if you use it frequenty... you can go through your sales rep to make sure you don't get locked out or whatever. Right now, they offer a service to back-up MPLS circuits, but they manage the endpoint at your site... this is their ANIRA product. You configure VRRP on your router and they configure it on theirs. You configure whatever tracking you want so that when a failure occurs, ATT's ANIRA router takes over and gets you back to the cloud (through the internet though)... (5) Verizon. No variable billing. The best throughput with dual-antennas. They also offer internet-to-MPLS backup like ATT and Sprint, but you get to manage the endpoint. (6) There is no direct-to-VRF type MPLS backup at this time, but all three carriers are rolling it out from what I understand. When this occurs, the card will come up direct to the MPLS cloud. Until then, its VPN tunnel to somewhere over the internet. Permanent IP is available. Some of them can create private subnets on the internet for you... you get a public IP in a /27 or something and it can only talk to other IPs in that /27. hmmm... Seth Mattinen wrote: Does anyone have any experience with the HWIC-3G-* cards in real life? I'm considering emergency access plans using these as opposed to traditional methods, and I'd be interested in any success or horror stories before jumping in. ~Seth ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.6/1765 - Release Date: 11/3/2008 4:59 PM ___ 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] Order-of-operations question about adjust-mss and crypto...
Indeed it does. This is the preferred route. Abandon dealing with fragmentation altogether. Sadly, some MPLS access options (like ethernet access) have a limitation of 1500 byte MTUs in the cloud. My thought is, just do the MSS adjustments at the sites with this limitation. We are seeing some corruption of fragments with GET in 12.4(15)T5. Thats what this is about. So we upgraded to T7 and jacked up the MTUs wherever possible. - Original Message From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: Luan Nguyen [EMAIL PROTECTED] Cc: Derick Winkworth [EMAIL PROTECTED]; Rodney Dunn [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Saturday, November 1, 2008 10:57:09 AM Subject: Re: [c-nsp] Order-of-operations question about adjust-mss and crypto... mtu 1600 on the wan interface also works doesn't require any changes on the lan interfaces :) Lee [EMAIL PROTECTED] wrote: - To: 'Derick Winkworth' [EMAIL PROTECTED], 'Rodney Dunn' [EMAIL PROTECTED] From: Luan Nguyen [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 10/31/2008 02:39PM cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Order-of-operations question about adjust-mss and crypto... The MSS tells the maximum data a host will accept in an TCP/IP datagram. Each side reports the value to the other side and the sending will abide by it. It's all before encryption. So typically like you said, people put ip tcp adjust-mss 1360 on the group member LAN interface and also set ip mtu 1400 on the WAN side hoping for PMTUD to work its magic. Putting both on the WAN interface should work as well, though, I don't quite understand the backside is MPLS statement :)...the packet has to be originated from somewhere. There's a very good paper here on Fragmentation http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper0 9186a00 800d6979.shtml#t3 Luan Nguyen Chesapeake NetCraftsmen, LLC. www.NetCraftsmen.net (blog) http://ccie-security.blogspot.com/ (e) [EMAIL PROTECTED] (aim/yahoo): luancnc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derick Winkworth Sent: Friday, October 31, 2008 11:52 AM To: Rodney Dunn Cc: cisco-nsp@puck.nether.net Subject: [c-nsp] Order-of-operations question about adjust-mss and crypto... If you apply the ip tcp adjust-mss command on an interface that has a crypto statement on it... Does it perform the MSS adjustment on outbound packets before they are encrypted? Does it perform the MSS adjustment on inbound packets after they are decrypted? I know that this is typically placed on a tunnel interface or, for instance, on an ethernet interface of a remote VPN site or something... but I have a case where we have many GET encryped sub-interfaces (each in their own VRF) which are the only logical IP interfaces on the box. The backside is MPLS so there is no place to put the statement there... so I was just going to apply it to the interfaces where the crypto maps are.. not sure if this will work. I'll probably have to lab it up I'm guessing. Derick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Order-of-operations question about adjust-mss and crypto...
If you apply the ip tcp adjust-mss command on an interface that has a crypto statement on it... Does it perform the MSS adjustment on outbound packets before they are encrypted? Does it perform the MSS adjustment on inbound packets after they are decrypted? I know that this is typically placed on a tunnel interface or, for instance, on an ethernet interface of a remote VPN site or something... but I have a case where we have many GET encryped sub-interfaces (each in their own VRF) which are the only logical IP interfaces on the box. The backside is MPLS so there is no place to put the statement there... so I was just going to apply it to the interfaces where the crypto maps are.. not sure if this will work. I'll probably have to lab it up I'm guessing. Derick ___ 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] EIGRP routing failure
What do you mean? The giant counter is incrementing or not? We ran into an issue where the MTUs were not equal and this was causing EIGRP to bounce. The router with the higher MTU was running 12.4 and the router with the lower MTU was running 12.2, and this was causing the router on 12.2 to discard the EIGRP packets as giants. In the logs it looked as though they are bouncing... Mohammed Dado wrote: It's not that giant , but counters are incrementing .. Best Regards, Mohammed Dado Technical Support Engineer - EMEA Airspan Communications Ltd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derick Winkworth Sent: 19 October 2008 15:29 Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] EIGRP routing failure Do you see giants incrementing on either interface? Mohammed Dado wrote: Dears, We're configuring EIGRP on both sides, customer and ISP. The customer router are dumping the following logs. Here's an example of some logs .. 128326: Oct 6 02:48:05.387 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency 128327: Oct 6 02:48:05.435 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is down: K-value mismatch 128328: Oct 6 02:48:19.519 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency 128329: Oct 6 02:57:37.414 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is down: holding time expired 128330: Oct 6 02:57:41.210 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency 128331: Oct 6 02:58:46.495 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is down: holding time expired 128332: Oct 6 02:58:50.655 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency 128333: Oct 6 02:58:52.699 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is down: K-value mismatch 128334: Oct 6 02:58:57.623 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency 128335: Oct 6 02:59:36.491 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is down: holding time expired 128336: Oct 6 02:59:44.327 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency Can anybody assist ? Best Regards, Mohammed Dado Technical Support Engineer - EMEA Airspan Communications Ltd [cid:identifierFooterImage] ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.1/1732 - Release Date: 10/18/2008 6:01 PM ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.2/1735 - Release Date: 10/20/2008 2:52 PM ___ 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] EIGRP routing failure
Do you see giants incrementing on either interface? Mohammed Dado wrote: Dears, We're configuring EIGRP on both sides, customer and ISP. The customer router are dumping the following logs. Here's an example of some logs .. 128326: Oct 6 02:48:05.387 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency 128327: Oct 6 02:48:05.435 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is down: K-value mismatch 128328: Oct 6 02:48:19.519 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency 128329: Oct 6 02:57:37.414 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is down: holding time expired 128330: Oct 6 02:57:41.210 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency 128331: Oct 6 02:58:46.495 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is down: holding time expired 128332: Oct 6 02:58:50.655 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency 128333: Oct 6 02:58:52.699 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is down: K-value mismatch 128334: Oct 6 02:58:57.623 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency 128335: Oct 6 02:59:36.491 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is down: holding time expired 128336: Oct 6 02:59:44.327 CDT: %DUAL-5-NBRCHANGE: IP-EIGRP(1) 100: Neighbor 10.253.225.38 (GigabitEthernet1/31.101) is up: new adjacency Can anybody assist ? Best Regards, Mohammed Dado Technical Support Engineer - EMEA Airspan Communications Ltd [cid:identifierFooterImage] ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.1/1732 - Release Date: 10/18/2008 6:01 PM ___ 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] Fwd: NAT in VRF
NAT NVI. That would be the first doc, qtnatvi. There is no inside/outside that way. On Tue, 2008-10-14 at 15:37 +0200, Jan van den Berg wrote: This touches a problem I am currently working on. I need to access services in one VPN from multiple other VPNs. I read in the ftnatvpn doc this: Inside VPN to VPN with NAT is not supported. Since it is necessary that different VPNs can access the services from one VPN; using NAT will be probably be required. So does anyone have any pointers on how to go about this? Cheers, Jan -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Derick Winkworth Verzonden: vrijdag 10 oktober 2008 14:09 Aan: cisco-nsp@puck.nether.net Cisco NSP Onderwerp: Re: [c-nsp] Fwd: NAT in VRF http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtnatvi.html http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftnatvpn.htm l Here are two different ways to do what you are asking for, I hope! Gary Roberton wrote: Thanks Luan Can anyone else confirm this also? Thanks On Thu, Oct 9, 2008 at 2:04 PM, Luan Nguyen [EMAIL PROTECTED] wrote: Yes you can. I used to do that with 2 VRF-Lites on 2 DMVPN tunnels. Platform doesn't make any different. Luan Nguyen Chesapeake NetCraftsmen, LLC. www.NetCraftsmen.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Roberton Sent: Thursday, October 09, 2008 7:28 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Fwd: NAT in VRF -- Forwarded message -- From: Gary Roberton [EMAIL PROTECTED] Date: Wed, Oct 8, 2008 at 10:13 AM Subject: NAT in VRF To: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Can someone please confirm for me that you can have the same IP address in different VRFs natted to different destinations. In other words; 217.1.1.1 nat to 10.1.1.1 in VRF A 217.1.1.1 nat to 192.168.1.1 in VRF B I can't see any reason why not. What about if using VRF-Lite on a 3845, does that make any difference? Its a funny question but I have been asked this and have no access to the kit to prove it working and I have to have a solid answer. Thanks. Gary ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.0/1717 - Release Date: 10/9/2008 4:56 PM ___ 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] Basic MPLS 7200
Don't these interfaces share a controller? So they are 3-to-1 oversubscribed on the NPE??? Mark Tinka wrote: On Wednesday 15 October 2008 02:20:03 Adam Armstrong wrote: ...and 4 Cu/SFP and 2Mpps The NPE-G2, like the NPE-G1, has only 3x copper/SFP transit interfaces. It's the 7201 with 4x. Cheers, Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.0/1724 - Release Date: 10/14/2008 2:02 AM ___ 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] Fwd: NAT in VRF
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtnatvi.html http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftnatvpn.html Here are two different ways to do what you are asking for, I hope! Gary Roberton wrote: Thanks Luan Can anyone else confirm this also? Thanks On Thu, Oct 9, 2008 at 2:04 PM, Luan Nguyen [EMAIL PROTECTED] wrote: Yes you can. I used to do that with 2 VRF-Lites on 2 DMVPN tunnels. Platform doesn't make any different. Luan Nguyen Chesapeake NetCraftsmen, LLC. www.NetCraftsmen.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Roberton Sent: Thursday, October 09, 2008 7:28 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Fwd: NAT in VRF -- Forwarded message -- From: Gary Roberton [EMAIL PROTECTED] Date: Wed, Oct 8, 2008 at 10:13 AM Subject: NAT in VRF To: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Can someone please confirm for me that you can have the same IP address in different VRFs natted to different destinations. In other words; 217.1.1.1 nat to 10.1.1.1 in VRF A 217.1.1.1 nat to 192.168.1.1 in VRF B I can't see any reason why not. What about if using VRF-Lite on a 3845, does that make any difference? Its a funny question but I have been asked this and have no access to the kit to prove it working and I have to have a solid answer. Thanks. Gary ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.0/1717 - Release Date: 10/9/2008 4:56 PM ___ 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] Recommend IOS for 7200?
We've been having good luck with 12.4(15)T6 and T7. I wouldn't recommend any other 12.4 release. Howard Jones wrote: Peter Nyamukusa wrote: Hi Howard, Why do you have a look at the Software Advisor tool http://tools.cisco.com/Support/Fusion/FusionHome.do Because that doesn't have a column for does what you want, but crashes mysteriously. 12.2(25)S15 is the latest 12.2S release. It has the features I want. What I don't know is if it's also buggy, like some other latest releases apparently are. That's why I was asking for experience. Best Regards, Howie ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.7.6/1712 - Release Date: 10/7/2008 9:41 AM ___ 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] Unable to connect VLAN traffic
Q-in-Q Johnny Ramirez wrote: We have layer 2 connectivity from our main office to an offsite facility where our servers reside. We are connected via fiber but is not a dedicated circuit. Recently I created a VLAN with same ID on both switches (main office and Offsite facility) . I trunked the port on both ends but not traffic passes on this VLAN. Obviously only VLAN 1 works. According to a consultant the provider of the fiber connection needs to turn something on for us to be able to pass VLAN traffic other than VLAN 1's. What would be that something, he does not even kow it himself. Can anybody shed any light on this?. We are urgently needing to have a separate VLAN for our VOIP traffic. Thanks John ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.5/1620 - Release Date: 8/19/2008 6:04 AM ___ 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] tx-ring-limit on ISR ATM-AIM module...
All: I believe I may need to tune down the tx-ring on a 3845 with ATM-AIM module. I'm looking at this, and it doesn't look like it uses the same system that the 7200 uses (i.e., with particles/576 bytes per particle calculation). from show controller atm0/ima0 I see the following: MXT5100 Channel Info: Channel Info (0): Chan_ID (0x1425), Open Status SUCCESS, VC(1)VPI/VCI(1/777), Tx Ring packets(used/max 0/40), Tx SBD(used/max 0/40) Tx PDU(5941481), Tx PDU discard(0) Tx SDU size err(0), Tx cell CLP0(123777482), Tx cell CLP1(0) Rx PDU(4827762), Rx PDU discard(0), Rx SDU size err(0) Rx CRC err(1), Rx cell CLP0(24771185), Rx cell CLP1(0) # So it looks like the tx-ring is just 40 packets long. I'm assuming this means 40 AAL5 packets? Does anyone know what SBD stands for? I tried getting some tech docs on the MXT5100 from Conexant, but you need a support account to access that. Derick ___ 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] tx-ring-limit on ISR ATM-AIM module...
I just found this: http://www.cisco.com/en/US/tech/tk39/tk824/technologies_tech_note09186a0080094b48.shtml It looks like it the BD part stands for buffer description so its a data structure describing a packet in the queue? Tyson Scott wrote: State-Based Decoder This is my guess based on searches. Here is the only article that I could find that seemed to make sense. http://net.educause.edu/elements/attachments/rfi/rfi_1/XACCT_original.pdf Regards, Tyson Scott - CCIE #13513 RS and Security Technical Instructor - IPexpert, Inc. Telephone: +1.810.326.1444 Cell: +1.248.504.7309 Fax: +1.810.454.0130 Mailto: [EMAIL PROTECTED] Join our free online support and peer group communities: http://www.IPexpert.com/communities IPexpert - The Global Leader in Self-Study, Classroom-Based, Video On Demand and Audio Certification Training Tools for the Cisco CCIE RS Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derick Winkworth Sent: Friday, July 18, 2008 8:45 AM To: Cisco NSP; Groupstudy RS Subject: tx-ring-limit on ISR ATM-AIM module... All: I believe I may need to tune down the tx-ring on a 3845 with ATM-AIM module. I'm looking at this, and it doesn't look like it uses the same system that the 7200 uses (i.e., with particles/576 bytes per particle calculation). from show controller atm0/ima0 I see the following: MXT5100 Channel Info: Channel Info (0): Chan_ID (0x1425), Open Status SUCCESS, VC(1)VPI/VCI(1/777), Tx Ring packets(used/max 0/40), Tx SBD(used/max 0/40) Tx PDU(5941481), Tx PDU discard(0) Tx SDU size err(0), Tx cell CLP0(123777482), Tx cell CLP1(0) Rx PDU(4827762), Rx PDU discard(0), Rx SDU size err(0) Rx CRC err(1), Rx cell CLP0(24771185), Rx cell CLP1(0) # So it looks like the tx-ring is just 40 packets long. I'm assuming this means 40 AAL5 packets? Does anyone know what SBD stands for? I tried getting some tech docs on the MXT5100 from Conexant, but you need a support account to access that. Derick ___ Subscription information may be found at: http://www.groupstudy.com/list/CCIELab.html No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.0/1558 - Release Date: 7/17/2008 9:56 AM ___ 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] OT: Boson practice exams
All: Anyone heard from Boson on when they are going to update their practice exams? We try calling to talk to them and they are just plain rude about it. They are still selling the old CCNP exams. Their information page on the CCNP looks like it was written two years ago. We are a volume buyer from them, and they won't give us the slightest idea of when this might be updated. They are aware we may not renew or commitments next year if they can't update these exams, and their attitude seems to be they really don't care. Its too bad, because they make a decent product. Their not braindumps. Their officially associated with Cisco. Cisco even distributes their questions and exam engine with some of the CiscoPress study guides. Argh! Boson what is going on?!?! ___ 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/
