Re: [c-nsp] Two HUBS-Location Specific Spokes-Redundant to each other
Hi Yaswanth I haven’t made it in real life, but doesn’t seem difficult. What I would do is publish the default route with a different community in each hub (i.e. 65000:1 in one hub and 65000:2). In each spoke, depending of what you want use the community to set a local preference. i.e. in the hub: router bgp 65000 network 0.0.0.0 mask 0.0.0.0 neighbor 10.0.0.2 remote-as 65000 neighbor 10.0.0.2 send—community neighbor 10.0.0.2 route-map NY out route-map NY permit 10 set community 65000:1 in the spoke: router bgp 65000 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 route-map hub in route-map hub permit 10 match community 65000:1 set local-preference 130 route-map hub permit 20 match community 65000:2 set local-preference 90 Regards, Fernando El 26/07/2013, a las 07:41, vasu varma ypk...@gmail.com escribió: Hi Lumbis, Thanks for your response. Its not all about latency, latency may vary depending on the backbone utilization irrespective of closest location. I want in such a way that east locations should prefer the default route from East HUB with West HUB acting as secondary and west locations should prefer the default route from WEST HUB with EAST HUB acting as secondary. One location may be equally destined in terms of latency or distance but we should be able to configure as we desired. Regards Yaswanth On Tue, Jul 23, 2013 at 8:32 PM, Pete Lumbis alum...@gmail.com wrote: If by closest you mean lowest latency you probably want to look at something like PfR to do this dynamically for you. On Tue, Jul 23, 2013 at 1:48 AM, vasu varma ypk...@gmail.com wrote: Hi Team, I have a requirement in such a way that there are two HUB's, one in Newyork and other in LOS Angeles. The spoke locations will access the HUB location whichever is closer geographically and the other acts as the backup for that particular site. If both the HUB's injects default route into the cloud, how can I configure the iBGP attributes to select the best path based on the closest physical location. Our's is a MPLS cloud with multiple customers sharing the same Infra. Can someone assist me with the solution approach and most importantly the changes that I need to do in my network. Regards Yaswanth ___ cisco-nsp 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] Two HUBS-Location Specific Spokes-Redundant to each other
Hi Yaswanth I haven’t made it in real life, but doesn’t seem difficult. What I would do is publish the default route with a different community in each hub (i.e. 65000:1 in one hub and 65000:2). In each spoke, depending of what you want use the community to set a local preference. i.e. in the hub: router bgp 65000 network 0.0.0.0 mask 0.0.0.0 neighbor 10.0.0.2 remote-as 65000 neighbor 10.0.0.2 send—community neighbor 10.0.0.2 route-map NY out route-map NY permit 10 set community 65000:1 in the spoke: router bgp 65000 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 route-map hub in route-map hub permit 10 match community 65000:1 set local-preference 130 route-map hub permit 20 match community 65000:2 set local-preference 90 Regards, Fernando El 26/07/2013, a las 07:41, vasu varma ypk...@gmail.com escribió: Hi Lumbis, Thanks for your response. Its not all about latency, latency may vary depending on the backbone utilization irrespective of closest location. I want in such a way that east locations should prefer the default route from East HUB with West HUB acting as secondary and west locations should prefer the default route from WEST HUB with EAST HUB acting as secondary. One location may be equally destined in terms of latency or distance but we should be able to configure as we desired. Regards Yaswanth On Tue, Jul 23, 2013 at 8:32 PM, Pete Lumbis alum...@gmail.com wrote: If by closest you mean lowest latency you probably want to look at something like PfR to do this dynamically for you. On Tue, Jul 23, 2013 at 1:48 AM, vasu varma ypk...@gmail.com wrote: Hi Team, I have a requirement in such a way that there are two HUB's, one in Newyork and other in LOS Angeles. The spoke locations will access the HUB location whichever is closer geographically and the other acts as the backup for that particular site. If both the HUB's injects default route into the cloud, how can I configure the iBGP attributes to select the best path based on the closest physical location. Our's is a MPLS cloud with multiple customers sharing the same Infra. Can someone assist me with the solution approach and most importantly the changes that I need to do in my network. Regards Yaswanth ___ cisco-nsp 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] MPLS down to the CPE
They will always have a job for you there with that design. On 25 July 2013 13:04, Adam Vitkovsky adam.vitkov...@swan.sk wrote: I see so the islands are stitched together over the CsC L3VPN, since all islands have the same AS together they act like a common AS. And the CsC L3VPN is provided by the underlying common backbone Inter-AS-MPLS optC style. Right? So all access nodes within a particular island have RSVP-TE tunnels to ABRs/ASBRs within the island (ASBRs than provide connectivity to other islands). And there's a full mesh of tunnels between all ASBRs. Right? I'd like to ask is there a full mesh of iBGP sessions between the ASBRs or some of the ASBRs have a role of RRs please? So you have decided to create this sort of overlay AS dedicated for L2 services. I think I understand your reasoning behind the setup and must say it's very bold and creative. See this is what I was talking about before, back in the old days engineers would have to get very creative and bold to create something extraordinary with such a limited set of features. With today's boxes you could all stack it up into a single AS not ever worrying about scalability or convergence times. Thank you very much for sharing the design with us adam -Original Message- From: Phil Bedard [mailto:phil...@gmail.com] Sent: Thursday, July 11, 2013 3:48 AM To: Adam Vitkovsky; mark.ti...@seacom.mu Cc: 'Andrew Miehs'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] MPLS down to the CPE On 7/10/13 4:16 AM, Adam Vitkovsky adam.vitkov...@swan.sk wrote: the different network islands are tied together using CsC over a common MPLS core. You got me scared for a moment CsC would mean to run a separate OSPF/LDP/BGP-ASN for each area and doing MP-eBGP between ASBRs within each area(OptB) or between RRs in each area(optC) with core area/AS acting as a labeled relay for ASBRs loopback addresses, though I believe by common MPLS core you mean a single AS right please? The islands are actually all in the same ASN, the common core is not the same ASN. Could have been the same ASN, more political reasons for it not being the same than technical. In the end it looks like Option C, the CsC L3VPN only carries loopbacks and aggregate IP prefixes. The common core is RSVP-TE based, if I had my preference today I would build TE tunnels across it between the islands and then use RFC3107 as a way to tie it all together end to end. Years ago when we first built it some of the feature support wasn't there to do that. At the ABR all of the L2VPN services are stitched since you are entering a different RSVP-TE/MPLS domain, the L3VPN configuration exists on these nodes with the access nodes using L2 pseudowires into virtual L3 interfaces. I see, right that's a clever way to save some money by pushing the L3VPN stuff to only a few powerful boxes with high-queue line cards and L3VPN licenses. Though the PWHE -a setup where you can actually terminate the PW into L3 interface on the same box was introduced to Cisco boxes only recently so prior to that you'd have to have a separate box bridging the PW to sub-int/serv-inst on a QinQ trunk where the L3VPN box would be connected to. I'm still confused about the TE part. So I believe you are pushing PW directly into TE tunnels what gives you the ability to balance the PWs around the ring as well as to use a backup tunnel via the opposite leg of the circuit. So the TE tunnels are actually terminated on the PWHE nodes right? Or do they actually continue into the backbone area please? The tunnels from the access boxes terminate on the PWHE nodes, they do not extend beyond that boundary. There is another set of tunnels which connect the PWHE nodes together. This isn't a one-off deployment or anything, there are other folks out there with basically the same type of deployment. Phil adam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] N7k sending LACP PDUs tagged w/ vlan dot1q tag native?
On 25/07/13 17:31, Phil Mayers wrote: AFAIK, IOS doesn't do this, even with vlan dot1q tag native set globally (which we set for avoidance of half-directional tagged links). For info, some versions of IOS do this, but it was fixed as a bug - see for example CSCtc20603 I'm guessing this bug got ported from IOS to NX-OS? ___ cisco-nsp 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] C76 and ES+ LC - show mpls l2transport bug
Hi all,
This may be interesting for everybody using MPLS-TE and Loadbalancing with
ES+ LC.
We use Cisco 7600 with IOS 15.3.1-S2 and the following LCs:
Module Part number Series CEF mode
1RSP720-3C-10GEsupervisor CEF
276-ES+T-4TG dCEF720 dCEF
376-ES+T-4TG dCEF720 dCEF
476-ES+T-40G dCEF720 dCEF
We set up a MPLS core and because of multiple links between core routers,
we have multiple MPLS-TE tunnels and load balancing between each two of
them.
E.g. Tunnel10301, Outgoing Label 39 and Tunnel10302, Outgoing Label 53
Some days ago I discovered that the imposed label stack on a VC does not
show the truth as I compared sh mpls l2transport vc 2105 detail which
said Output interface: Tu10301, imposed label stack {39 0 18} to my
packet capture which showed label stack {53 0 18}. Thus the EoMPLS gets
transferred on a not supposed tunnel which results in traffic on a
different interface.
I opened a TAC case and they raised a bug for this, CSCui14755.
Now I got the following response:
Here is the situation. Whenever dual path exists to carry the EoMPLS VC,
when it is established, the software will take one of the CEF path to
build the label stack that is displayed under 'show mpls l2 vc ...
detail' but it is possible the hardware will forward the traffic on a
different path based on the load-balancing hashing algorithm.
The problem here is that there is no way with the current code and
hardware for the software to retrieve the hardware information which
could be used to forward the traffic. The developers looked to the code
architecture and it is not possible to modify it.
I even asked if this could be implemented as a new feature (then having
the whole code rewritten) but that still does not seem to be an option.
First, I would like to warn everyone of you trusting the imposed label
stack together with load balancing.
Second, I would to know how many of you are affected by this bug which
will not be fixed..
Holger
___
cisco-nsp 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] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback
However, in order to turn on 250 MDT routes, we have to drop the IPv4 routes down to 12,000. A reasonable use-case for a larger FIB in this platform family :-). We've gone through the same disappointment so I'm waiting for the mLDP/NG-MVPN support. Yes however the bigger FIB would be much appreciated. Regarding the lack of 10GigE ports + 1GigE ports density, my first question when I saw this platform was: Is it stackable? It would be great if the new version of X(CX) is stackable. Yes so far we use 2x CX to redundantly connect a 10GE ring to the city POP. However we don't really need CES everywhere so stacking two X-es together would be a better solution with a lot more GigE ports. adam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ME3800X/ME3600X/ME3600X-24CX/ASR903/ASR901 Deployment Simplification Feedback
Regarding the lack of 10GigE ports + 1GigE ports density, my first question when I saw this platform was: Is it stackable? It would be great if the new version of X(CX) is stackable. Yes so far we use 2x CX to redundantly connect a 10GE ring to the city POP. However we don't really need CES everywhere so stacking two X-es together would be a better solution with a lot more GigE ports. Amen. Number of 1G ports, number of 10G ports, stackability: Cisco has a pretty significant hole in their metro portfolio there. Chassis based 6500/7600 is *not* the answer. Steinar Haug, AS 2116 ___ cisco-nsp 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] ASR9000 vlan rewrite
interface TenGigE0/1/0/0.22001 l2transport encapsulation dot1q 100-399 exact rewrite ingress tag pop 1 symmetric What the heck. I have just tried to configure this in the lab and it did not complain. When the box removes the tag form the incoming frame how does it know what tag to apply on the outgoing frames? I'm not aware of any mac to tag mapping table in XR. This type of configuration would be rejected on regular IOS. adam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Multi-Vendor CAPWAP AP Interop Using Cisco 5508 WLC
Hello Darin, On Thu, Jul 25, 2013 at 12:19:13PM -0500, Darin Herteen wrote: I have been trying to hunt down some definitive answers regarding interoperability using non-cisco AP's running CAPWAP in conjunction with a Cisco WLC 5508 running 7.3.101.0. A TAC case I opened on this issue didn't really give me a definitive answer only to say that a non-cisco AP could only be used in Workgroup Bridge Mode which would not be desired or even applicable to our deployment. ( I have not reached out to our SE as of yet) Upon further research I came across a statement from Aruba Networks in 2009 regarding their position on CAPWAP in which they state anybody claiming to be running CAPWAP are using proprietary extensions and do not adhere to RFC5415. Can anybody tell me if this is still the current state of CAPWAP? Has anybody seen or had experience running a multi-vendor AP deployment using Cisco WLC's ? I don't think so, In case you want to take a look at Cisco CAPWAP vs. RFC CAPWAP you may want to look at the Wireshark source for the CAPWAP dissector and search for cisco (case insensitive search). http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-capwap.c Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ cisco-nsp 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] Passing Payload Transparently in a L2VPN
Hi, I would like to put different types of payloads inside a L2VPN (whether p2p or vpls) and confirm that the terminating router will not process the payload (i.e: only pass it to the CE/customer). I am wondering how i can do that? specially if i want to test legacy protocols (AppleTalk, IPX...etc) Suppose i have a traffic generator and two ports are connected to my setup : Traffic_Gen(PE)==L2VPN(PE)Traffic_Gen If the traffic generator supports creating packets, then how do i make sure the router will take my crafted packet across and what kind of checks I can do on the terminating PE to make sure it did not process the packet. Thanks, Sam ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
