Re: [c-nsp] ospf database size - affects that underlying transport mtu might have

Hi, On Fri, Dec 01, 2017 at 12:09:11PM -0600, Clint Wade wrote: > Potential for dropping a large routing update as well causing inconsistent > route tables and missing routes. ... and dropping customer payload... gert -- now what should I write here... Gert Doering - Munich, Germany

Re: [c-nsp] Nexus 7700

We've had 8.1.1 running now for ~9 months without issue. On Mon, Nov 27, 2017 at 1:50 PM, Scott Voll wrote: > What are others running on their 77xx's? > > 6.2.16 is the starred release but is over a year and a half old. and there > is an .18 version too (but not starred).

Re: [c-nsp] ospf database size - affects that underlying transport mtu might have

Potential for dropping a large routing update as well causing inconsistent route tables and missing routes. On Fri, Dec 1, 2017 at 10:21 AM, Gert Doering wrote: > Hi, > > On Fri, Nov 24, 2017 at 01:34:23PM -0600, Aaron Gould wrote: > > Cisco tac didn't want to do ignore-mtu

Re: [c-nsp] 3850 / 3650 storm control

On 22.11.17, 17:15, "cisco-nsp on behalf of Scott Voll" wrote: So I'm green field with 3850 at the distribution layer and 3650 at the access layer. Since I don't have anything to start with, what would be save

Re: [c-nsp] ASR9000 HW compatibility

On 24 November 2017 at 10:38, Dmitry Kiselev wrote: > Hi! > > > Seems you are right: all A9K-8X100GE, A9K-4X100GE and A9K-48x10GE have very > similar power consumption (t=40C), so most likely they all have equal chassis > requirements. I think there will be no issues with

Re: [c-nsp] ospf database size - affects that underlying transport mtu might have

Hi, On Fri, Nov 24, 2017 at 01:34:23PM -0600, Aaron Gould wrote: > Cisco tac didn't want to do ignore-mtu And right they are. "Have OSPF come up, and then drop payload data frames because the lower layer cannot transport full size packets" is about the worst you can do to your customer data

Re: [c-nsp] multiple GRE on the same gear

I'm am 99 percent certain this does not happen on anything but the 6500, it is something to do with the hardware forwarding not able to handle an extra field to index something. One of Ivan Pepelnjak's webinars talked more about it (the 6500 having the issue) - and he mentioned ISR / ASR did

[c-nsp] FIB insertion issues on Sup2T routers

Hello, I had 3 incidents within a week in which Sup2T-XL routers switched to software forwarding. I.e. log says: %MLSCEF-4-FIB_TCAM_INSERT_FAIL: FIB entry insertion into tcam failed, one IPv4 route may be absent from hardware table Was fixed by a reboot in each case. Uptime differs (several

Re: [c-nsp] 3850 / 3650 storm control

Hi Scott, On Wed, Nov 22, 2017 at 08:13:45AM -0800, Scott Voll wrote: > > Since I don't have anything to start with, what would be save storm control > limits to start with on each platform for Broadcast, multicast,and > Unicast? > After some observations of common broadcast levels we limit

[c-nsp] multiple GRE on the same gear

Dear experts, the bug CSCdy72539 states that on Cisco 6500 with SUP720 if are created multiple GRE interfaces using the same source address traffic is switched in CPU instead of hardware, it seems the issue is solved with SUP2T. The question: can ASR1001X suffer of the same issue ? I’m not able to

[c-nsp] Nexus 7700

What are others running on their 77xx's? 6.2.16 is the starred release but is over a year and a half old. and there is an .18 version too (but not starred). 8.2.1 is very new. cisco is shipping with 8.1.1. if you were going in green, what version would you recommend? TIA Scott

Re: [c-nsp] BGP not advertising supernet to RR's

Its strange, you can try some other methods of creating the summary - maybe via "aggregate" way. Also instead of redist static you can also try "network" command. -pavel Dňa 3. 10. 2017 9:20 AM používateľ napísal: > Just stab in a dark, > Aren't you learning

Re: [c-nsp] ospf database size - affects that underlying transport mtu might have

Cisco tac didn't want to do ignore-mtu because I think they said there was something else further in the neighborship process that must have a sufficient transport mtu to make work... so we had to shrink the end point mtu's where the neighbors were located (my cisco asr901 at the cell tower

Re: [c-nsp] ASR9000 HW compatibility

Hi! Seems you are right: all A9K-8X100GE, A9K-4X100GE and A9K-48x10GE have very similar power consumption (t=40C), so most likely they all have equal chassis requirements. I think there will be no issues with power modules and chassis itself. Thanks! A9K-4X100GE 1050W 4xTomahawks

[c-nsp] ASR900 & IOS-XE Everest

Is anyone using IOS-XE Everest on ASR90X/ASR920 in production yet or have tested in the lab and have thoughts they could share? Feature sets of interest to me are RSVP-TE/FRR/L2VPN/BGP-VPLS Appreciate any comments re caveats to look out for etc and particular releases that are working better

Re: [c-nsp] ospf database size - affects that underlying transport mtu might have

--- Begin Message --- Hi, Yes. If neighbor adjacency gets hosed at Exchange-Start, MTU is more than likely; the culprit. Ip ospf mtu-ignore can be used to confirm. IMO, bad to have this in place in a production-env; special-cases notwithstanding. ./Randy From:

Re: [c-nsp] ASR9000 HW compatibility

Hi. The 48x10GE is a Tomahawk based linecard using A9K-NP300-LC and thus needs V2 fan trays. These linecards also require both fantrays to be UP to boot. I had this issue when trying to install a 4x100GE LC, even though the hardware installation guide only mentions this for the 8x100GE card.

Re: [c-nsp] Redistributed connected / static prefixes to upstream and set as-path prepend

Apologies - I did resolve this, but neglected to post to listsoft bgp reset, I saw no as prepends on carriers looking glass, same with hard reset (Hence I thought it was caused by origin (grasping at straws  )) - I ended up shutting down the peering session, then activating it, and the AS

[c-nsp] multiple GRE on the same gear

Dear experts, the bug CSCdy72539 states that on Cisco 6500 with SUP720 if are created multiple GRE interfaces using the same source address traffic is switched in CPU instead of hardware, it seems the issue is solved with SUP2T. The question: can ASR1001X suffer of the same issue ? I’m not able to