Re: [c-nsp] Internet in VRF
On 2/May/15 02:27, Phil Bedard wrote: I think it’s a popular enough option these days in carrier networks that the larger vendors do plan for it somewhat at this point. In the beginning there were issues with how labels are allocated (per-VRF or per-prefix) which leads to lots of potential issues. The ability for the box to look deep enough into the packet as well to get good entropy for load balancing. If you are doing something like seamless MPLS and carrying 3+ labels on a packet some gear may have issues. You also may run into issues with not being able to impose enough labels for something like FRR/backup tunnels on an ingress node. Like I said though, there are some large carriers doing this today so vendors have solved most of those issues by now. Some vendors are building gear with off-the-shelf network processors that have limitations into how many labels can be supported. Nothing you can do about that since it's a hardware problem, and the vendors are not going to be developing in-house network processors for those platforms because the existing solution is quite cheap enough for them given the competition. 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/
Re: [c-nsp] Internet in VRF
On 2/May/15 01:13, Jason Lixfeld wrote: I’ve been doing this for years on ME3600s, 7600s, A9Ks and A1Ks. Except, I don’t separate my Internet customers into a different VRF than the Internet VRF. Internet and all Internet customers are in the same VRF. VOIP is in another VRF, IPTV in another, Management in another, etc. Putting sub-sets of customers who require the same services inside different VRFs and having to leak between the two is more complexity than we need. We don’t sell L3VPNs, so leaking between VRFs is never something I’ve had to worry much about. I do have one application where I need to leak between two VRFs on an A9K. That is a royal pain in the ass which requires a loopback cable because IOS and XR by default inherit the next hop of the route when it’s leaked, instead of providing a knob to adjust this behaviour. Overall, I love the design. It shrinks failure domains very nicely. If someone fat fingers something in a VRF, it’s limited to that VRF and the global table is left completely intact. Alternatively, with one huge routing table, one fat enough finger and you’re in quite the pickle. Since everything is in a VRF, the global table is pretty much completely hands off except for device M-A-C events, but those are far less frequent than other config M-A-C events which happen inside these VRFs. A stable global table means stable MPLS underpinnings. Stable MPLS underpinnings mean stable EoMPLS/VPLS/NG-MVPN. So we are now seeing LDPv6 spring up in IOS XR 5.3.0 - are you going to start planning something similar for IPv6 routing/forwarding? Generally, we use BGP communities, very extensively, to create the necessary separation as demanded by the business and the network. Pretty much everything we touch in BGP is community-driven, and that works very well. Of course, this works well because we have the luxury of discretely separating functions to specific devices in all the PoP's we operate (which is essentially what VRF's or logical systems/SDR's do anyway). So not an option for everyone, but one has to cost hardware as well as operational complexity to find out what works for them. We went the other route :-)... 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/
Re: [c-nsp] MPLS interface continuity and OSPF configuration ME-3600X
Instead of autoconfig, I've always used LDP/IGP synchronization. This prevents the exact problem you are running into by setting the IGP metric to the max value if the IGP and LDP aren't in sync (e.g., if you've forgotten to enable MPLS on an interface). See http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_ldp/configuration/15-sy/mp-ldp-15-sy-book/mp-ldp-igp-synch.html for more info. Peer-review of configs is obviously a great idea, but you will still run into cases where this might help. For example, your NOC might be troubleshooting link issues and try removing parts of the config or perhaps moving configs to a new interface, etc. If you end up with IP but no MPLS enabled, and you've got synchronization enabled, the link simply doesn't get used unless there are no other possible paths, which usually helps highlight the problem. --Jeff Sent from my iPad On May 1, 2015, at 20:14, Eric Louie elo...@techintegrity.com wrote: I'll just review the configs before they're implemented from now on. Auto-config seems to be a little too dangerous, and still requires configuration, which mpls ip does when they add it to both sides. On Fri, May 1, 2015 at 1:50 PM, Andrew Brant andrew.br...@me.com wrote: http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/mpls/configuration/guide/mpls_cg/mp_ldp_autoconfig.html I'd look into enabling the OSPF LDP auto-config feature to prevent another NOC induced outage Sent from my iPhone On May 1, 2015, at 14:09, Eric Louie elo...@techintegrity.com wrote: I had a strange anomaly happen yesterday We have 2 ME-3600's as part of an MPLS network. There are MPLS interfaces on both sides of them and between them. so, like this R1 R2 R3 R4 and all the links between are MPLS IP My NOC enabled a new circuit between R2 and R3, and forgot to use mpls ip on both interfaces. When they decreased the OSPF cost on the two interfaces (as the preferred route), traffic from R1 to R4 stopped at R2. (I didn't get the corresponding result R4 to R1, but our monitoring server is behind R4, and could not reach any devices connected to R1) The old MPLS circuit was still connected and enabled, just costed out via OSPF. So, it appears that when the new link was costed in, because it was not an MPLS link, the traffic didn't know how to get through the new R2-R3 link, since the MPLS link was now costed out by MPLS. making the new link an MPLS link solved the problem. My questions are: Is this by design? In other words, if we have MPLS links on both sides of a pair of routers, does that MPLS configuration need to be contiguous throughout? Is this a condition of configuring MPLS, that all intermediate paths need to be either tunnelled or configured? (something that I might have missed in my MPLS learning) Did we run into a bug? IOS 15.2(4)S Is this a TAC question? ___ 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 interface continuity and OSPF configuration ME-3600X
On 2/May/15 06:25, Daniel Dib wrote: Maybe you could help develop a checklist for the NOC? If they don’t have one already. Check the current best path, do a traceroute, what labels are used. Verify that new interface comes up, MPLS is enabled, do a traceroute, verify new labels and so on. For us, that is why we wouldn't allow the NOC to deploy new backbones. Yes, with a checklist, the NOC will ensure everything is followed to the tee, but the NOC are typically operations folk, meaning they generally follow set procedures to run the network. Bringing up new backbones, while reasonably mundane, can have its own set of interesting issues that need one to implement solutions that the network might have never seen (remember, NOC's are generally process-driven). As such, we'd normally leave the NOC to operate the network, and deployments done by a different built for that. 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/
Re: [c-nsp] Cheap BGP router for ~20k prefixes
Mark Tinka Sent: 01 May 2015 19:55 To: Dan Brisson; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cheap BGP router for ~20k prefixes On 30/Apr/15 16:35, Dan Brisson wrote: Looking for suggestions for a device (switch/router) that can speak BGP and do around 20k prefixes. The other requirement is minimum 500Mb/s of throughput, which seems to throw a low-end Cisco router out of the mix. I know a 3560 switch can do BGP and wouldn't have the throughput limitations the router lines have. The cost is probably going to creep up again though when adding Enterprise code for BGP support. I'm really hoping to stay in the sub $2000 range, if possible. Mikrotik has some very impressive gear and I know folks on this list are mixed on them. But something like their CCR1036-12G-4S has impressive specs and an even more impressive price tag - ~$850. CSR1000v? Interesting idea, CSR1000v BW can go up to 10GE (license base upgrade) right? adam --- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.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] Internet in VRF
On May 2, 2015, at 2:35 AM, Mark Tinka mark.ti...@seacom.mu wrote: So we are now seeing LDPv6 spring up in IOS XR 5.3.0 - are you going to start planning something similar for IPv6 routing/forwarding? If anything, we’d migrate our entire MPLS core to LDPv6. Don’t hold your breath though :) ___ 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 iWAN Solution
Hi . Can anyone please provide inputs on the Cisco iWAN solution . Thanks, Ranjith On Fri, May 1, 2015 at 12:11 AM, Ranjith R ranjithrn...@gmail.com wrote: Hello Folks , We are in the process of evaluating Cisco iWAN solution , would like to gather opinions about the solution with the below requirement How good is the PFR feature for load balancing effectively among multiple internet links How good is the Cisco WAAS and akamai connect for the WAN acceleration We have a cloud based proxy solution and all the traffic from remote site should make use of the local internet links to reach the proxy server on cloud Although various cisco documents states PFR will work for Direct internet access , there has been contradictory information on the same . Could you guys share your valuable inputs if any ? Thanks in Advance , Regards, Ranjith ___ 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] Optical - rx power low warning
On 05/02/2015 09:51 AM, Andrew Miehs wrote: 10GBASE-ER/EW should only be 40km - ZR would be the longer distance ones. Can you compare it to the light levels seen on the other end of the link? The levels should be approximately equal. Are you sure it is 20 miles and not a little longer? I would not be happy running the link based on these light levels. Are there any patch panels? Have all the cables been cleaned? Based on Cisco's web site: http://www.cisco.com/c/en/us/td/docs/interfaces_modules/transceiver_modules/installation/note/78_15160.html SFP-10G-ER1: 10GBASE-ER, 1550-nm SMF Max Distance: 24.86 miles (40 km)3 Tx: 4.0 (Max) Tx: -4.7 (Min) Rx: -1.0 (Max) Rx: -15.8 (Min) Freq: 1530 to 1565 As a follow up, I've talked to my vendor. The optics are ok and traffic is working fine (as confirmed by smokeping over the last 72 hours) but the programming is wrong, vendor fskup, and thats the explanation for my problem. I'm geting replacements and will post results when those are in. Thank you. Mike- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco iWAN Solution
On 02 May 2015, at 19:52, Pavel Skovajsa pavel.skova...@gmail.com wrote: Hello Ranjith, The IWAN solution is relatively new, so you will not find a lot of people with experience with it. True. Also there are interesting operational issues that are probably much harder to fix in IWAN world. For example the customer calls you and tells you that yesterday at 9:35AM their application did not work in SiteA. How would you know which path the traffic took? It is dynamic, so how would you troubleshoot? PfR logs prefix decisions, and you can store them either in some syslog server, or in other software solutions that provide more capabilities than just checking. Now to your questions: How good is the PFR feature for load balancing effectively among multiple internet links PFR is traditionally excellent in this, without configuration it actually loadbalances almost precisely 50/50. Well, that’ll depend on the configuration and traffic characteristics. If I understand correctly what you are asking is whether PFR works for Direct Internet Access. No, it does not, my understanding is that PFR only works inside the DMVPN cloud inside the Enterprise. The reason is simple - PFR not only changes the forward path, but also the return path, hence you need full control of both sides. PfR works on prefixes and reachability information, so no, it is not dependent on the DMVPN cloud. You can run (and people usually do) for pure IP traffic. It’s capability to actually run and use different types of tunnels makes it more flexible. -- Those pople who think they know| Łukasz Bromirski everything, are a great annoyance to | jid:lbromir...@jabber.org those of us, who do. Isaac Asimov | http://lukasz.bromirski.net ___ 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] Optical - rx power low warning
10GBASE-ER/EW should only be 40km - ZR would be the longer distance ones. Can you compare it to the light levels seen on the other end of the link? The levels should be approximately equal. Are you sure it is 20 miles and not a little longer? I would not be happy running the link based on these light levels. Are there any patch panels? Have all the cables been cleaned? Based on Cisco's web site: http://www.cisco.com/c/en/us/td/docs/interfaces_modules/transceiver_modules/installation/note/78_15160.html SFP-10G-ER1: 10GBASE-ER, 1550-nm SMF Max Distance: 24.86 miles (40 km)3 Tx: 4.0 (Max) Tx: -4.7 (Min) Rx: -1.0 (Max) Rx: -15.8 (Min) Freq: 1530 to 1565 -- Andrew On Fri, May 1, 2015 at 12:57 AM, Mike mike-cisconspl...@tiedyenetworks.com wrote: On 04/29/2015 11:22 PM, Sascha Pollok wrote: Hi Mike! the Alarm status comes from the SFP. Togehther with the crapp chars I would say some internal values got messed up maybe incl the thresholds for alarms. -16dbm should be fine. Talk to the vendor. Thats exactly what I'm planning next, thank you. ___ 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] Cisco iWAN Solution
Hello Ranjith, The IWAN solution is relatively new, so you will not find a lot of people with experience with it. I do not have any practical experience running an IWAN network, but I spent quite some time looking at the IWAN architecture and design. My opinion is that on one side the IWAN solution lowers the cost of branch site circuits, but significantly increases the technical and operational complexity of the WAN CE routers. This is a perfect move from Cisco since just by principle their routers with more complexity inside can be more expensive. Hence the solution moves the cost around from circuits (non cisco business) to routers (cisco business) and strengthens Cisco position. Obviously this depends on your definition of what is complex and what is not complex. You can argue can that various IWAN single pane of glass mgmt tools make this solution less complex by presenting a nice clean GUI, but all those tools do is hide complexity for casual user. All I know is that IWAN is not a simple feature that you turn on and forget about - it completely changes how routing works. Also there are interesting operational issues that are probably much harder to fix in IWAN world. For example the customer calls you and tells you that yesterday at 9:35AM their application did not work in SiteA. How would you know which path the traffic took? It is dynamic, so how would you troubleshoot? Now to your questions: How good is the PFR feature for load balancing effectively among multiple internet links PFR is traditionally excellent in this, without configuration it actually loadbalances almost precisely 50/50. How good is the Cisco WAAS and akamai connect for the WAN acceleration As good as any WAAS box or proxy solution:) all the traffic from remote site should make use of the local internet links to reach the proxy server on cloud Although various cisco documents states PFR will work for Direct internet access If I understand correctly what you are asking is whether PFR works for Direct Internet Access. No, it does not, my understanding is that PFR only works inside the DMVPN cloud inside the Enterprise. The reason is simple - PFR not only changes the forward path, but also the return path, hence you need full control of both sides. My 2 cents, comments or corrections welcome, I would be interested in others opinion and experience as well, -pavel skovajsa On Sat, May 2, 2015 at 6:34 PM, Ranjith R ranjithrn...@gmail.com wrote: Hi . Can anyone please provide inputs on the Cisco iWAN solution . Thanks, Ranjith On Fri, May 1, 2015 at 12:11 AM, Ranjith R ranjithrn...@gmail.com wrote: Hello Folks , We are in the process of evaluating Cisco iWAN solution , would like to gather opinions about the solution with the below requirement How good is the PFR feature for load balancing effectively among multiple internet links How good is the Cisco WAAS and akamai connect for the WAN acceleration We have a cloud based proxy solution and all the traffic from remote site should make use of the local internet links to reach the proxy server on cloud Although various cisco documents states PFR will work for Direct internet access , there has been contradictory information on the same . Could you guys share your valuable inputs if any ? Thanks in Advance , Regards, Ranjith ___ 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] Cheap BGP router for ~20k prefixes
On 2015-05-02 13:08, Adam Vitkovsky wrote: Interesting idea, CSR1000v BW can go up to 10GE (license base upgrade) right? Can it handle QoS in any way? /Anders ___ 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/
