Re: [c-nsp] Internet border router recommendations and experiences

Hello, for the unititiated, how does the licensing on a mx204 look like for different or combined use-cases like pure IP edge, mpls layer3 and layer2 VPNs, BNG functionality? Thanks, Lukas ___ cisco-nsp mailing list cisco-nsp@puck.nether.net

Re: [c-nsp] asr1000 esp80

On Fri, 27 Jan 2023 at 17:09, Blake Hudson via cisco-nsp wrote: > > Seems to be a thing... > https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuq85985 > > > Crash of both active and standby ESP. Applies to ESP80, 100, and 200. It shows up in "show platform power" outputs in Cisco live

Re: [c-nsp] ASR920 randomly loosing layer-2 on a port

Hello, On Mon, 11 Jul 2022 at 18:20, Adrian Minta wrote: > Yes, this is one of the bugs in 3.x trains. The solution is to upgrade > to something like 16.12.x. Well, we don't really know what the solution is, unless someone is actually running a significant number of boxes of previously affected

Re: [c-nsp] FIB scale on ASR9001

On Mon, 15 Nov 2021 at 16:12, Mark Tinka wrote: > > > > On 11/14/21 08:58, Saku Ytti wrote: > > > I don't think IETF is making standards for specific implementation. > > The implementation agnostic solution is to keep all routes which we > > rejected due to consulting validation database,

Re: [c-nsp] FIB scale on ASR9001

On Thu, 11 Nov 2021 at 15:01, Mark Tinka wrote: > > > > On 11/11/21 15:43, Lukas Tribus wrote: > > > For ROV to work reliably it needs to be able to reconsider previously > > rejected invalids, so I would not recommend disabling > > soft-reconfiguartion in

Re: [c-nsp] FIB scale on ASR9001

On Thu, 11 Nov 2021 at 15:12, Mark Tinka wrote: > > > > On 11/11/21 16:02, Lukas Tribus wrote: > > > When I tested RTR on IOS-XR I hit some strange bugs in the RTR client, > > specifically the RTR session would hang in certain scenarios (router > > restart, R

Re: [c-nsp] FIB scale on ASR9001

Hello Gert, On Thu, 11 Nov 2021 at 08:18, Gert Doering wrote: > > Hi, > > On Thu, Nov 11, 2021 at 08:27:44AM +0200, Mark Tinka wrote: > > We have nothing against the forwarding performance of the ASR9001. It's > > the control/management plane that seems to be slowing down (at least for > > us,

Re: [c-nsp] FIB scale on ASR9001

Hello, On Thu, 11 Nov 2021 at 10:22, Saku Ytti wrote: > > On Thu, 11 Nov 2021 at 10:19, Mark Tinka wrote: > > > Thanks for the clue, Saku. Hopefully someone here has the energy to ask > > Cisco to update their documentation, to make this a recommendation. I > > can't be asked :-). > > I think

Re: [c-nsp] IOS-XR Vs. NTP in a duel to the death.

I don't think you will get anywhere without actually capturing the entire NTP traffic between the host and the NTP server and analyzing it. Lukas ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp

Re: [c-nsp] TIL: Maintenance Operations Protocol (MOP)

On Fri, 6 Aug 2021 at 09:59, James Bensley wrote: > > What is right or technically correct is not always the priority. > > This is the job we do, right? (it's the job I do anyway). We find a > way to convince the powers that be, that this is a massive security > risk for example, or for example

Re: [c-nsp] TIL: Maintenance Operations Protocol (MOP)

On Thu, 5 Aug 2021 at 21:49, Nick Hilliard wrote: > It has the appearance of a feature which is kept alive because some > customer with a huge spend demands it in general-deployment release > trains (this is idle speculation and may be completely wrong btw). More precisely, who (which employee)

Re: [c-nsp] tcp intercept on IOS-XE?

Hello, On Sun, 14 Mar 2021 at 08:05, wrote: > > We are trying to implement tcp intercept on some brand new ASR1009x > running IOS-XE 16.12.5 yet nothing is seen (sometimes). > > So I found: > https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvo01450/?rfs=iqvred > which states: > It has been

Re: [c-nsp] N9K traffic lost when redundant link comes up

On Tue, 9 Mar 2021 at 18:08, wrote: > Expected behaviour is: > New link gets active, and > if spanning tree finds this new link as "lower" it would block it. > if spanning tree finds it "better" it should start to use it and block > somewhere else. > > But monitoring was crying, and I found in

Re: [c-nsp] Cisco 6509-E SSH and Telnet not allowing connections

Hello, On Sat, 27 Feb 2021 at 20:03, Lee Starnes wrote: > > Hello all, > > Ran into an issue that I can't seem to resolve and really don't want to > reboot the chassis. Have 1 of our 6509-e units that has decided it is not > going to allow connections to it via ssh or telnet. I can get access

Re: [c-nsp] ASR9K to ASR920 MPLS issue

On Tue, 12 Jan 2021 at 18:02, James Bensley wrote: > > Can I omit the "rewrite ..." on both sides? > > Why would you want to? I think that if you do that, a VLAN tagged > frame coming into one end with VLAN 95, will be send over the > pseudoiwre with the VLAN tag still present, at the other end

Re: [c-nsp] RPKI extended-community RFC8097

Hello Jakob, On Fri, 18 Dec 2020 at 07:58, Jakob Heitz (jheitz) wrote: > > Hi Lukas, Mark, Ben, > > The default bestpath prefix-validate behavior treats invalid routes > as unfeasible and prefers valid routes over not-found. > > The default bestpath prefix-validate behavior cannot be used

Re: [c-nsp] RPKI extended-community RFC8097

On Sat, 19 Dec 2020 at 10:40, Gert Doering wrote: > > Hi, > > On Sat, Dec 19, 2020 at 10:13:36AM +0100, Robert Raszuk wrote: > > See even if you validate in route map you may just mark it not-eligible or > > set higher local pref for VALID etc I am not sure how anyone could > > come with the

Re: [c-nsp] RPKI extended-community RFC8097

Hi Ben, On Sat, 28 Nov 2020 at 01:32, Ben Maddison wrote: > > router bgp ... > > bgp rpki server tcp [...] > > address-family ipv4 > > bgp bestpath prefix-validate disable > > [...] > > route-map RM_EBGP_IN deny 10 > > match rpki invalid > > route-map RM_EBGP_IN permit 20 > > [...] > > >

Re: [c-nsp] RPKI extended-community RFC8097

Hello Mark, hello Jakob, On Sun, 19 Apr 2020 at 03:03, Mark Tinka wrote: > On 18/Apr/20 16:23, Lukas Tribus wrote: > > > > > More about this issue here: > > https://www.mail-archive.com/nanog@nanog.org/msg104776.html > > > > Code with CSCvc84848 fixed wi

Re: [c-nsp] ASR9k RSP440

Hi, On Thursday, 12 November 2020, Gert Doering wrote: > Hi, > > On Thu, Nov 12, 2020 at 10:06:11AM -0600, N. Max Pierson wrote: > > We're trying to figure out what the last train of XR software that can > run > > on the RSP440 for a 9006. We're running 6.2 right now but I can't seem to > >

Re: [c-nsp] Anyconnect VPN on IOS that supports TLS 1.2

Hello, On Fri, 7 Aug 2020 at 19:46, Chuck Church wrote: > > Hey all, > > > > I've got a small company I support occasionally that deploys > Anyconnect VPN service on small ISR G2 models for customers. It seems that > recently Chrome and it seems like Edge and IE are not allowing

Re: [c-nsp] Rehosting a perpetual CSR1000V license

Hello, On Thursday, 23 July 2020, Mark Tinka wrote: > > > On 23/Jul/20 10:43, Lukas Tribus wrote: > > > You just need a route to a HTTP proxy (like tinyproxy) in your FIB, > > just like you already need reachability for monitoring systems, NMS, > > radius servers

Re: [c-nsp] RPKI validation weirdness

Hello Robert, On Fri, 8 May 2020 at 11:42, Robert Raszuk wrote: > See when you sign a block then sell this block without removing your RPKI > signature, then the block gets cutted into chunks and sold further - and no > one in this process of transaction chain cares about RPKI - this entire >

Re: [c-nsp] RPKI extended-community RFC8097

Hi Gert, On Sat, 18 Apr 2020 at 16:24, Gert Doering wrote: > > Hi, > > On Sat, Apr 18, 2020 at 02:13:07PM +, Ben Maddison wrote: > > I meant "dumb" as in "I painted the life-saving emergency stop button > > green and mounted it on a green wall behind a locked fire-proof door in > > a

Re: [c-nsp] RPKI extended-community RFC8097

Hello, On Sat, 18 Apr 2020 at 14:44, Ben Maddison via cisco-nsp wrote: > Going back to the OP's question, though: we (AS37271) use 8097. > Not because I think that it's a particularly sensible design (I don't), > but because we have IOS-XE bgp-speakers, and you can't do ROV on XE or > Classic

Re: [c-nsp] BGP maximum-prefix on ASR9000s

On Mon, 27 Jan 2020 at 12:21, Saku Ytti wrote: > > On Mon, 27 Jan 2020 at 12:54, Lukas Tribus wrote: > > > I'm confused; I'm running Internet in a MPLS VPNs with per-ce label > > allocation on ASR9k since 2016, for both address-families. > > > > What is CSCvf152

Re: [c-nsp] BGP maximum-prefix on ASR9000s

Hello, On Mon, 27 Jan 2020 at 11:15, Saku Ytti wrote: > > For people running full tables with labels (BGP-LU or > > Internet-in-a-VRF), it's probably a good time to start thinking about > > their label consumption, if a label is allocated per-prefix (default > > in Cisco land at least for MPLS

Re: [c-nsp] BGP maximum-prefix on ASR9000s

Hello, On Mon, 27 Jan 2020 at 08:14, Mark Tinka wrote: > On 27/Jan/20 08:05, Hank Nussbacher wrote: > > > As many of us run full routing tables on our ASR9000s, we have just > > found popping up in our logs: > > gp[1058]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes > > received from

[c-nsp] Rant: ASR1000 MPLS (not) load-balancing

Dear list, tl;dr: this is a rant about ASR1000 not load-balancing (Eo-)MPLS traffic. So the common approach to load-balance MPLS packets at the LSR (ingress MPLS, egress MPLS) is to either look at the payload (IPv4/IPv6 source/destination address if that is detected) or to fallback to

Re: [c-nsp] ASR920 and EEM:Mandatory.dualrate_eem.tcl

Hello Gert, On Mon, 26 Aug 2019 at 14:47, Gert Doering wrote: > > Hi, > > does anyone know what "EEM:Mandatory.dualrate_eem.tcl" is? > > We have an ASR920 that grew an unexpected config change upon insertion > of a DAC cable into port ten0/0/12, and "unexpected config change" always > triggers

Re: [c-nsp] GTSM IOS-XR

Hello! On Tue, 6 Aug 2019 at 19:38, Saku Ytti wrote: > > If you are running GTSM in IOS-XR, it does not work. TTL is verified > during 3-way-sync, not after. So anyone can reset that session with > trivial amount of packets in subsecond. > > Cisco is is having internal problems arguing if this

Re: [c-nsp] Nexus Lack of Functionality Parity

Hello Mike, On Mon, 15 Jul 2019 at 16:17, Mike Hammett wrote: > > Is it common for there to be a lack of functionality parity across the Nexus > line? Yes, default logging on the Nexus is different on different series switches and at least on the 7k/9k is also a giant trap (a Nexus 9k by

Re: [c-nsp] ASR 920 Replacement

Hello, On Wed, 26 Jun 2019 at 15:59, Muhammad Asif Rao wrote: > > Hi, > Going through ASR 920 and look like EOL announced already. I don't see any EOL announcement for the ASR920 (other then software). Can you clarify what you mean and link to that EOL announcement please? cheers, lukas

Re: [c-nsp] ASR920 is a ticking timebomb (CSCvk35460)

On Wed, 20 Feb 2019 at 10:31, Lukas Tribus wrote: > CSCvk35460 is now marked as a duplicate of CSCvc27889, which has a > different trigger (reload, as opposed to long uptime). > CSCvc27889 is fixed in 15.5(3)S6 (XE 3.16.6). > > Apparently the symptoms of CSCvk35460 sound somehow s

Re: [c-nsp] ASR920 is a ticking timebomb (CSCvk35460)

Hello, CSCvk35460 is now marked as a duplicate of CSCvc27889, which has a different trigger (reload, as opposed to long uptime). CSCvc27889 is fixed in 15.5(3)S6 (XE 3.16.6). Apparently the symptoms of CSCvk35460 sound somehow similar to those of CSCvc27889 to Cisco, although I've yet to get a

Re: [c-nsp] ASR920 is a ticking timebomb (CSCvk35460)

Hello, On Wed, 23 Jan 2019 at 13:37, Tassos Chatzithomaoglou wrote: > > > Has anyone been hit by CSCvk35460? > > Symptom: > counter not increasing under show interface even though packets are > being forwarded normally > > Conditions: > ASR920 is running for nearly 889 days > > Workaround: >

Re: [c-nsp] Strange problems with Cisco ASR1002 RP1

Share the "show ip interfaces " output please. ___ cisco-nsp 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 ASR RIB Failure ?

Hi, On Wed, 5 Dec 2018 at 07:58, Olivier CALVANO wrote: > > Hi > > On all of my router, i have : > > ASR1002.BLD1#sh ip bgp 172.16.0.1 > BGP routing table entry for 172.16.0.1/32, version 1184149 > Paths: (2 available, best #1, table default, not advertised to EBGP peer, > RIB-failure(17)) > >

Re: [c-nsp] [j-nsp] Strange issue

On Mon, 10 Sep 2018 at 15:53, james list wrote: > > Dear experts > I'm wondering if you can provide any hints/help on this problem. > > We experienced a strange issue in reaching the remote devices (servers) and > perforiming bulk snmp walk, instead direct object query was working fine. Sounds

Re: [c-nsp] ISIS Fast Convergence (ASR920?)

Hello, On 28 February 2018 at 19:31, Jason Lixfeld wrote: > Hey, > > There seem to be some conflicting suggestions for ISIS fast convergence > timers, and I can’t seem to understand why that would be. The former > example is ISIS in a LFA FRR environment, the latter is from

Re: [c-nsp] Nexus 7k Upgrade Path

Hello, On 23 February 2018 at 08:58, Pete Templin wrote: > I would even go so far as to: > > load system/kickstart files > isolate the box (shutdown all ports) > power-cycle the box, let it boot into the new code > perform EPLD updates on all cards > run the ISSU command

Re: [c-nsp] NCS5501(-SE) in P and SP Peering roles

>> The NCS5001 is out of scope here, as I was recently told that it’s not >> recommended as a P; it’s not (any longer?) a supported use case. > > No doubt, it's a L2 switch, which happened to do some MPLSy stuff. If it isn't recommended as a LSR, exactly what MPLS roles is it recommended for?

Re: [c-nsp] CISCO-AVAGO CISCO-FINISAR etc SFPs

Hello, 2017-10-31 15:49 GMT+01:00 Nick Cutting : > Well, a bunch of vendors now sell optics that do not require the secret > command on IOS to ignore the non cisco coding. > > I guess buy a few – the 10g SR’s are about $16 - > > However, we got burned in 2015 when a

Re: [c-nsp] General ME3600 software stability

Hello, 2017-10-20 15:06 GMT+02:00 Jason Lixfeld : > I need to be on at least 15.4(3)S1 to resolve all the bugs on my current list, > and while reviewing the ME3600 specific release notes for 15.4S and 15.5S > (http://tinyurl.com/yc9uudvz), it seems to me that generally

Re: [c-nsp] spanning-tree for local switching on ASR920

Hello Gert, 2017-10-18 15:39 GMT+02:00 Gert Doering : > IOS is asr920-universalk9_npe.03.18.03.S.156-2.S3-std.bin Well PVST+/RPVST+ is a fancy feature on this platform, and for fancy features you need fancy releases :) 16.6.1 in this case:

Re: [c-nsp] ASR 1k vs 9k as a non-transit BGP router with full tables?

> as a point of correction — iirc — asr1002x is running closer to an rp2. > i don’t have one available to me at the moment, but i believe the code > indicates as such.  comparing the ram, route, etc numbers leads me to > believe this is true. Agreed, the RP1 is a 32 bit platform and can only use

Re: [c-nsp] STM-1 over MPLS using ASR920

> This it ? The below. Looking for feedback from the field. TsoP Smart SFP [2]: ONS-SC-155-TSOP -> “TSoP Smart SFP” da inserire in uno slot SFP 1GE nel ASR920 TsoP in OC3 module [1], [2]: Modulo A900-IMA4OS + SFP OC3 ONS-SI-155-I1 -> qua occupiamo lo slot nel ASR920 VCoP Smart SFP [3]:

Re: [c-nsp] STM-1 over MPLS using ASR920

Hello Georg, > Has anyone ever tried to transport transparently STM-1 over MPLS using > ASR920? > Can you share your experiences and any issues you have possibly faced? > > Consider the following topology > > SDH #1 <=> ASR920 #1 <==MPLS==> ASR920 #2 <=> SDH #2 > > ASR920 supports the

Re: [c-nsp] PVLAN Edge on 4500 Sup8E

> There is a need to do vlan mapping and regular trunks on the customer > interfaces. > Was this in Sup8E, we know all other Sups can not do this. Initially Sup7, but then we switched to Sup8. I also had rewriting needs that I had to abandon because of the PVLANs. It clearly is not a metro

Re: [c-nsp] PVLAN Edge on 4500 Sup8E

> Does anyone have experience with PVLAN Edge / Switchport Protect on the > 4500 Sup8E? > > Documentation is sparse and there is confusion about the feature as the box > is meant to run private vlans. This will not be possible in this case. > > We are getting some resistance from a third party

Re: [c-nsp] Typhoon support on XRe

> Seriously?  I thought only Trident cards ended support in 5.3.X.  IOS XR 6.x *DOES* support Typhoon, just not in the 64-bit flavor. Lukas ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp

Re: [c-nsp] Typhoon support on XRe

Hello Christian, > does someone know for sure that XRe will never support Typhoon based > linecards? Yes (to my surprise), IOS XR 64bit does not support Typhoon linecards: https://supportforums.cisco.com/discussion/13204931/supported-hardware-ios-xr-612-release-note#comment-11822371 > So

Re: [c-nsp] ASR9000 A9K-2T20GE-B weird port issue

> I've just noticed this weird issue recently.  Whenever we have a port go > down for circuit related issues and recover I have to manually do a > shut/commit, no shut/commit to bring the interface up/up.  It is not > related to a specific type of optic because I am using different Cisco >

Re: [c-nsp] Troubleshooting ECMP/bundling issue (5-tuple black holing)

Thanks for all the hints, in the end I used a simple for loop with curl to find affected source ports (works especially well with rejected ports): for ((i=10001;i<=10020;i++)); do echo "Trying source-port $i"; curl -sSI "http://www.example.net:81/; --local-port $i -m 10 >/dev/null; done Trying

Re: [c-nsp] Troubleshooting ECMP/bundling issue (5-tuple black holing)

> Hey Lukas, > > Different platforms have different possibilities to examine the hashing, > what platforms are you using? Hah, that would be easy if this would be my network or my boxes. No, the issue is external, in other carriers networks, that is the difficult thing here. I'm looking at

[c-nsp] Troubleshooting ECMP/bundling issue (5-tuple black holing)

Hey guys, troubleshooting routing issues on paths external to our network that lead to blackholing of specific 5-tuple combinations here, very likely due to ECMP/Bundling issues (we are link is up/up and used for load-balancing, but cannot actually transmit or receive traffic, therefor

Re: [c-nsp] Cisco 6500/SUP720-3BXL - 7600-SIP-400 => VPDN for ppp connection ?

> Yes i have search without success ... i see information for 7600 but not > 6500 Just because SIP400 supports PPPoE/VPDN in a 7600 chassis doesn't mean you can do the exact same thing on a 6500. 7600 and 6500 software is very different, and while 7600 may address PE and some BNG needs, I don't

Re: [c-nsp] Stopping MLD responses & protecting CPU from MLD queries

> I've been testing workarounds based upon filtering the incoming MLD > query, on a 4500 (Cisco 4948E running 15.1(2)SG) and a 6500 (Cisco > 6500 w. SUP720-3B running 15.1(2)SY). Control Plane Policing is probably the way to address this (in case MLD cannot be properly disabled, I mean). >

Re: [c-nsp] ASR920 S vs SP train?

> For the record, 3.18SP fixes this vulnerability: > https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160804-wedge As does 03.16.04S and other rebuild in previous trains. ___ cisco-nsp mailing list

Re: [c-nsp] MPLS/VPLS gear with ext.temperatures

Hello Robert, > As equipment will work in unfriendly environment it have to support > extended operating temperatures (from -20*C up to 60*C) The ASR920 should be able to work in that conditions, check table 8 (Environmental Specifications) at [1]. There is basic IPsec support afaik, I'm not

[c-nsp] leap sec adjust. may crash linux based platforms

Hey folks, since I couldn't find any field notices about this [1] and I only discovered it from our partner [2], here some informations about the upcoming leap second adjustment: Some Linux based platforms (IOS-XE, NX-OS) may crash on December 31st 23:59:59 due to the upcoming leap second

Re: [c-nsp] SITE-2-SITE GRE Tunnel Problem with 7600 in Core Network

> We are having a strange issue after deploying 7604 Router in our Network. > When we connect our customer to 7604 Router theirGRE tunnel never got up. > But if we use 7200 router then it is working fine. Here is topology diagram: Make sure the core facing port is on the ES+ line card, not the

Re: [c-nsp] Wierd MPLS/VPLS issue

> Where the inner Destination MAC (i.e. after the two MPLS labels) starts with 4 > or 6, yes. > > The Nexus 92160 is being used as purely a L2 switch. It doesn't even support > MPLS... Then why for Christ's sake do they look at the Destination MAC two MPLS labels deep. The fix for this issue

Re: [c-nsp] Rec for full-table multi-peer bgp router?

> The QSFP shaped ports can take either QSFP28 (100G) or regular QSFP > (40G) transceivers. Also, it's "about 1.2M" ipv4 routes.  This is a deep > buffer broadcom jericho based box, so shows interesting potential, but > will not have the flexibility of NPU based architectures.  It will be >

Re: [c-nsp] Cat 6500/sup720 doesn't boot

> So I formated a CF in another 6500, copied the IOS > and tried to boot from disk0 without luck. >From the outputs you provided, you did not copy an IOS image to disk0, but a boot image. Boot image present or not, you will need an IOS image. > I tried erasing nvram and I even copied a boot

Re: [c-nsp] ASR920 vs NCS5000

> > The NCS500x is a dumb, dumb switch. > > > > Its a cheap and fast-tracked Trident II+ implementation in IOS-XR. > > Which sounds extremely tempting, TBH :-) - sane OS, fast hardware. I see your point, but just because its IOS-XR doesn't mean its 9k-like IOS-XR. You can choose (today)

Re: [c-nsp] ASR920 vs NCS5000

> Now with the NCS5000 I'am wondering now how it competes with the ASR920. It > has 1/10G and four 100G ports, thats some difference, but beyond that, > mainly feature-wise (IOX vs XE) what can I expect from both? The NCS500x is a dumb, dumb switch. Its a cheap and fast-tracked Trident II+

Re: [c-nsp] ISR4331 QoS

> It seems that the 4331 is not able to police or shape on sub-interface > level anymore. Its works fine on my 4431 (not 4331) box. I have a subinterface level shaper with child policies. Can you guys elaborate what doesn't work? Does IOS reject the configuration? Does it fail to match/queue

Re: [c-nsp] [c-nsp ]Router with legacy interfaces

> If you need something that is still currently supported by Cisco, the 3900 > ISR could also be an option. Currently supported yes, but the EOL announcement is already out:

Re: [c-nsp] 720-3BXL IOS 15

> Would be easy for cisco to implement some ram compression > technique in the sup720 code which would be nice but I suppose > it's not a priority. "Not a priority" is quite an understatement. This platform is nearly dead, ain't nobody gonna start implementing software workarounds to extend the

Re: [c-nsp] "safe harbor" - reliable statement about expected sw quality?

> I don't quite get what precisely Cisco is stating with those > little stars and the "safe harbor" label for IOS releases. Safe harbor means the release was tested in a number of scenarios and found to be stable. It is a certification basically. > Does the missing "star" imply I can expect

Re: [c-nsp] MPLS Suggestion on 7604 Router

Hello, > We are going to deploy 7604 router in our network (replacing 7200 G2). I would strongly suggest against a 7600 deployment. Its EOL/EOS and its extremely expensive if you buy from Cisco. The ASR9k series is what you should be looking at. With the small ASR9001 you can already get

Re: [c-nsp] Wierd MPLS/VPLS issue

> To me, everything *looks* right, it's just that some VPLS traffic traversing > the new link gets lost. > > Anyone got any suggestions on what I should look for whilst troubleshooting > this? Unfortunately, due to the impact to traffic, I have to make any changes > within a maintenance window,

Re: [c-nsp] DDOS Attacks Mitigation

> Really? > In order to use FlowSpec what should we need to do? > I believe in order to use flowspec your ISP should support that, is that > right? > How does it work to mitigate DDoS ? Sounds like your asking us to do your homework, how about you do some basic research on your own? I am sure

Re: [c-nsp] DDOS Attacks Mitigation

> We heard about BGP Flowspec but not confident how does it work and I think > ASR1006 doesn't support it. ASR1k supports Flowspec just fine. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp

Re: [c-nsp] ASR Firmware 15.5(3)S4a

> On a similar topic of the software download portal. Does it happen to you > that when you navigate those software download selections nothing happens > after you click on them? > I drives me mad sometimes as it comes and goes. Yes. It also happens that it redirects you to a page that only

Re: [c-nsp] Loop Prevention in VPLS

> I have issues in VPLS network where we get loop sometimes because of mac > flood from customer side and sometimes because of media loop in last mile. > Being a service provider what are the best practices which I could > implement on my PE Router or PE switch or in transmission equipment to >

Re: [c-nsp] DHCP Snooping on Cat3850

Hi, the IOS thread for DHCP snooping is hogging CPU, either it is swamped by incoming DHCP traffic (although this should be rate-limited, not causing 50% CPU load) or the thread got into a infinite loop because of a bug. Disabling/Enabling DHCP snooping may close the thread and restart it,

Re: [c-nsp] Forcing BGP to propagate only after route is in the FIB

Hi, > I've personally not seen this yet (in bothersome level) in any Cisco > gear, so this is very interesting observation, I sort of assumed what > every Cisco is doing, they're doing in manner that they are protected > from this problem. Thanks for the heads up! This definitely is a problem.

Re: [c-nsp] BGP full feeds on ASR1k

> That's pretty bad. I never had it that bad when I ran RP1's. > > Do you see any improvement if the session is in the global table? I don't know, I never tested that. But I'd imagine to see at least some improvements in the global table. ___

Re: [c-nsp] BGP full feeds on ASR1k

There are a lot of different ASR1k hw configurations out there, you will have to be more specific. Don't do it with RP1's though. I have the full-table in a VRF on RP1, not only is there a shortage of RAM that you cannot upgrade (because RP1 is 32bit), the box is also extremely slow to

Re: [c-nsp] L2PT over VPLS/VPWS between ME3600X and ASR920 (one for Warris?)

> We are settling on 03.16.03a, however the 2nd DC is still in build so > I haven't bumped this up yet. Concentrating on getting the config > working for now. If it doesn't work because of IOS bugs in 03.16.01a, you will spend a hell-of-a lot of time with "getting the config working for now".

Re: [c-nsp] L2PT over VPLS/VPWS between ME3600X and ASR920 (one for Warris?)

Hi James, > ASR920 is 03.16.01a.S Don't use this image, it will bite you. Upgrade to 03.16.02a or even better: 03.16.03a. Really do this *before* losing any more time on this. Which transport do you want, VPLS or VPWS? Doesn't make sense to troubleshoot both. Also, exactly which l2protocol

Re: [c-nsp] ME3400G EVC / bridge-domain config

> Just found out the hard way indeed. I can create an EVC on > the 3400g, I can put an interface into the EVC but cannot > associate any bridge domain with it. Forget EVC on the 3400 series. Its not real EVC functionality, but some subset of it for OAM/CFM/E-LMI use. > I’m guessing I need a

Re: [c-nsp] ME3400G EVC / bridge-domain config

Hi Rutger, > I have a Q-in-Q tunnel with a few different S-VLANs that I want > to terminate into a bridge-domain, effectively doing EVPN/VPLS > in a single ME box and hiding all customer specific VLAN > information while still bridging. I would like to do > something like: > > interface gi3/1 >

Re: [c-nsp] Cisco working as PPPoE Server

> I recommended the ASR9001 because it has 10G ports built in. The only thing with the 9k series is that it doesn't support LNS configurations, you can only do LAC or direct termination with it. LNS functionality aside, the 9k is a good choice as a BNG I guess. Regards, Lukas

Re: [c-nsp] CSCuy29638 - MPLS (for IPv4) Brokenness Fixed - ASR920

> Not all packets cause the wedge. If your CoPP allows NTP from your > configured NTP servers, but not from others, you're fine. Unless the IP address of your NTP servers are known to an attacker, in that case the packet can simply be spoofed. Lukas

Re: [c-nsp] CSCuy29638 - MPLS (for IPv4) Brokenness Fixed - ASR920

Hi, the hang you see could be related to the NTP bug (affecting only 03.16.03): http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160804-wedge https://bst.cloudapps.cisco.com/bugsearch/bug/CSCva35619 Lukas ___ cisco-nsp

Re: [c-nsp] route processor redundancy basics (RPR)

> RPR: standby RP is partially initialised. That is, only the startup-config > of the active router and standby router are sync'ed. Correct. > I lost about 1 or 2 minutes of pings during this stage, then RP1 stabilised > and the pings started going through. > > Is this expected behaviour?

Re: [c-nsp] CSCuy29638 - MPLS (for IPv4) Brokenness Fixed - ASR920

Hi Eric, Mark, any new informations about the 03.16.03a hangs? Could you share SR number or bugid, if filed? Anyone else saw those hangs in 03.16.03a? About to deploy some 24SZ here and I need to decide between 02a and 03a. Thanks guys, Lukas

Re: [c-nsp] Weird throughput issue

> UDP tests to the site are ok as we can force 85-90M and the > site receives it with very little packet loss.  Packet loss none the less. If you stay (well) below the CIR you are not supposed to see any packet loss. Also, check for jitter and OOO packets. All those things matter, and will make

Re: [c-nsp] Cisco ASR 9k transporting QinQ traffic

Hi, > wonder if the 4948 is using 8100 for both the outer and inner tags, in > which case using dot1ad wouldn't match. By default Cisco tags with 8100 for both outer and inner tag. Don't expected 1ad unless explicitly requested/configured on the Catalayst. > Is "rewrite ingress tag pop

Re: [c-nsp] ASR 9000 Series MPLS Label Limits

Hi James, there are only 1M labels, because its a 20-bit value. This is a protocol limitation, you cannot go further with MPLS. Means you cannot and should not assign a label per global ipv4 prefix, because you are going to run out of labels eventually. Use per-vrf or per-ce label instead.

Re: [c-nsp] SUP720's memory, looking at options..

> Is there any place where they list how many routes the ASR9K will handle, > granted most of the current goodness is too rich for my blood, but stuff > like the RSP4G and RSP8G are pretty easy to come by.   I thought I saw > something saying they were limited to say 512K routes, but I may be

Re: [c-nsp] asr 920 - lower mpls mtu?

Hi Mike, > Trying to set up an EoMPLS tunnel, the mtu allowed for > 'l2 vfi somename manual' is a bit short.. only 9180 bytes as > opposed to 9216 for all the rest of my me3600's for example. > > asr920(config-vfi)#mtu ? >    <1500-9180>  MTU size in bytes >   > > > I am trying to figure out

Re: [c-nsp] ASR1006 IOS version question

> On cisco support i am seeing two ISO version which one should i use on > production? > > Suggested: >   - 3.16.3S(ED) >   - 3.13.5aS(MD) 03.16.3S, because its supported for a longer time. > Latest: >   - 3.17.2S(ED) > > Should i use Lates one 3.17.2S(ED) or i should use suggested what is

Re: [c-nsp] netflow real AS instead of uplink provider?

> 4.3.1 is quite crusty.  If you need to stay in 4.3.x perhaps 4.3.4.  I would > avoid 5.3.3. About to deploy 5.3.3 (+ SMUs) here. Can you elaborate the problems in 5.3.3? Thanks, Lukas ___ cisco-nsp mailing list cisco-nsp@puck.nether.net

Re: [c-nsp] A9K Netflow export drops

Hi Chris, > Hi Robert, > > we've finally received clarification from TAC: > In our case this was a bug within IOS-XR 5.3.X. > For us, this is fixed in 6.0.1 which we wanted to upgrade to anyway due to > extended netconf support. Do you have a bug id for this one? Thanks, Lukas

Re: [c-nsp] MPLS Routing with PBR

> So I'm confused a bit then. Once the label pops it sees a next hop > in that VRF aware router and will get imported into that VRF no? No. There are no VRF imports, no IP based actions on an LSR, even when you call the box a PE. The intermediate nodes just swaps one transport label with

Re: [c-nsp] MPLS Routing with PBR

> If the packet ends up traversing PE routers that are VRF aware of the > customer on it's way to that final PE router will the in between PE routers > pop the labels and subject the packet to normal VPNV4 routing table instead > of just label switching entirely to the final PE router? No,

  1   2   3   4   >