Re: [c-nsp] Whats happens when TCAM is full on 7600/RSP720RSP-3CXL?
--- Begin Message --- On Fri, 18 Sep 2020, chiel wrote: Is it ok to set "maximum-prefix 0" on my v6 session? Or is it better to make a prefix list like " ipv6 prefix-list IPV6-IN seq 10 deny ::/0 le 128" top stop receiving routes from my upstream? It's better to filter incoming routes. That way your session is still up. -- Mikael Abrahamssonemail: swm...@swm.pp.se --- End Message --- ___ 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] Whats happens when TCAM is full on 7600/RSP720RSP-3CXL?
--- Begin Message --- On Fri, 18 Sep 2020, chiel wrote: I have been hearing different scenario of what would happen when the TCAM is full: 1. The whole thing goes into software routing mode for all routes which causes 100% CPU and resulting and unusable box 2. New route entries will just get dropped, current entries just stay in TCAM 3. New route entries will be software routed, but entries that are already in TCAM will be hardware routed. You won't notice much impact in the beginning. What is true? In my experience (which is almost a decade old though) the device goes into a semi-unstable state where some traffic is dropped/unusable, and can only be fully recovered by reboot. My advice is "don't let that happen". -- Mikael Abrahamssonemail: swm...@swm.pp.se --- End Message --- ___ 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 speed
On Sun, 12 Aug 2018, ring...@mail.com wrote: It also selects a public server which is outside of your AS thus taking into consideration the busy international links which are outside of your administration andas a result for a 30Mbps package the measure shows 15 for example. My experience is that speedtest.net works well up to around 500 megabit/s, after that it starts to get unreliable. This of course means their test server needs to be not on the other side of the world, but for North America and Europe this shouldn't be the case. Without knowing exactly your conditions, I'd say your customers getting 15 megabit/s in Speedtest.net on a 30 megabit/s package actually indicates that there is a real problem. 1. Require that your customers do the measurement wired (not wifi), directly connected to your equipment (if you provide one). 2. If speedtest.net isn't nearby you or you have a weird network path to them that doesn't work well, look into how you can improve it, plus host your own speedtest server. If speedtest.net testing servers aren't able to provide 30 megabit/s to your customers, you most likely actually have a connectivity issue negatively affecting your customers, not only for their testing. I frequently test 500-1000 megabit/s subscriptions. If customer gets 200 megabit/s in a wired test, it's typically indicative of a problem. If they get 500-800, that's usually fine and it's other issues outside of your control that is affecting this (different operating systems have different TCP window scaling settings etc). But getting 15 meg out of 30, I'd say you have a problem you should look into. ___ 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 Router IRB
On Mon, 5 Mar 2018, Arie Vayner wrote: My gut feeling tells me the performance will be the same for irb and regular routing. These are software routers, so the performance depends on how many and which features you enable. There is a huge performance difference (at least in older routers and older software) between CEF-enabled forwarding paths and non-CEF-enabled forwarding paths, even on CPU based routers. Look for routerperformance.pdf and compare "process switching" and "fast/CEF switching". There is often 5-20x difference in pps. So at least back then it was important to use features that were CEF enabled, otherwise performance would go down a lot. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] ASR 9k Multicast commands
On Thu, 14 Sep 2017, Harry Hambi - Atos wrote: HI All, Logged onto a ASR9k and trying to find commands to show me the following : BSR router "show pim bsr", there are multiple commands under that. Where pim is enabled. "show pim interface" -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] ASR9K Software Recovery
On Mon, 8 May 2017, Mohammad Khalil wrote: Hi all I have upgraded my router from 5.3.4 to 6.1.2 , and I have stuck at Processor family/kernel mismatch (2/4) Crash[0,0] at init_cpu line 220 Becuase I have discovered that RSP-8G is not supported on the 6.1.x train I have 5.3.4 mini already , I just want to roll back to it Any help? You need to re-install IOS XR. The re-install procedure is called "turbo boot". https://supportforums.cisco.com/document/123576/asr9000xr-understanding-turboboot-and-initial-system-bring -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Typhoon support on XRe
On Thu, 4 May 2017, adamv0...@netconsultings.com wrote: Well people don't care about a lot of things, like how routers actually work or whether they can still protect your EF traffic when overloaded, and that's not necessarily a good thing even though everyone does it. But I guess you're right, it's just I've got a feeling we're slowly getting ripped off here, I mean it's alright if the LC is marketed as oversubscribed, but it's certainly not alright if a LC can deliver what it's marketed for only under certain specific circumstances and it seems like this "nominal performance window" is getting narrower and narrower as the BW the LCs are marketed for is increasing. And you get told - use less ports then, or buy more LCs, or don't use these two features together. I have been told this before purchase. "worst case performance with all features turned on, is X bytes wirespeed. Less features, higher pps. if you want wirespeed, don't use all ports, use 2 ports instad of 4 connected to that NPU, then it's wirespeed on those two ports". if this wasn't true, I would get upset. Let's consider NCS5K -it's one of the "100GE for everyone at the bar" type of boxes, has an abundance of these dirty cheap 100GE ports, it might not have the most feature rich NPU but it would only ever do MPLS switching so no problem there. (Btw talking about raw performance, NCS 5001 is 35Mpps per 10GE) But does the NPU's architecture allow it to protect your EF traffic even when it's overloaded (under DDoS), I don't know I haven't checked/tested, I know ASR9K LCs would. From people who like to look at theoretical edge cases, I've been told the last major platform that did this was the CRS-1 with 40G per slot. What I'm trying to illustrate here is that raw performance of the NPU is one thing, but there's also other dimensions that dictate the price and suitability of the HW for a certain project. Absolutely. For example if it's a network that can't get DDoS traffic in it and you know you're only going to have 60% utilization before upgrade, or all traffic is BE, then sure nothing to worry about. I'd also say this isn't just about PPS. It's about other features. Designing a network with lots of feature-rich edge/core features mean you need platform that supports this. If you keep down the features required, you typically have more platforms to choose from. But yes, I agree, the type of traffic you're expecting worst-case dictates what platforms you can choose and how to use them. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Typhoon support on XRe
On Tue, 2 May 2017, adamv0...@netconsultings.com wrote: Oh dear, 16.67Mpps budget per 10GE is now acceptable? We're doomed. This has been in the making for a long time. There have been plenty of offerings where the line rate min-packet size kept creeping up and up. Cisco 12000 wasn't line-rate until engine2, then engine5 started slightly skimping on that, engine 2, 4 and 6 are the only wirespeed POS linecards that I know of. Even the CRS-1 tapped out around 80 bytes wirespeed rate if I remember correctly, and there is/was an ASR9k 100G LC that only will do around 200-250 bytes minimum packet size (if I remember correctly, again). So I'd say the market has spoken, people don't care about wirespeed anymore, hasn't for 10 years at least, and the market is catering for wirespeed forwarding at around 100-200 bytes min sized packets. If you want more than that, then you have to typically use fewer ports per NPU, if the internal wiring allows for that kind of "trickery" to get wirespeed out of the NPU by using less oversubscription of its capacity. Also, with fewer features the wirespeed performance might be a lot better than the worst-case specified by the vendor. Going forward, it's not a bad thing to design your network to fit features commonly available in merchant silicon. People designing networks that require a "fully featured, classic-style core router" are going to discover that there is less and less focus on them, probably meaning significantly higher cost compared to the gear coming out that caters to the "less-complicated" networks. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Wierd MPLS/VPLS issue
On Sat, 3 Dec 2016, Christian wrote: BU says its known limitation, which is very weird. I guess that with next RFI/RFQ I need to explicitely ask for all supported protocols and services a L2 switch is capable to switch. No, you tell them to send you devices that work. What you described regarding BFD is not acceptable. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IPv6 routing vs IPv4 Nating
On Mon, 22 Aug 2016, Scott Voll wrote: I'm not really able to wrap my mind around what best practice would be. Currently I have two exit points in my network. BGP / iBGP. Two Firewalls behind those. Each Firewall has a IPv4 Class C to NAT to. With publicly Routed IPv6 not nat'ing how do I setup the firewalls / bgp to route correctly? Do I have to leak all IPv6 routes to the internal network to make sure the IPv6 address comes back to the correct Firewall? Also thinking about redundancy if one ISP / BGP router / Firewall goes down, I need it to dynamically reroute to the other side. See attached. Thank for your input. maybe I'm just missing something easy. Doesn't the below IETF I-D match your setup? https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 The fact that you don't have multiple ISPs shouldn't matter for the problem description? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] hardware accelerated ipv6ip tunnels?
On Tue, 16 Aug 2016, Harald Kapper wrote: Hi again, to answer my own question: Hi Could anyone let me know if this tunnel mode is done by PFC/DFC on sup720-3B/3C systems? After some testing it seems we're accelerated in this mode: Tunnel1 Switching pathPkts In Chars In Pkts Out Chars Out Processor 5 1050 11 1152 Route cache 68075554693 0 0 Distributed cache1173294 2592117692140285 3034842076 Total1180106 2647675122140296 3034843228 If I remember correctly, this works in accelerated mode as long you have a unique IPv4 address per tunnel endpoint. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Optic Shutdown TX State?
On Fri, 12 Aug 2016, Nick Hilliard wrote: you're very brave with your iphones. Shining a laser on a CMOS sensor doesn't seem like a smart thing to do. Smarter than looking into laser with remaining good eye. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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/7600 TCAM Usage
On Tue, 31 May 2016, Pete Templin wrote: +1 on what Gert said. You'll get log entries at the 90% threshold within a region, but the badness only happens when you tickle the 100% threshold. In my 5 year old experience, the badness would continue even if you removed some routes and TCAM usage dropped to (let's say) 95% again. The problem would only be solved by reboot. Is this still the case? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 XR and Netconf Operational Data
On Mon, 2 May 2016, chip wrote: Anyone have any example code or pointers to docs that spell this out or at least point to how to determine the request to make. Bonus if its python or perl. I've made several tools using NETCONF with the Juniper kit but am having trouble with Cisco. What version of XR are you trying to do this with? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] MTU size, fragmentation and drops
On Fri, 15 Apr 2016, CiscoNSP List wrote: My question is why? i.e. Why would reducing our PE's Ints MTU size to 1500 "allow" packets above 1500bytes to pass fragmented, but at 9100, they were dropped? There are two values here, MTU and MRU. Some devices configured for 1500 MTU are capable of receiving 9100 unfragmented packet, but will not transmit more than 1500 bytes (thus fragmenting before sending). So most likely, the CE had MTU and MRU set to 1500, and since the 9100 sized unfragmented packet sent from the PE to the CE was higher than the MRU, it was dropped. If there were some L2 switches in between the PE and CE, then it/they might have dropped it. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] NCS-5001 - MPLS L3VPN Issue
On Wed, 2 Mar 2016, Mark Tinka wrote: But aren't the fabric chassis' in multi-chassis deployments for the CRS all optics-based? Yes, but I believe the discussion was around optical backplanes within a device, not between devices. Compass EOS is the only player I am aware of that does optical within a chassi. It seems there were copper advancements in the meantime that made copper still scale well for backplane connectivity, and that's why existing vendors have kept using copper traces switch fabric connectivity instead of going optical. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] NCS-5001 - MPLS L3VPN Issue
On Sat, 27 Feb 2016, James Bensley wrote: Erase the box, push up the new image and original config. That way the network state is known at all times without having to ask the PEs. Everything is nice and consistent. This is a workaround because the vendor did a shoddy job with package and configuration handling. I prefer that the vendor does a proper job. We'll see if XR 6.x actually is properly done, or if it's just failed promises again. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] NCS-5001 - MPLS L3VPN Issue
On Wed, 3 Feb 2016, Lukas Tribus wrote: But then again, when you do need that particular SMU, that isn't covered by any SP yet, you can't apply it and you have to wait for the next SP containing this fix - which kind of defeats the purpose. I still expect Cisco to do some kind of "hotfix", which is what SMUs are good at. Fixing some specific issue until next SR comes along. My biggest objection was that historically one had to apply 40-50 SMUs at a single time, some obsoleted others, some depended on others. It was just hell to figure out how to get where one wanted to be. Often you found out if you missed something after 30-60 minutes and you got a rejection message that something went wrong. There was no mechanism for automatically including SMUs that another SMU depended on. So software application path should be (and this is what I hope they're doing): Version x.y.z SR every 1-4 months, which rolls up all fixes and removes all previous SMUs and SRs during install. SR has no dependencies apart from what version it applies to. SMUs for the last SR for hotfixes that are so new that the fix hasn't made it into an SR yet. I've been told XR 6.x will have a new package handler, I am curious to see if that actually fixes a lot of the problems. I kept stating to people involved with XR that the Debian apt tool was better in 2000 than the package handling in XR in 2014. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] NCS-5001 - MPLS L3VPN Issue
On Wed, 3 Feb 2016, Adam Vitkovsky wrote: Yeah I don't like Service Packs, I think it's better to cherry pick only SMUs that are relevant to bugs that you might run into. And there's always a danger of reintroduction of bugs e.g. a SMU fixes recent bug but reintroduces bug that was fixed by some older SMU. I have spent a non-trivial amount of time going through SMUs and testing upgrades. Considering that Cisco do not do testing of SMUs in any-to-any configuration, I am a big proponent of SPs, where the SP is properly tested, and contains all rollup bug fixes. I've run into issues where two SMUs didn't work together, and when I complained I received the answer that this was never tested. I've also run into issues where all SMUs couldn't be applied together, requiring two reboots to apply all SMUs. So... again, big proponent of properly tested SRs instead of SMU-hell. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] NCS-5001 - MPLS L3VPN Issue
On Tue, 2 Feb 2016, James Bensley wrote: My mind is pretty set on this, their testing has been appalling (I’m obviously moaning at Cisco about this) – I’d like to know what others think. Back in the late 00:s XR for the CRS was rock solid (as long as you managed to get the thing up and running), especially if you ran without a lot of new features. Basic LDP+MPLS+ISIS+BGP just worked for years without issue. I believe this was a factor of fairly low number of features and fairly high price for the platform, so Cisco could pay for proper testing of the features they offered. Now, everybody wants all kinds of features, the feature velocity has been extremely high for the past 5-8 years, and at the same time people don't really want to pay much. Thus, you get more features that are less tested, because testing them is complex, and yet I'm sure there is less money for testing. Of course Cisco could do a better job here, but one also has to recognise the market condition our vendors are acting in. At least it's my experience that even though there was a shared code-base between ASR9k and CRS, XR worked a lot better on CRS. My guess is that this was due to level of testing and that they were in different BUs back then. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] NCS-5001 - MPLS L3VPN Issue
On Tue, 2 Feb 2016, James Bensley wrote: IOS-XR is much needed but jesus christ its been buggy as hell for us on the 9000 series routers. Stable, cheap, fast. Pick any two. I am not aware of any product the past 10-15 years that didn't have serious bugs at first customer shipment. If you want something that works, wait 1-2 years after first customer shipment and try it, then it usually works. Now, at that time it's not fast and cheap anymore... -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Equipment for a large-ish LAN event
On Wed, 9 Dec 2015, Roland Dobbins wrote: On 9 Dec 2015, at 8:19, Laurent Dumont wrote: arp-inspection DAI is a self-defeating misfeature which can result in a self-DoS of the switch. Don't enable it! DHCP Snooping and IP Source Guard are very useful anti-spoofing mechanisms, and should be enabled on the access ports. Also, Root Guard, Loop Guard, and BPDU-Guard should be enabled in a situationally-appropriate manner. Don't forget to enable this for IPv6 as well. Potentially you could use protocol based vlans and put each player port into its own /64 whch solves most of the complexity and dynamic inspection stuff, you could even have static ACLs on each subinterface/port if you want to. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Equipment for a large-ish LAN event
On Tue, 8 Dec 2015, Laurent Dumont wrote: We were looking at either the Nexus 7004 chassis or the ASR 9004/9006 chassis as the core "switch". We would then use 48xGigE and 1x24 SFP+ line cards. Our actual port requirements and somewhat flexible but we do need at least 4x10G Fiber ports. And at least 48 GigE ports for players or access switches. I don't really understand your topology. 2001-2004 I was involved in providing network connectivity to around 2500-4500 users at Dreamhack, back then the largest LAN in the world as far as we knew. Back then we made do with 2x100FE for 20 computers and the core connectivity was 2xGE. I'd say your design seems to fairly similar, but with 2x10GE instead, but I'm just guessing from what you wrote. ASR9k has been used before and will do just fine. Dreamhack has grown a bit since I was involved: http://www.cisco.com/c/dam/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/dreamhack_v4acs_final.pdf http://www.extremetech.com/extreme/107245-inside-the-worlds-largest-lan-party http://www.pack4dreamhack.nl/interviews/dreamhack-behind-the-scenes-network/ I'm also open to any suggestion within Cisco portfolio. Our needs are pretty standard and nothing extraordinary but we would like to use this opportunity in order to try new equipment and technologies that are usually only seem within ISP and large networks. Don't forget to provide dual stack (IPv4 and IPv6) connectivity. Limit your broadcast domains (I'd say 20-50 users per broadcast domain), and make sure you do antispoofing (BCP38) for everybody. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 7600 Router Related
On Sun, 27 Sep 2015, Shoaib Farhan wrote: Hi everyone, We are going to migrate to 7600 series router and after some study we came to below sets for router. We would run L2/L3 MPLS VPN, VPLS, BGP, IPv6, OSPF, Netflow. Traffic would be over 2 gbps and we need few 10G ports and scope for future growth and also consider cost. Which set would be the better? If you're buying the ES or SIP cards for the 7600, then you might as well start looking into ASR1k and ASR9k (as others have suggested), because most likely the price difference is going to be small and you'll get hardware/software that is going to be supported for a lot longer time. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 7206 VXR || Can I use new old IOS with new bootloader
On Mon, 21 Sep 2015, Zahid Khan wrote: Hi Guys, I have Cisco 7206 VXR, I upgraded the boot loader and upgraded the IOS.Details of which is as below. Suddenly I found that the CPU utilization is going very high upto 90%. Old Bootloader :*c7200-kboot-mz.123-9.bin* Old IOS :*c7200-jk9s-mz.124-25d.bin* New Bootloader:*c7200-kboot-mz.151-4.M10.bin* New IOS:*c7200-adventerprisek9-mz.151-4.M10.bin* Now as a immediate resolution, I want to restore back to old IOS. So my Q is, can I reload the router with old IOS without downgrading the bootloader or I should downgrade the bootloader and then boot with old IOS. A newer bootloader can always load an old IOS, so keep your existing boot loader, especially with the above versions which are both fairly recent (and not 15 years old). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] issues with Cisco 12413 12.0(32)SY15 per packet load balancing
On Wed, 12 Aug 2015, Sathiyan D MPLS_NOC wrote: Hi, We are trying to do per packet load balancing for cisco 12413 router with IOS of 12.0(32)SY15. As this is active network, whether enabling per packet load balancing will cause huge upsurge in CPU util and whether any issues will come enabling per packet load balancing From the IOS version and the name, I would imagine you're talking about some kind of GSR (Cisco 12000)? There is no 12413 router. If it indeed is Cisco 12000 you're referring to, then what kind of linecards and what kind of interfaces do you plan to use per-packet loadbalancing on? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 fragmentation and ASR9001
On Tue, 11 Aug 2015, Gert Doering wrote: Indeed... "it might be implemented eventually, but today it isn't, so if you turn it on, your packets will be destroyed in creative ways" :-) But I'm relieved that it's not only me who can't find a formal word on this. With the kind of router that ASR9k is, you most likely find it under support if it works ok, otherwise it's not mentioned at all. Re-assembly of fragmented packets is typically something that routers do not do. As soon as you need to keep state across packets you need a fairly differently engineered device. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Fibre Channel over SDH STM64
On Mon, 6 Jul 2015, Jared Mauch wrote: I would have to imagine something like this would be up your alley: http://www.mrv.com/sites/default/files/datasheets/us_pdfs/mrv-fd-dmr10g.pdf This should take an 8G fiber channel SFP+ and allow it to come out in a 10G SDH framing. Reverse on the other side and it "should" just work. I doubt it. That device seems to do 3R which means it does not look past individual bits, and it can't do speed conversion (because that would require media insight). So it means it can do MM to SM for 8G but it won't do 8G over 10G. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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-XR and interface discards (input)
On Thu, 14 May 2015, Hank Nussbacher wrote: The config on the interface looks like this: interface TenGigE0/1/1/7 mtu 9028 ipv4 unreachables disable ipv6 nd dad attempts 5 ipv6 address 2001:798:28:20aa::6/126 monitor-session No1 ethernet flow-control bidirectional carrier-delay up 100 down 4000 load-interval 30 flow ipv4 monitor fmp-nfsen sampler fsm-nfsen ingress transport-mode wan ipv4 access-group catch13-ing ingress ! Any clue would be helpful for us to begin to debug this issue. I would look at this: http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-0/troubleshooting/guide/tr40asr9kbook.pdf , especially the "show controller interface TenGigE0/1/1/7 stats" output. I don't remember exactly how this works, it was two years since I last did this, but I seem to remember that on some plattforms if an ACL causes a packet loss, it's seen as "input drop". Also, I am curious behind your reasoning for the carrier delay settings (I'd say they are backwards to what I would configure), and why are you using flow control?. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] multicast routing tabel
On Tue, 12 May 2015, harbor235 wrote: I want to ensure that enabling multicast does not overwhelm my router memory resources, does anyone know how to estimate memory requirements for multicast? What "memory" are you talking about? What platform is this? There are multiple kinds of memory and different platforms work differently. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] 7204VXR replacement suggestions needed
On Thu, 30 Apr 2015, Steven Pfister wrote: doing BGP, getting a default route, plus a small table of Internet2 This is the most important part of what you wrote, if you can fit number of concurrent routes into one of the L3 switch platforms, you can do what you want at a fraction of the cost of a router that can do full DFZ routing table. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 Router 2821 is having issue & getting error
On Thu, 23 Apr 2015, Ahsan Rasheed wrote: Hi Guys, I am having issue in my lab router Cisco 2821. This router is booting on rommon mode all the time. I checked flash of this router in another working router. So flash is working fine in another router. I tried to use another Was this "working router" also an 2800? What size of CF card are you trying to use? Is it larger than 256MB? http://www.cisco.com/c/en/us/td/docs/routers/access/2800/hardware/installation/guide/hw/01_hw.html External CompactFlash memory cards of the following optional sizes: •64 MB (default) •128 MB •256 MB -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] CRS secondary RP not syncing properly
With XR 5.1.3, I applied most of the SMUs available today. After that I issued a format command for disk0: on the secondary RP, which then rebooted according to plan and started syncing from primary RP. I then started getting these messages on the secondary RP (with the SMUs, it was for the -sse- package): Apr 09 11:34:25.192: Install Setup: Syncing package 'disk0/iosxr-fwding-5.1.3': This (D)RP Node is not ready or active for login /configuration Apr 09 12:11:52.328: Install Setup: Failed: Unable to sync all of the contents of '/disk0/iosxr-fwding-5.1.3' Apr 09 12:11:52.494: Install Setup: Failed to sync some packages or meta-data Apr 09 12:11:52.495: Install Setup: Install Setup (pid 53288) has failed to prepare this node successfully and will now exit: (2949233664) 'Subsystem(8083)' detected the 'fatal' condition 'Code(30)' Apr 09 12:11:56.457: Install Setup: Using install device 'disk0:' Apr 09 12:11:56.468: Install Setup: Using MBI device 'bootflash:' Apr 09 12:11:58.696: Install Setup: Preparing devices: Apr 09 12:11:58.707: Install Setup: Complete Apr 09 12:11:58.954: Install Setup: Starting package and meta-data sync Apr 09 12:11:58.966: Install Setup: Cleaning packages not in sync list Apr 09 12:11:58.968: Install Setup: Complete Apr 09 12:11:58.975: Install Setup: Syncing package 'disk0/iosxr-fwding-5.1.3': ... and this never fixes itself. I put the secondary RP in bootrom and deactivated all the SMUs on the primary RP, and then removed them. This still didn't fix the problem. I'm pretty sure I could go on-site, format the disk0: in the secondary RP, and boot it, and the sync would work just fine. I have serial console on the secondary RP. So my question now is, is there a boot variable I can set to make XR either format or completely "clean" disk0: on secondary RP after initial boot? I know this can be done with turbo-boot, but I haven't been able to find anything on how to do this if I don't want to turbo-boot. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 XR needs PIM&MLD for clients to receive multicast stream
On Tue, 10 Feb 2015, Adam Vitkovsky wrote: Hi Mikael, Have you enabled the CE facing interfaces under "router igmp" please? (oh and XR uses IGMPv3 by default). - but can't recall if it worked at the end or the PIM was indeed necessary. I am not using IGMP since this is IPv6 and I'm using MLD instead. So I have now worked around this issue by letting XR enable PIM&MLD on all interfaces (using the "interface all" statement under "multicast-routing"), but implementing a PIM IPv6-wide neighbor-filter to only allow the router-to-router interfaces to form PIM neighborship, plus configuring "version" directly under "router mld". This way it seems I get away from having interface-unique entries under router pim and router mld. I still don't understand why the design choice to require PIM to be running on a client-interface, was made. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IOS XR needs PIM&MLD for clients to receive multicast stream
Hi, I am re-learning multicast for the 3-4th time in the past 10 years now so I'm rusty. IOS XR machine (ASR9k). PIM-SSM (group in ff38::/96) multicast-source--R1--R2--R3--client This is R3: multicast-routing address-family ipv6 interface-inheritance disable interface all enable I enable the interface in "router pim" and "router mld", and everything is fine, client can receive multicast stream after MLD join, mrib of course looks great. Why can't I now disable PIM? Why is PIM needed on a client-only interface wherefrom I don't need any multicast sourced, just want clients to be able to MLD join streams from elsewhere. If I disable PIM, mrib still looks almost the same, but there is no multicast being forwarded out that interface towards the client. I really would like to avoid having to run PIM on thousands of (sub)interfaces, which on top of everything needs to be protected with an ACL because I don't want my customers to be able to establish a PIM session with my router. Without PIM: #show mrib ipv6 route Mon Feb 9 15:17:16.770 CET IP Multicast Routing Information Base Entry flags: L - Domain-Local Source, E - External Source to the Domain, C - Directly-Connected Check, S - Signal, IA - Inherit Accept, IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID, MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary MoFB - MoFRR Backup, RPFID - RPF ID Set Interface flags: F - Forward, A - Accept, IC - Internal Copy, NS - Negate Signal, DP - Don't Preserve, SP - Signal Present, II - Internal Interest, ID - Internal Disinterest, LI - Local Interest, LD - Local Disinterest, DI - Decapsulation Interface EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap, EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed, MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface IRMI - IR MDT Interface (,) RPF nbr: fe80::da67:d9ff:fe4b:510c Flags: Up: 00:00:09 Incoming Interface List HundredGigE0/0/0/0 Flags: A, Up: 00:00:09 Outgoing Interface List TenGigE0/2/0/3.2021 Flags: LI, Up: 00:00:09 When I enable PIM, I get: Outgoing Interface List TenGigE0/2/0/3.2021 Flags: F NS LI, Up: 00:01:59 Now everything works as it should. and when I disable PIM, it goes back to: Outgoing Interface List TenGigE0/2/0/3.2021 Flags: LI, Up: 00:02:36 F means "Forward", so it's pretty obvious that the forwarding plane stops the forwarding of this multicast group without PIM enabled on the interface. I just don't understand why. Could someone please enlighten me? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 LDP Sync w/ ISIS over point to point Link
On Tue, 3 Feb 2015, Troy Boutso wrote: Getting back to my point ... If I remove the mpls ldp sync on both routers the ISIS adjacency forms immediately. So this is definitely the culprit. How on earth is this feature supposed to work in a production environment? Am I missing something here? I've had this problem 6-8 years ago, on XR. A router lost all its connectivity, and when connectivity came back the ISIS session didn't come up because LDP wasn't done, and LDP wouldn't come up because the loopback prefixes weren't reachable because ISIS wasn't up. This isn't normally how it should work, because ISIS should come up anyway, but with very high metric. This doesn't seem to be the case on all XR codebases though. What version are you running? You probably have to choose between LDP session protection and "mpls ldp igp sync" on your code base. You can't use both it seems. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Customer getting its own AS
On Tue, 7 Oct 2014, redscorpion69 wrote: which are all given to our customer. Their prefix is outside of bigger aggregation. Ok, that was important information. This is why I asked, what if upstream providers filter based on AS+prefix. Could we ask them to accept same prefix from two different origin ASs for a short time ? What are your suggestions ? I would contact my upstream just like you say, and also add their new AS to the route-object so the route-object has two ASes mentioned in it. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Customer getting its own AS
On Tue, 7 Oct 2014, redscorpion69 wrote: One of our customers just got AS number. He is going to keep our addressing scheme (so Provider Assigned address space). What is the best strategy to change static routing to now new BGP sessions on few of POPs. Where does deleting ripe object and creating new ones come into play? So in other words what would be the best order of operation to migrate customer with least amount of downtime? There should be no downtime if you do it right. Set up BGP sessions. Make sure prefixes and default route are being propagated. Delete static route(s). Traffic now flows according to BGP routing. Change route object. In case someone has a problem with the route object, your encompassing larger prefix is going to make sure you get the traffic anyway. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Removing An Interface from a Port Channel
On Mon, 22 Sep 2014, Harry Hambi - Atos wrote: I have a trunk with 4 interfaces what is the quickest way to remove ONE interface from the Port channel?, is the command Default interface gi x/y/z adequate?. Thanks in advance. A colleague of mine removed an interface recently from a port channel and the interface retained the information that was applied by being a member of the port channel this caused a loop. Don't want to repeat this. Are you running LACP or not? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Issue with MPLS implementation using cisco ME-3750-24TE-M within our backbone
On Fri, 12 Sep 2014, Thomas Braun wrote: Hi, for MPLS to work, you need to use the following ports: interface GigabitEthernet1/1/1 interface GigabitEthernet1/1/2 Exactly, these are the only ports that allow MPLS labeled packets, ie these are the only ones you're allowed to configure "mpls ip" on. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Issue with MPLS implementation using cisco ME-3750-24TE-M within our backbone
On Fri, 12 Sep 2014, thucydide tajouo wrote: I said : "Note that between PE and LSR, we use VLANs interface (because MPLS cannot be enable on physical interfaces)." because of what you can see on the image in attach according to this http://www.cisco.com/c/en/us/td/docs/switches/metro/catalyst3750m/software/release/12-2_55_se/configuration/guide/3750metro_scg/swmpls.html#wp1182634 until now, i realize that when MPLS is disabled on MPLS cloud interfaces, i can ping from one customer from another but when i enable it again, ping cannot pass. I don't understand your terminology. "cloud interface"? "VLANs interface"? Please post config. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Issue with MPLS implementation using cisco ME-3750-24TE-M within our backbone
On Fri, 12 Sep 2014, thucydide tajouo wrote: Note that between PE and LSR, we use VLANs interface (because MPLS cannot be enable on physical interfaces). What do you mean here? You can only do MPLS on the rightmost two SFP interfaces on the ME3750. So i wanted to know if there are particulars details to consider when implementing MPLS with ME-3750-24TE-M. How am i supposed to do. Apart from that they have very little RAM and forwarding table, everything is fine :P They're very restricted, make sure you test them properly for your scaling needs. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] 7301 - copper vs fibre port throughput
On Mon, 1 Sep 2014, Tom Storey wrote: If it can push 500-600 with a gigabit port, why cant it push 100mbit on a 100mbit port? Thats my question. :-) Without doing fault finding when there was actually a problem, we'll never know. What is at least needed is to look at the interface counters at each end, make sure there is no policing of traffic anywhere, etc. There is no obvious culprit from what you have described so far, the solution you described should have worked, at least up to 70-90 megabit/s of actual TCP througput. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] MTU on XR
Hello. http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/116350-trouble-ios-xr-mtu-00.html What I can check personally with machines I have available, the above article is correct in saying that vlan tags does not count when it comes to configuring MTU. XR will automatically add number of vlan tags when programming MTU to the hardware, no care has to be taken to configuring it, at least not for L3 interfaces. On an interface with MTU 9200 on the main interface, the subinterface has this: #show im database interface Te0/3/0/0.101 Interface TenGigE0/3/0/0.101, ifh 0x06001340 (up, 9204) Interface flags: 0x00800597 (ROOT_IS_HW|IFINDEX |SUP_NAMED_SUB|BROADCAST|CONFIG|VIS|DATA|CONTROL) Encapsulation:dot1q Interface type: IFT_VLAN_SUBIF Control parent: TenGigE0/3/0/0 Data parent: TenGigE0/3/0/0 Views:GDP|LDP|L3P|OWN ProtocolCaps (state, mtu) - Nonevlan_jump (up, 9204) Nonedot1q (up, 9204) ipv6ipv6_preswitch (up, 9186) ipv6ipv6 (up, 9186) so this single tagged subinterface has automatically had its MTU raised to 9204 to accomodate the vlan tag, even though config says 9200. The IPv6 MTU ends up being 9186. This for instance contradicts what AMSIX has written on this page: https://ams-ix.net/technical/specifications-descriptions/config-guide "5.7. MTU Config On Cisco IOS, the interface IP MTU should be set to 1500. MTU configurations for IOS-XR include the Layer-2 headers, and need to be adjusted when using VLAN tags." So which one is correct? I have talked to numerous people and they have different experience and results are contradicting. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] 7206 Gigabit Ethernet Card - Strange behavior
On Tue, 8 Jul 2014, Joseph Mays wrote: I have a Cisco 7206 with a Gigabit Ethernet card in it. I’m getting what I think is anomalous behavior, but I’m not sure. http://www.atm.tut.fi/list-archive/cisco-nsp/msg13448.html In that thread it's said that the combination you're trying isn't supported. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Peering with AS larger than 65535
On Wed, 30 Apr 2014, CiscoNSP List wrote: Have an oldish 7200-G2 in the lab that I need to setup with test peering with an AS larger than 65535 - It does not accept asdot notation (i.e. throws an error when I enter the converted AS - It doesnt like the "."). Why do you want to use the asdot notation? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 telnet access
On Tue, 8 Apr 2014, Olivier CALVANO wrote: The problem does this product from certain IP source, not for all a idea of this problems ? Does it have VRFs on it? Are you trying to telnet within the vrf? http://www.archivum.info/cisco-nsp@puck.nether.net/2007-02/00677/Re-(c-nsp)-Catalyst-4507R-and-VRF-Lite.html -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Licensing ASR9k
On Tue, 1 Apr 2014, Rob T wrote: We've 'inherited' some ASR9k's due to takeovers, and we are in the process of getting them SmartNet'ed if possible.In the mean time, is it possible to use the IOSXR from an already SmartNet'ed ASR9k to upgrade these routers, or is the IOS linked to the serial of the router itself ? There is no binding of software version to serial number of chassi, so just take the software you already have and apply to them. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] how to reload an asr9000 with dual rsp's
On Mon, 31 Mar 2014, Aaron wrote: How do you reboot the entire chassis of an asr9000 that has dual rsp's ? When I do "reload" it fails over the redundant rsp's back and forth and I never get a full reboot with the router and its linecards Go into admin mode and reload all RPs, then it'll do both at the same time. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Upgrading to 40G
On Fri, 28 Feb 2014, Mark Tinka wrote: Personally, I think this indicates a fundamental lack of focus from vendors (and the IETF) in understanding the actual problems operators have and need to solve. So for this perticular problem statement, it's standardized in IEEE, not IETF. Also I would say there is a fundamental lack of focus from operational people when it comes to progress in making the standards better and more efficient. Ops people are like any other recipient of developemnt, if you ask them, most of them just want the same, but more and cheaper. Doing leaps in efficiency isn't something they do, because that's not what they focus on, they focus on stability. I can understand that ops people feel the IETF or IEEE isn't taking their views seriously enough, but where should the balance be struck? I know some ops people who just want things to be the same, forever, because that's what they know and that's safe and stable. So, we're always going to have this conflict in order to have progress. The struggle is good, because you don't want ops people to rule the world and you don't want protocol designers to rule the world, you want compromise between the camps, that's when good balance usually happens. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Upgrading to 40G
On Fri, 28 Feb 2014, Mark Tinka wrote: While I can appreciate this, history has always proven that users will find a use for something for which it wasn't initially intended - y'know, like using a Cisco 2901 as a core router :-). I am all for "abusing" equipment in manners the vendor didn't think about, but it also helps to know what application the vendor thought the equipment would be used in, in order to understand why things are the way they are. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Upgrading to 40G
On Fri, 28 Feb 2014, Pshem Kowalczyk wrote: At this stage we wouldn't be able to justify the spend to go 100G on ASR9k. We're not talking about a single router or interface here, but quite a few. Besides - that doesn't really answer the question what to do with distances over the 10km. When 40GE and 100GE was standardized it was taken for granted that 40GE would be used to connect servers and perhaps a little inter-building backhaul, because of that only up to 10km was standardized. If you want longer reaches, you have to do 100GE. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] 7200VXR to ASR upgrade
On Tue, 18 Feb 2014, Adam Greene wrote: move to the ASR platform. They may keep the 7204VXR/NPE-G1 for redundancy Just to save you confusion in the future. There is no "the ASR platform". There are multiple. You'll incur less confusion if you actually say ASR1k which has absolutely nothing in common with the ASR9k, ASR5k or ASR90x platforms (which each of them have nothing in common with each other, ASR is just a marketing name). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] uBR7246VXR - etherchannel outbound load balancing ?
On Tue, 4 Feb 2014, Aaron wrote: see any of those load balance tweaks as options in the cmts.. Is it possibly ? if so, how? I did a TAC case on a 7200 with FE a lot of years back, and the conclusion was that etherchannel load balancing didn't work very well. I would recommend you to use ECMP instead (have two links with separate IPs on them) and see if that works better. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Search small replacement for Cisco 12k with ATM/OC3 interface
On Mon, 20 Jan 2014, Sigurbjörn Birkir Lárusson wrote: There is a warning on boot up that the router might explode and spread its ashes into space (or similar). This is not my experience. The warning seen when booting 15.2M on a NPE-300 isn't shown when booting it on an NPE-400. 15.2M (latest) will boot on NPE-300 with 256M of ram (with warning saying it's not supported), but there isn't much memory to spare for routes. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Search small replacement for Cisco 12k with ATM/OC3 interface
On Mon, 20 Jan 2014, Gert Doering wrote: It is still supported? Oh, thanks for that info. I thought NPE400 was also EOL already, and end of software support - good to know (and end-of-life announcements for the NPE-G1 have been sent). Hm, I dug up the EoL announcement, and indeed it's end-of-software development in sep 2011. However, hardware support is available until Sep 2015. Also, they are still releasing images (probably because NPE-G1 runs same code). 15.2M and 15.2S seems to be the last images made for it. Last image available is from september 2013 anyway. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Search small replacement for Cisco 12k with ATM/OC3 interface
On Mon, 20 Jan 2014, Gert Doering wrote: Hi, On Mon, Jan 20, 2014 at 12:06:22PM +0100, "Rolf Hanßen" wrote: I found on Ebay: CISCO7204VXR + NPE400 + PWR7200-AC + C7200-I/O-2FE - 160 Euro PA-A3-OC3SMI ATM Port Adapter (73-2427-04 / PA-A3-OC3SMI) - 40 Euro Would that combination be sufficient? It's end of everything, so "current IOS" won't work - but 12.3M will be there, and will do everything you need (and still gets security fixes, if I'm not mistaken). Besides that, it will easily get the job done. VXR with NPE-400 isn't out of everything. c7200-advipservicesk9-mz.152-4.M4.bin for instance work just fine on NPE-400 and is supported. To original poster, you probably want 512M of ram on it. It'll use approx 130-150W of power. If you need full tables, get NPE-G1 with 1G of RAM. So +1 on the 7200 recommendation for the description of what's needed. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] ARP on ASR9k 4.3.2
On Fri, 17 Jan 2014, Mark Tinka wrote: IOS is riddled with "no ip " to turn off stupidity. If they start going down this path with IOS XR, the clean slate will have been for nothing. I agree. "Sensible defaults" has been a good thing in XR. Was the ARP change even documented? I would guess not, since "arp learning local" search finds the only mention at all in this thread. Even on www.cisco.com "arp learning local" gives no hits apart from the bug ID description. For instance, the command isn't documented in <http://www.cisco.com/en/US/partner/docs/routers/asr9000/software/asr9k_r4.3/addr_serv/command/reference/b_ipaddr_cr42asr9k_chapter_010.html>. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IPv6 in the lab......
On Thu, 28 Nov 2013, Bill Blackford wrote: My experience with Cisco IPv6 is limited but I believe you can't even configure a v6 address until you have the IPv6 SDM template loaded. You don't need to have an IPv6 address on an L2 switch, to L2 switch 0x86dd ethertype frames. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 bug locator?
On Tue, 19 Nov 2013, Pete Lumbis wrote: Yes, there are crappy bugs. I see them every day. They are written by humans with the information available at the time. TAC needs to do a better That is not the problem. If I read a crappy bug description and then contact someone with access to internal cisco systems, the internal description is *much* better. The information is there, it's just not published to customers. (since again, it's written by humans). I would say you should ALWAYS open a TAC case to fix bugs that you worry you are hitting. TAC engineers have the resources to find further details and update the bug so it's readable (yes, this is a pain in the ass. why should you have to open a case to translate a bug to English? Again, bugs written by humans, generally with limited information at the time of writing). This won't always be an easy process but it's doable. 5-10 years ago it was possible to do bug scrubs based on information on CCO. This is no longer possible, now one needs to pay advanced services for their NOS service to be able to do it, just because the customer accessable information just isn't complete enough. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 bug locator?
On Tue, 19 Nov 2013, Jay Hennigan wrote: Does anyone have a current URL for the Cisco bug toolkit that works the right way around? The link on their website now only allows you to enter a bug ID. I am looking for the original bug tool that is actually useful, where you specify the IOS version, platform, and nature of the bug, and it then gives you the bug ID. This one is kind of useless. https://tools.cisco.com/bugsearch Cisco has over the past years made their public bug information more and more useless, mostly by not documenting their bugs publically in a useful manner. That they would then cripple the search function would be no surprise to me. I have numerous times had to ask people within Cisco who have access to their internal tools for clarification on bugs in order to actually gain useful knowledge about what the bug actually is. I also had to numerous times ask cisco to actually publish the bug at all, just to be able to evaluate if a SMU should be applied or not. Yes, they released SMUs without the bug ID the SMU fixed being publically available. This has happened several times. So complain to your account team and give feedback on their website. Only by customers complaining will we see improvement. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IPv6 filters
On Thu, 14 Nov 2013, Gert Doering wrote: Easier on CPU load but more maintenance if prefixes keep being added is to filter by prefix-list... so it depends a bit on how fast your router's CPU is, how often prefixes change, etc. Just using prefix-lists has drawbacks as well, since customers who are no longer customers can end up being transited to your network because you now receive the prefix via a peer, but still announce it to your transits. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Amix Peering
On Thu, 24 Oct 2013, naresh reddy wrote: will they charge us for the traffic that we pump and pull to internet on per MB basis ?? if so what would be the cost No, they will not charge you for traffic. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 12 and 15
On Wed, 28 Aug 2013, Jeff Kell wrote: On 8/28/2013 10:46 PM, Mikael Abrahamsson wrote: Think of 15.x as 12.(5+x). There isn't that mcuh different when it comes to commands, it's mostly under the hood and of course new functionality. Is that true on the 6500? Yes. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 12 and 15
On Thu, 29 Aug 2013, Ali Sumsam wrote: Hi All, Is there any document that has a list of the differences between the commands in IOS 12 and IOS 15 of Cisco? I am upgrading one of my customer's cisco3750X to IOS15. I am aware of the basic difference, which says we need licenses for every service in IOS15. I am particularly interested in the differences in IOS 15 command line. Think of 15.x as 12.(5+x). There isn't that mcuh different when it comes to commands, it's mostly under the hood and of course new functionality. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] speed and duplex change of remote router
On Mon, 12 Aug 2013, Michael Sprouffske wrote: Is there a safe way to change the speed and duplex of a remote routers WAN connection without taking down the link while making the changes? I know if you change the speed and its wrong you will lose connectivity. I have a link that is setup auto, but my isp has their end setup 10 full. I would prefer not to drive all the way to this place to change the speed to 10 full on the wan interface. Speed can "always" be autodetected. Why do you want to disable link speed detection/negotiation? "Duplex full ; speed auto" if you really need to force duplex. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Output queues - access vs. trunk
On Fri, 19 Jul 2013, Jerry Bacon wrote: When the the ports facing the radios are in access mode, everything is good, but when they are in trunk mode (which we need), we get 2 - 3% packet loss at small packet sizes (high packet rates). We've tracked it down to output queue drops, but I don't understand why it's different for access vs. trunk. Please describe more in detail what your configuration is like. If the fluke is connected to an access port, you then vlan tag the traffic on the trunk port, then you're adding 4 bytes per packet meaning your access port is no longer wire speed and the loss you're seeing would be understandable. Any ideas? And would QOS tuning be likely to help? QOS is a way of selecting what packets to drop. I don't see how it would help here. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Card 12000-SIP-601 reboot
On Wed, 10 Jul 2013, PlaWanSai RMUTT CPE IX wrote: I think the root cause from hardware. What do you think ? I can't open TAC. SLOT 3:Jul 7 10:55:24.192 TST: RX_XBMA: (33092) FCRAM SBE detected. info: 0x8081E6E6 My guess would be that SBE is "Single Bit Error", so yes, hw failure. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IPv6 Deployment / 6PE
On Mon, 24 Jun 2013, Ahmed Hilmy wrote: from 6pe to 6vpe we need to creat a VRF as u mention and send-label only in 6pe scenario When looking for some other information, I came across this that might be useful: <http://www.ine.com/all-access-pass/training/playlist/ccie-service-provider-advanced-technology-class/ipv6-over-mpls-with-102.html> I managed to watch one of them, then it requires registration (so I can't watch this one). If it's as good as the one I watched, it should be worthwile for the topics in this thread. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IPv6 Deployment / 6PE
On Sat, 22 Jun 2013, Ahmed Hilmy wrote: But i dont have MP-BGP between IGW & RR, I have pure BGP IPv4. So ? You said it was a PE so I presumed it was an MPLS speaker. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IPv6 Deployment / 6PE
On Sat, 22 Jun 2013, Ahmed Hilmy wrote: Can i add address family IPv6 at IGW to advertise IPv6 routes to RR, since it is directly connected ? Sure. I would configure send-label there as well so that you do thing in a consistent manner, but that's a matter of opinion. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IPv6 Deployment / 6PE
On Fri, 21 Jun 2013, Ahmed Hilmy wrote: What do u think ? I don't have experience with mixing 6PE and native so I can't offer much advice in this case. I also do not know what IGW is. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IPv6 Deployment / 6PE
On Fri, 21 Jun 2013, Ahmed Hilmy wrote: We can say MP-BGP ( vpnv4 ) will carry IPv6 packets as a label across IPv4 MPLS Backone. Thanks in advance for sharing info. vpnv6 is what you need for 6VPE (IPv6 VRFs). 6PE is for "Internet IPv6", and there you do it under address-family ipv6 unicast but you add "send-label". -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IPv6 Deployment / 6PE
On Fri, 21 Jun 2013, Ahmed Hilmy wrote: Dear Friends, I am working on IPv6 deployment at our Backbone. Our network design is as below: PEs --- MP-BGP ---RR ( address-family vpnv4 ) RR-- BGP-IGW ( address-family ipv4 ) what i understand is : - Add address family IPv6 at PEs : address-family ipv6 neighbor x.x.x.x activate( x.x.x.x is IPv4 address of RR ) neighbor x.x.x.x send-community both exit-address-family Excellent document from cisco on the matter: <http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_data_sheet09186a008052edd3.html> You need "send-label". -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] QSFP to SFP+ over 300 meters: Can it be done out of box?
On Fri, 21 Jun 2013, Troy Lucero wrote: Seems there is no option here. The QSFP-40G/E-LR4 doesn't have an MPO connector like its' SR4 counterpart, so there is no MPO break-away option to choose from if I want to go 10gig over singlemode. Correct, LR4 is 4 10G CWDM waves over a single fiber pair instead of 4 parallell fibers like SR4. I can't be the only person who has tried this? Seems like a flaw in the standard to not allow you to connect 10gig beyond 300 meters right out of the box for devices that have QSFP ports. The people who wanted 40GE were datacenter and server guys. Most higher end datacom people only wanted 100GE. The number of variants wanted to be kept down. If you want 10GE-LR then you have to get dedicated ports for that or go 100GE (which I presume you'll consider budget suicide as well). 100GE does have a 10x10GE-LR breakout option (however, this is not an IEEE standard as far as I can tell). There is nothing fundamentally stopping for instance Cisco to produce a proprietary 4x10GE LR QSFP+, but I guess they didn't feel it made a lot of sense. <http://www.finisar.com/sites/default/files/pdf/Pluggable%20Transceiver%20Challenges-ECOC2012-ChrisCole.pdf> might be interesting to read if you want to see where things are and where they're headed for the future. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] ASR-9010-AC vs ASR-9010-AC-V2
On Thu, 20 Jun 2013, Ronan Mullally wrote: I think this relates to the power supplies. I noticed 'Version 1' and 'Version 2' power options in the specs a few weeks ago. When I asked our SE he told me V1 has 3 power modules, V2 has 4. The difference is essentially to provide more headroom in the event of one of the modules failing. Apparently V1 can just about do a fully loaded chassis with 2 modules. My bad. Yes, I knew about the power shelves/supplies, just didn't know that they were reflected in the chassis ID as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] ASR-9010-AC vs ASR-9010-AC-V2
On Thu, 20 Jun 2013, Mattias Gyllenvarg wrote: Dear List What is the difference between the chassie versions? Is the V2 just a hardware revision? V2 is probably the uprated FAN array, which means you can have DWDM optics in all slots in a 24x10GE card. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Cat 6500 and QoS for lower bandwidth
On Tue, 18 Jun 2013, Grischa Stegemann wrote: Thus there is no way to achieve something like a shaping down to 5MBit/s AND considering the dscp/cos-classes at the same time. You should look into "wrr-queue shape", but it's not on the cards you mentioned. <http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_538840.html> 6.5.4. Shaped Round Robin SRR is a recent addition to the scheduling capabilities of the Catalyst 6500 family. SRR is currently available only on egress and only on the WS-X6708, the WS-X6716, the uplink ports of the Supervisor 32 and Sup720-10GE. SRR is different to WRR in that the SRR algorithm provides a way to shape outbound traffic to a stated rate. In some respects, it is similar to a policer except that traffic in excess of the rate will be buffered rather than dropped as with a policer. SRR is configured by adding the keyword shape to the queue configuration and can only be configured if the priority queue is not used (no COS is associated with the priority queue) This is the CLI used to configured SRR on the uplink of the Sup720-10GE Cat6500(config-if)#int ten 5/4 Cat6500(config-if)#wrr-queue shape 100 150 200 -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] ASR1k to ASR9k CLNS MTU problems
On Tue, 28 May 2013, Pshem Kowalczyk wrote: ASR 9k calculates the MTU differently to ASR 1k. We've settled on the 9k way of calculating MTU and adjust all other platforms with "clns mtu". Our network runs mostly on ~9100, so XR uses 9114 as interface MTU and 9097 as CLNS MTU (calculated by XR). On other platforms (xe and classic ios) we apply interface MTU of 9100 with "clns mtu 9083". I'm guessing that XR takes the source/destination MAC and ethertypes field into consideration for CLNS frames (14 bytes), but other platforms don't. I'm not sure where the initial 9097 comes from though. If you configure main interface mtu 9114 on ASR9k and 9100 on IOS, it should just work out of the box, no need to adjust clns mtu or any other protocol MTU. Both Juniper and IOSXR includes the 14 byte ethernet header in the MTU calculation. IOS does not. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 XR 4.3.0 or 4.3.1
On Sun, 26 May 2013, Marc wrote: Not exactly what IOS-XR is doing. At least the number of new features in 4.2.x or 4.3.x is decreasing with increasing x. But it's not just bug fixes. For XR, I'm talking the (rollup) SMU PACKs they're doing now. The feedback I'm giving Cisco is that this is appreciated. Basically release all fixes in a rollup SMU pack every 3 months, mimicking the way IOS used to work, releasing a new fix release every 3-4 months. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 XR 4.3.0 or 4.3.1
On Thu, 23 May 2013, Blake Dunlap wrote: The problem with the wait and see approach is it is a tragedy of the commons approach. You're just outsourcing the effort to the "cloud" and hoping others are more adventurous than you are. Eventually critical mass is reached, and then even older code versions have the bugs, they last longer, and code quality gets even worse, and you can't just jump to newer code for the fixes, because they don't exist. People use new software because they perceive an upside with the new features, and they're willing to take the risk of running into bugs. This has been pretty static the past 15-20 years or so, and true of "all" software that I know of. If I don't need the new features, why would I not run a software that's been in active deployment for 6-12 months already, thus giving me a higher probability of not running into bugs? Just look at IOS, where they even have classification such as early deployment etc. You can say "tragedy of the commons" all you want, and you might be partially right, but even Cisco recognises that a major new software release will have bugs and their Advanced Services department always recommends staying away from brand new software unless you *have* to use it. Thus my yelling at Cisco to make sure that when they need to decide in a release if they want a lot of brand new advanced new features or new hw support, not both. Similar to Intels tick/tock approach, they develop new architecture one step and new manufacturing technique the next step, then new arch again. Not both at the same time. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 XR 4.3.0 or 4.3.1
On Thu, 23 May 2013, Jared Mauch wrote: That seems to be what the SE in the (now trimmed reference) was suggesting. I understand not everyone has lab/test hardware, but if that's the case how can you ever upgrade anything without risk. At some point you need to make that jump. I'd say the acceptable risk is different for each ISP. I think the question of what that unit of measure you apply. If you want to wait until X bugs are fixed, I can certainly understand where x(sub)1 for my network may not be the same as x(sub)2 for yours. Is there a specific metric for number of defects you use, or is it just some time-based SWAG? Without the vendor getting feedback that their software is good (or bad), they are left with an unknown outcome for their software release. I'm not saying everybody should do what I say. In a perfect world vendors would test there code properly and there would be no bugs. This is obviously not happening so by staying behind the curve you let others run into the bugs, they are fixed and by waiting you benefit from this. Others might say new features are extremely important to them and they don't mind rebooting their core boxes every 3 months to apply fixes. I'm can get very frustrated with Cisco on these topics. We went a round with them on 4.2.2 as we depended on that release for specific hardware. They didn't want to support it. If that's the case, there was no point of the release at all, why even ship that release? (can you feel my frustration? :-) Absolutely. I also feel that at least the ASR9k BU seems to want to abandon their "long-term" software after a year and stop supporting it. This is not what I have been used to before on other platforms. But at least there is hope that things are improving with 4.3 and later releases. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 XR 4.3.0 or 4.3.1
On Thu, 23 May 2013, Jared Mauch wrote: So everyone waits and nobody reports a bug for the first 6 months? Obviously not. I summarily reject your irrational fears of "new" software. Software is imperfect in all cases. It seems more imperfect shortly after release than after a while. I have specific defects that are keeping me from 4.3.1, these also exist in 4.2.3. Are you hitting the same bugs? I don't know. Me neither. I get very upset when they say that they won't fix things in 4.2.3 (which is supposedly a long-term support release) and they usually fix it. I take for granted that I'm not the only upset one. But rejecting something with loads of bug fixes and architecture changes to fix the whole every smu is a reload one because of a calendar without defects is irrational and illogical. I don't really understand what you're trying to say here. Anyhow, I apply the same logic here as I do in IOS-land. You start to get on 12.0(32)SYx when X is above 3 or 4. Same with SRE for 7600, SRE4-5 or so started to be ok. Cisco is not alone in this, I'd say most vendors have similar problems. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 XR 4.3.0 or 4.3.1
On Thu, 23 May 2013, Jared Mauch wrote: If 4.3.1 is too new to run why did they release it? I Love SE logic at times. Sounds like he just said Cisco will deliberately ship defective software. I would seek a new SE. Why would you want to replace an honest SE? "Everybody" knows you wait at least 6 month after major release if you want stable software. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] BGP Cease notifications with Graceful Restart
On Tue, 21 May 2013, John Neiberger wrote: the 7600, which the CRS immediately recognized, but the CRS continued to use those BGP routes until the neighbor's graceful restart timer expired. It's my experience that Cisco has a GR implemention that leaves some to be desired on a lot of platforms. I have escalated this several times to no avail. A 7600 will advertise itself as GR capable even if there is a single RP, and the BU didn't feel the need to implmement "bgp graceful-restart helper-only" even after several requests. So in our network, 7600 have no graceful restart configured. Please talk to your account team and ask them to talk to the BU and get them to fix this. Desired behaviour: On a dual RP system, advertise yourself as GR capable. On a single RP system, only do GR "helper". Either auto detect this or make it configurable. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] 4GE-SFP-LC EoS
On Wed, 8 May 2013, Antonio Soares wrote: We are trying to renew some contracts but the contracts team is refusing that saying that the card reached the end of life on 30-Jun-2011. I'd say they're wrong. --- End of New Service Attachment Date: HW For equipment and software that is not covered by a service-and-support contract, this is the last date to order a new service-and-support contract or add the equipment and/or software to an existing service-and-support contract. August 30, 2013 --- This is the date they should be looking at. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] SPA-1X10GE-WL-V2 vs SPA-1X10GE-L-V2
On Wed, 24 Apr 2013, Lee Starnes wrote: would have any issues with this or if it's only difference is the ability to do POS. I was under the impression that the WL did 10GE WANPHY (and LANPHY), not POS. POS is not Ethernet. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Most Stable IOS-XR Version for ASR9K
On Thu, 18 Apr 2013, gu...@golas.ru wrote: Try to use another version 4.2.3 with SMUs. 4.2.3 with SMUs seems stable. There are still some bugs, but nothing causing catastrophic failures (with smupack 2 released end of January). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] IPv6 Transition - IP/MPLS Backbone
On Sun, 14 Apr 2013, Ahmed Hilmy wrote: Would you please guide me from where can i start ? http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/prod_presentation0900aecd80311df4.pdf That was the first hit on "6PE" on www.cisco.com. The other hits in the list seem promising as well. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 12000 / SIP 601 / Throughput
On Thu, 4 Apr 2013, Ahmed Hilmy wrote: Thank Mikeal for your comments, yes right toe 10 GE SPAs have been inserted so i can understand from that 10 G IN / 10 G OUT for my whole SIP ? Correct, the forwarding engine in the SIP-601 is capable of a total of approximately 11-12 gigabit/s bidirectionally. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 12000 / SIP 601 / Throughput
On Wed, 3 Apr 2013, Ahmed Hilmy wrote: My questions are: - shall my SIP work half or full rate ? - full duplex, 10 GE IN / 10 GE OUT ? -SIP 601 will do local forwarding for the traffic ? ( Download coming from UP Link to Backbone ) or should go to RSP ( control plane ) and if this true so the SIP will carry only 10 GE ( IN + OUT ) ... ? Would you please share your experience about this isue. A SIP-601 will do ~11-12 gigabit/s of througput, full duplex. By inserting two 10G SPAs you've overbooked the SIP by almost a factor of 2. There is no local switching I'm aware of. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Performance issue on link
On Wed, 3 Apr 2013, CiscoNSP List wrote: Im going to up a direct connection between the 2 linux boxes (by-passing the routers), and see if there is any improvement. The most productive thing for you to do instead of just blindly trying things, is to actually do a tcpdump of your tcp traffic to a pcap file and open this is wireshark and to a TCP stream analysis so you can actually *see* what is going on. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] ipodwdm - asr 9000
On Tue, 2 Apr 2013, Aaron wrote: Any assistance is appreciated "show controller dwdm 0/0/0/0" both ends. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Performance issue on link
On Tue, 2 Apr 2013, CiscoNSP List wrote: class-map match-any MATCH_ANY match any policy-map 40MB_SHAPE class MATCH_ANY shape average 41943040 Try lowering this to 35 megabit/s to make sure you avoid the policer your provider has in place. When you do the tcp testing, do a packet capture on the servers and look for packet loss. Wireshark has excellent TCP analysis tools that can show you exactly what's going on, if the problem is maxed out TCP windows or if it's caused by TCP saw-toothing due to packet loss. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Sup2T - poor netflow performance
On Wed, 27 Mar 2013, Phil Mayers wrote: Obviously lots of people won't have this need, but it's the reason we would avoid sampling. Maybe it's an unreasonable thing to want - but we do want it ;o) The important thing is to realise the limitations of the 6500/7600 when it comes to netflow. For "Internet peering router at 10GE with typical eyeball traffic" my opinion is that 6500/7600 doesn't have working netflow. I'm sure there are use cases where 6500/7600 netflow works just fine, but not in the scenario a lot of poeple seem to want to use it. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] ASR9k sw quality (Re: Sup2T - poor netflow performance)
On Wed, 27 Mar 2013, Mattias Gyllenvarg wrote: Very nice platform, we got hit by the "MPLS payload begins with 0x6" bug. Couldn't believe it was true. This was a forwarding bug affecting all ASR9k in 4.2.1. That was the second major forwarding bug affecting 4.2.1 (the other one was ghost /32s out of null routed larger aggregates. Yay CEF bugs!). 4.2.0 and 4.2.1 has generally been a complete disaster when it comes to software Q&A. 4.2.3 with smu pack 2 (released end of january) seem to be a bit better, but I'm still worried about the SMU velocity. Also, my pet peeve is that SMUs which fixes bugs that are not yet published in bug toolkit. I found 3 in 4.2.3 yesterday, gave 1 rating as feedback, two were published within 1-2 hours of my report. Amazing that it takes customer bad feedback before things that should just work are done. One of the SMUs was released in january with the bug still in "review" yesterday. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] entry-level 10gbps for exchange
On Fri, 15 Mar 2013, randal k wrote: I love 6500s, but their Netflow sucks. So use that 6500 towards the IX but use optical splitters towards one of those PCs you were talking about and try to find something that'll look at the traffic and do netflow export of it (or sFlow). As far as I can tell, there is no "low cost" product from Cisco that'll do netflow, full routing table and the rest you probably want. You quickly end up with ASR9k and alike. So if you want to lower your cost you need to band-aid solutions together to achieve the full functionality you really need, and probably skip some nice-to-have ones. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Private IP in SP Core
On Sun, 10 Mar 2013, Gordon Bryan wrote: Also, even in a completely private core, a PE still becomes exposed to the outside world on its PE-to-CE interface when delivering Internet services. Has anyone developed any proficient methods for locking down these interfaces and making them unresponsive/secure from the outside? Put core and PE-to-CE interfaces in a dedicated public range, and then police/ACL traffic to those IPs at your edge. Private IPs should never show up in traceroute or send ICMP messages so if you're going to do that, you have to make sure you have enough functionality to make ICMP originate from a GUA loopback interface at all points.___ 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 XR and router rib rump always-replicate
On Wed, 6 Mar 2013, Mattias Gyllenvarg wrote: I was just refering too removing PIM from within Core/Dist not inter-AS. How is multicast supposed to work at all whereever for L3 routing without PIM? I'll admit I'm a bit rusty and only know about PIM-SM and PIM-SSM, what other methods are there for controlling routed multicast? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 XR and router rib rump always-replicate
On Wed, 6 Mar 2013, Mattias Gyllenvarg wrote: About that, Oliver, is multicast-BGP production ready in IOS ans IOS XR. Specifically ASR9k, 7606 Sup720, ME3600X and 3560/3750? People have been running multicast on XR (ASR9K) and 7600 since "forever". I'd be more worried about ME3600X and 3560/3750, but at least on the 3560/3750 they're mature platforms so I'd imagine it works there as well. Whould be nice too remove PIM from the core, just as Gert says limited use = limited support. How is multicast supposed to work without PIM? What Gert was talking about was "Internet" multicast, ie multicast between ISPs. Watching NASA multicast streams for instance (I did this at my university in ~1995). Very few commercial ISPs support this. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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/
