Re: [c-nsp] Where have all the skilled people gone?

[Łukasz Bromirski via cisco-nsp]

Hi Hank,

That indeed looks bad - can you share OS and version? I'll take it to devs.

— 
Łukasz Bromirski

> On 16 Feb 2023, at 07:40, Hank Nussbacher via cisco-nsp 
>  wrote:
> 
> 
>> 
>>  These days a lot of experience is getting lost, and the industry hasn’t 
>> found a way to transfer that knowledge to new generations.
>> 
>> Cheers,
>> Sander
> 
> It makes me sadder that people in Cisco don't know how to spell "iput", 
> "recieved" or "byetes" and there is no QA using spellcheck:
> 
> 
> rtr#sh int te0/1/1 accounting
> TenGigabitEthernet0/1/1   10G link
>  INPKTS input pkts OUTPKTS: output pkts
>  RXBYTES: iput bytes recieved  TXBYTES: output byetes transmitted
>  RXBS: rx rate (bits/sec)  RXPS: rx rate (pkts/sec)
>  TXBS: tx rate (bits/sec)  TXPS: tx rate (pkts/sec)
> 
>  ...
> 
> 
> If they can't get simple English words spelled corrected, you can imagine 
> what the code looks like :-(
> 
> 
> Regards,
> 
> Hank
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] policer on ASR1001X

[Łukasz Bromirski]

Mark,

I’m from a different BU, but overall - yes, I remember some of the discussions 
we’ve had in the past. I’m very sorry it turned out this way.

Unfortunately, some of the decisions are not made on single-platform level, and 
I do get you’re frustrated because either there’s no one to talk to, answers 
are not satisfactory or there’s simply black hole - no answers.

Just for everyone to know - SP team changed the way they process feature 
requests from Customers and Account Teams. Tools by themselves won’t solve any 
problem, but right now it should be much easier to track all of the requests 
received across the board. If you, like Mike, are frustrated with the 
suggestions or requests falling to „deaf ears”, please try once again. 

And hey - solid competition is what can move us all forward :)

-- 
./

> On 10 Sep 2021, at 18:16, Mark Tinka  wrote:
> 
> 
> 
>> On 9/10/21 17:50, Lukasz Bromirski wrote:
>> 
>> IOS-XE is here to stay :) Indeed, there’s “dumbed down” version of it for 
>> SD-WAN, and they’re being slowly unified with normal IOS-XE being adopted to 
>> work in “centralized” (vs “autonomous”) mode. That’s not “autonomous” like 
>> with the Autonomic Networking feature from some years back, it’s “normal” 
>> IOS-XE.
>> 
>> From hardware perspective, yes, UADP (Catalyst/switches) and QFP 
>> (Catalyst/ASR/routers) can handle a lot of fancy QoS duties, and doing 
>> pps/bps at the same time would be just enhancement. PPS limit for normal 
>> traffic seems to be less popular as Customers usually care more about 
>> bandwidth/throughput than PPS, while PPS is *very* important and more 
>> applicable for Control-Plane protection duties, as all processing is 
>> PPS-bound obviously.
>> 
>> @James - please reach out to your account team to request such feature.
> 
> Thanks, Lukasz.
> 
> But with respect, this is one of the reasons I am changing all our gear over 
> to Juniper. The messaging from Cisco depends on who you speak to, and when. 
> Last year with our AM team was horrible, trying to get features into the 
> ASR920, and being told that the NCS540 is where all focus is going; so, sorry!
> 
> This may or may not have been true last year. This may or may not be true 
> this year. But I can't build a business on this uncertainty.
> 
> I'm not moaning at you, just to be clear :-).
> 
> Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] RSP720 fabric channel speed

[Łukasz Bromirski]

That's normal, older Sup switching matrixes were not running
in active/active mode.

So, the standby Sup is doing exactly that - standing by to take
over.

— 
Łukasz Bromirski

> On 8 May 2021, at 08:37, Eugene Grosbein  wrote:
> 
> Hi!
> 
> This is for Cisco 7606 with two RSP720-3CXL-GE working as AS border router 
> with BGP full views:
> 
> #show fabric status
> slot  channel speed module   fabric  hotsync  Standby  Standby
> status   status  support  module   fabric
>20   20G OK   OK N/A
>30   20G OK   OK N/A
>31   20G OK   OK N/A
>40   20G OK   OK N/A
>41   20G OK   OK N/A
>508G OK   OK N/A
>60   20G OK   OK N/A
> 
> I wonder why module 5 can possibly have 8G speed instead of 20G?
> System image file is 
> "sup-bootdisk:c7600rsp72043-adventerprisek9-mz.153-3.S2.bin"
> 
> #show module
> Mod Ports Card Type  Model  Serial No.
> --- - -- -- 
> ---
>  2   24  CEF720 24 port 1000mb SFP  WS-X6724-SFP   SAD095100KW
>  34  CEF720 4 port 10-Gigabit Ethernet  WS-X6704-10GE  SAL11413Y50
>  44  CEF720 4 port 10-Gigabit Ethernet  WS-X6704-10GE  SAL1206FSRB
>  52  Route Switch Processor 720 (Hot)   RSP720-3CXL-GE SAL1631JGQP
>  62  Route Switch Processor 720 (Active)RSP720-3CXL-GE JAE11484O8V
> 
> Mod MAC addresses   Hw   FwSw   Status
> --- -- - -  
> ---
>  2  0015.f91d.3aa4 to 0015.f91d.3abb  2.3   12.2(14r)S15.3(3)S Ok
>  3  001b.d4f7.22fc to 001b.d4f7.22ff  2.6   12.2(14r)S15.3(3)S Ok
>  4  001e.4a79.3ee8 to 001e.4a79.3eeb  2.6   12.2(14r)S15.3(3)S Ok
>  5  2894.0fd1.3950 to 2894.0fd1.3953  5.13  12.2(33r)SR   15.3(3)S Ok
>  6  001b.d401.6654 to 001b.d401.6657  5.2   12.2(33r)SRB  15.3(3)S Ok
> 
> Mod  Sub-Module  Model  Serial   Hw Status
>  --- -- --- --- 
> ---
>  2  Centralized Forwarding Card WS-F6700-CFC   SAL10019C56  2.0Ok
>  3  Centralized Forwarding Card WS-F6700-CFC   SAL11413Y1P  4.0Ok
>  4  Centralized Forwarding Card WS-F6700-CFC   SAL1207GEZT  4.0Ok
>  5  Policy Feature Card 3   7600-PFC3CXL   SAL1631JD1G  1.1Ok
>  5  C7600 MSFC4 Daughterboard   7600-MSFC4 SAL1631J9ST  5.0Ok
>  6  Policy Feature Card 3   7600-PFC3CXL   JAE114749TM  1.0Ok
>  6  C7600 MSFC4 Daughterboard   7600-MSFC4 JAE11474ID5  1.1Ok
> 
> Mod  Online Diag Status
>  ---
>  2  Pass
>  3  Pass
>  4  Pass
>  5  Pass
>  6  Pass
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Delay in delivery of new routers

[Łukasz Bromirski]

There are three forces working here, for clarity.

First is fiscal year. For us (Cisco) it's from August of
year X to July of year X+1. As you can expect, by end
of fiscal year we have a lot of orders coming in, as sales
wants to make the quota. This influences lead times, as
despite being big vendor we also have limits to what we
can produce in given time.

The other is calendar year. Some customers (public
entities in particular) tend to have budget given for
calendar year, and by end of year they usually again
are pushing a lot of smaller and bigger orders, and this
again can influence lead times.

Depending on your ordering type (direct or via 
distributor) this can also change for numerous reasons
(stock availability, promotions, etc).

Last but not least - is COVID. COVID impacted whole
supply chain, and despite the fact we fared way better
than our competitors, it's still a problem. Sometimes in
very unexpected places.

I'm sorry for the experience, but work with your account
team. They heave means to try to expedite shipment if
that's for specific project/deadlines.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

___
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] IR1101 multicast

[Łukasz Bromirski]

Have you verified if you had CoPP enabled by any chance?

-- 
./

> On 16 Nov 2020, at 00:44, Mal via cisco-nsp  wrote:
> 
> 
> From: Mal 
> Subject: IR1101 multicast
> Date: 16 November 2020 at 00:44:19 CET
> To: "cisco-nsp@puck.nether.net" 
> 
> 
> Wondering if anyone is experiencing slow multicast throughput, at L3, with 
> the IR1101 router.
> 
> I have a box running the latest 16.12.04 and receive 1-2Mbit  only multicast, 
> for a 6M HD stream.
> 
> Mal
> 
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP in the lab - v4 & v6 live feeds from Europe

[Łukasz Bromirski]

Cisco NSPers,

If you’re looking for live, full BGP v4 & v6 feed for your lab or
a bit of testing before going live, I just shared a short post on
how to get it:

https://lukasz.bromirski.net/post/bgp-w-labie-3/

Happy BGPing,
-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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?

[Łukasz Bromirski]

Hi,

> On 18 Sep 2020, at 11:50, Rolf Hanßen  wrote:
> 
> Hi,
> 
> at least for Sup720-3B(XL) and Sup-2T it results in number 1 for the
> family that hit the limit.
> 
> So in most cases it will look that way:
> #show mls cef exception status
> Current IPv4 FIB exception state = TRUE
> Current IPv6 FIB exception state = FALSE
> Current MPLS FIB exception state = FALSE
> 
> And yes, the box will drop down to a few MBit of Traffic.

Performance will depend on where the traffic is going. If it’s
going to unaffected prefixes, it will be still hardware forwarded.

For traffic going to prefixes that failed to be installed in HW,
resulting performance will be similar to what you can get on those
pretty small, non-x86 CPUs. 

There’s no easy way to clean up HW after failure to program it and
then somehow “split” prefixes between hardware only and software
only. With Sup2T and newer we have an option to check if ACL/QoS
and other policies will fit before even trying to program them
(so called ‘atomic’ commit), but that’s not the case for FIB.
The only way going forward is to reload the box after making sure
it won’t get into the same time after re-establishing routing
protocol adjacencies and getting prefixes again.

Set up 'maximum-prefixes' on your eBGP sessions to sensible value
depending on PFC/DFC models and you should be fine. Also, there’s
whole guide how to adjust MLS CEF scale numbers on 6500/7600:
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

___
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 requests

[Łukasz Bromirski]

Gert,

> On 19 Aug 2020, at 18:29, Gert Doering  wrote:
> 
> Hi,
> 
> On Wed, Aug 19, 2020 at 06:23:36PM +0200, ??ukasz Bromirski wrote:
>> Working with TAC would be probably best option going forward.
> 
> I find your optimism amazing.

Maybe that’s because I work for Cisco? :)

> (My TAC case about "ASR920 do not always honour IPv4 ACLs on SVIs"
> is not getting anywhere since December.  We managed to reproduce the
> issue in the TAC lab around April...)

I’ll follow up with you offline on that, while that’s not exact name of the 
case, I found it ;)

> It might give some sort of satisfaction if a TAC case eventually comes
> to a conclusion different from "works as designed" or "the effect is
> gone after reboot" or "have you tried upgrading to the latest version?"
> (and then "gone after reboot") but for ongoing operational problems,
> we have been less than underwhelmed with TAC performance.

Unfortunately, everything comes down to proper escalation. While Cisco TAC is 
still biggest technical support organization, unmatched by other networking 
vendors, people are working on a number of cases. Priorities/Severities matter.

P1 - my network is down
P2 - my network functioning is severly degraded
P3 - I have a problem which is interesting
P4 - I have a question

I’d keep such request at least at P2 at all times. Even if TAC is waiting to 
schedule internal lab recreation or cooperation with platform developers to 
verify behavior.

Anyway, yeah - I’m actually pessimist and cynic, but enough about me ;)

-- 
Łukasz Bromirski / https://lukasz.bromirski.net
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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 requests

[Łukasz Bromirski]

Eugene,

Did the interface had IP address assigned in the past to main interface and 
then changed to subinterface ones? I remember couple of nasty 7200-impacting 
bugs in 15.x train (so called “CEF rewrite” or “not 13.x”) that had stale IDB 
entries wrongly mapped to CEF structures and that could potentially result in 
similar behavior.

Also, can you identify if those ARP requests are valid, belonging to 
subinterface link space, or totally bogus? And if they happen both on the main 
interface and subinterface, or only on main interface?

Working with TAC would be probably best option going forward.

— 
./

> On 19 Aug 2020, at 17:03, Eugene Grosbein  wrote:
> 
> 19.08.2020 21:44, Gert Doering wrote:
>> Moin,
>> 
>> On Wed, Aug 19, 2020 at 09:40:43PM +0700, Eugene Grosbein wrote:
>>> Gi3/9 of the switch is actually the port connected to router's Gi0/1.
>>> So, the question remains same.
>> 
>> Check the routes on the router.  If you have something which is pointing
>> directly to an interface ("ip route 0.0.0.0 0.0.0.0 gi0/1") it will
>> generate proxy-ARP requests for all destinations covered by that route.
>> 
>> Always use interface + gateway-IP unless this is a desired property.
> 
> I have not such routes: the command "show ip route | include 0/1$" shows 
> nothing.
> The interface Gi0/1 does not have any IP configuration itself, only its 
> sub-interfaces have.
> 
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net 
> 
> https://puck.nether.net/mailman/listinfo/cisco-nsp 
> 
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 
> 
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco N540-ACC-SYS ipv4 routes

[Łukasz Bromirski]

Mark,

> On 15 Jul 2020, at 15:45, Mark Tinka  wrote:
> 
> On 15/Jul/20 15:08, Łukasz Bromirski wrote:
> 
>> That’s right. That’s also why I didn’t want to claim Juniper was stupid
>> with the product, more into direction that such naive approach simply 
>> didn’t work out.
> Well, we are dumping our CRS-X boxes and the PTX1000 is high up on the
> list of shoo-ins.

That’s interesting. How about Cisco 8000 (feature-rich services) or
NCS 55xx (cheap 10/40/100/200G ifaces)?

> There will come a time when new operators cannot buy IPv4 on an open or
> black market, so we all need to keep cracking on bringing IPv6 up to
> scratch.

I’m trying to preach IPv6 for two decades right now. I can last for one
or two decades more maximum so you guys *need* to deploy IPv6 in 
production environments even if a) it’s still broken and b) it is
missing some parts.

— 
./
___
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 N540-ACC-SYS ipv4 routes

[Łukasz Bromirski]

Mark,

> On 14 Jul 2020, at 06:52, Mark Tinka  wrote:
> 
> On 14/Jul/20 04:28, Phil Bedard wrote:
>> The PTX 5000 was the original PTX.  The 1st/2nd generation FPCs didn't have 
>> much FIB capacity, like 128k routes which was well below an Internet table 
>> in 2014.  The 3rd gen is where they started supporting up to 1M+ v4 prefixes.
> 
> Yes, this is what I remember also. But if you look at the PTX1000, you
> don't have that problem from when it went into inception.
> 
> Granted, one could say Juniper made the assumption that most MPLS-based
> networks would run a BGP-free core, and in theory, there were right.

That’s right. That’s also why I didn’t want to claim Juniper was stupid
with the product, more into direction that such naive approach simply 
didn’t work out.

> What they didn't account was that 6PE was one of those "temporary
> becomes permanent" situations.

OTOH, that’s still the vision we’re trying to catch up with, right? Have one,
simple and easy to provision/monitor/troubleshoot/traffic engineer/decomission
protocol, that carries all address families, has unified architecture and
universal interoperability “because of that”.

So, about OpenFlow… ;)

— 
./
___
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 N540-ACC-SYS ipv4 routes

[Łukasz Bromirski]

Mark,

> On 13 Jul 2020, at 15:55, Mark Tinka  wrote:
> 
> On 13/Jul/20 12:27, Łukasz Bromirski wrote:
>> You also can’t bet on oversimplifying things, as Juniper with PTX (for 
>> example) found out.
> Can you expand on this a little more?

PTX was created as platform that will do only MPLS-based forwarding, with tiny 
IP routing table scale.
The idea was marketed as something that will get Juniper leading edge across 
SPs and win back accounts.

— 
./
___
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 N540-ACC-SYS ipv4 routes

[Łukasz Bromirski]

Mark,

> On 13 Jul 2020, at 09:55, Mark Tinka  wrote:
> 
> On 13/Jul/20 09:20, Saku Ytti wrote:
> 
>> But if that is a strict definition, then we don't really have ASICs
>> outside really cheap switches, as there is some programmability in all
>> new stuff being released. So I'm not sure what the correct definition
>> is.
> 
> I've been thinking about this over the past 4 years, actually, and I
> came to the conclusion that it was mostly championed by the 6500/7600
> ASIC's, and Juniper's earlier Internet Processor I and Internet
> Processor II ASIC's.
> 
> Since that time, we've asked routers to do more things beyond simple IP
> packet forwarding, which has required those chips to evolve more into
> NPU's than ASIC's. I'd say from around the ASR1000, MX and later, is
> when we saw this shift.
> 
> […]

> Ultimately, I'm not sure it matters that much nowadays, but I wouldn't
> mind having the discussion :-).

I’d risk stating the obvious - technology is moving in one great sinusoidal 
shape. We tend to deaggregate, and then to aggregate, just to deaggregate 
again. The only thing that really changes is speed of those cycles.

Current trend is to simplify (Segment Routing) so there’s chance hardware of 
tomorrow can be less complex and do much less with faster speeds. But at some 
point there will be new protocols, applications, overlays and whatever, so 
there will be need to do more than just basics. You also can’t bet on 
oversimplifying things, as Juniper with PTX (for example) found out.

Do we have ASICs? Yes, they *still* usually drive fabrics, all else is 
essentially NPU - because it can be reprogrammed on the fly. As Saku pointed 
out, there’s less and less difference between modern x86 architectures and 
networking NPUs however and given how much different things can be easily done 
in software, this trend will continue to drive “cloud” applications. This 
should also help “simplifcation” trend, as there will be less and less 
dependency on the fancy “hardware” capabilities of a box.

Next wave will (are) probably photonics, moving further and further into direct 
feature capabilities without influencing speed-down to tackle specific feature 
in silicon. That will be true test to “how many features you *really* need” and 
great area to optimize further. Question is - how fast we’ll get there 
realistically with shipping products and how much it will level field vendors 
are playing on with Customers.

— 
./
___
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 N540-ACC-SYS ipv4 routes

[Łukasz Bromirski]

Vikas,

> On 9 Jul 2020, at 03:34, Vikas Sharma  wrote:
> 
> Dear Luka,
> 
> Thanks for your revert. I have checked all ciscolive presentation before I 
> have shooted question to the forum. I understand, LPM and LEM along with 
> iTCAM support on C 540 does not exceed 400k but I was not getting details on 
> rib/fib on ASR 1002-HX, in case you have found, please share with me.

The numbers quoted in the URL are actually FIB size (3.5M for IPv4, 3M for IPv6 
or mix of both).

RIB can scale to 11M routes.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

___
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 N540-ACC-SYS ipv4 routes

[Łukasz Bromirski]

Jason,

> On 9 Jul 2020, at 03:26, Jason Lixfeld  wrote:
> 
>> On Jul 8, 2020, at 9:14 PM, Łukasz Bromirski > <mailto:luk...@bromirski.net>> wrote:
>> 
>> Vikas,
>> 
>> First of all, NCS 540 ACC-SYS has 16GB of RAM.
> 
> … but only 8GB available to the RP.
> 
> RP/0/RP0/CPU0:ncs540-7.lab#show memory summary
> Wed Jul  8 21:19:33.842 EDT

Indeed, that may be the case. Thanks for correcting me. Memory allocated to RP 
may change in future.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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 N540-ACC-SYS ipv4 routes

[Łukasz Bromirski]

Vikas,

First of all, NCS 540 ACC-SYS has 16GB of RAM.

For NCS 540, slide 43:
https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKSPG-2159.pdf 


Essentially, around 380k depending on prefix distribution.

For ASR 1002-HX it’s here:
https://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/datasheet-c78-731640.html#PerformanceandScaling
 


Please use your favorite search engine first in future.

— 
./

> On 9 Jul 2020, at 02:48, Vikas Sharma  wrote:
> 
> Many thanks Jason for your quick response.
> 
> If possible please also confirm the rib/fib limits of ASR1002-HX.
> 
> I have two choices to be used as IGW, ASR1002-HX or C 540 X and I want to
> choose the best of the two options.
> 
> Regards,
> Vikas
> 
> On Thu, 9 Jul, 2020, 12:52 am Jason Lixfeld,  wrote:
> 
>> Hi,
>> 
>> I don’t know the exact RIB scale, if there is one, short of what available
>> memory will hold.  That said, it’s got 8GB of memory, and I’ve seen 1.7M+
>> BGP prefixes with the BGP process consuming about 1.9GB of memory.
>> 
>> It won’t hold a full table in FIB. 350K max, protocol independent,
>> depending on the prefix size.
>> 
>> SRD is implemented using table-policy.
>> 
>>> On Jul 8, 2020, at 3:02 PM, Vikas Sharma  wrote:
>>> 
>>> Dear,
>>> 
>>> Can someone please confirm how many routes are supported in above model
>> in
>>> both rib and fib?
>>> 
>>> Also, I am not able to find table-map command for this router.
>>> 
>>> Any suggestions?
>>> 
>>> Regards,
>>> 
>>>Vikas
>>> ___
>>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> 
>> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco 4000 series (4461) as a BGP router?

[Łukasz Bromirski]

Patrick,

> On 28 Oct 2019, at 09:30, Patrick M. Hausen  wrote:
> 
> Hi all,
> 
>> Am 27.10.2019 um 01:36 schrieb Łukasz Bromirski :
>> 
>>> On 23 Oct 2019, at 13:50, Patrick M. Hausen  wrote:
>>> 
>>> Hi all,
>>> 
>>> would you recommend the 4461 to run a handful of
>>> full feeds for v4 and v6? The model seems to be quite
>>> affordable compared to ASR 9000 series routers and
>>> throughput is not our main concern for upstream.
>> 
>> It will do fine. Memory and performance shouldn’t be an issue until you
>> reach around 7Gbps (with BOOST license, if you’re not running virtual
>> containers).
>> 
>> If that’s not enough, consider ASR 1001X/1001HX.
> 
> Our supplier recommended refurbished 9001 or 9006 to get the best
> bang for the buck. Would you agree with that?

It will depend on your requirements. 9001 is small, deep, but powerful,
capable of pushing 120Gbps. ISR 4461 and ASR 1001X/1001HX
can’t match that (1001HX is 60Gbps) and for example can do
VPN crypto which 9001/9901 can’t (if you’re willing at some point in
future to terminate S2S/RA VPNs).

> Could someone kindly clue me in about the 32bit vs 64bit platform
> „issue“ if there is one? I would not want to invest into a platform
> with EOL already on the horizon. Those 6500 have been running way
> too long.

As I already responded to James, 9001 is not going EOL anytime
soon - at least not until June 2020. 32 bit is still an valid option and
will be for years to come - we have hundreds of thousands of systems
deployed with it.

*If* however you want to go for full-scale/future-proof design, either
go with ASR 1k or ASR 9901 (both of which run 64b code, IOS-XE and
IOS XR now).

And refurbished is only good if you don’t need official service & support.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

___
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 4000 series (4461) as a BGP router?

[Łukasz Bromirski]

James,

> On 28 Oct 2019, at 13:35, James Jun  wrote:
> 
> If this is a new deployment, don't bother with 9001, or 9006 with 32-bit kit 
> components.
> 
> Both of these are going EOL.

There are no such plans for now, and until at least July of 2020.
And yes, I’m with Cisco, this is official.

And please remember EOL is last stage - first, there’s EoS, and you
still can for a year buy the equipment. There’s couple of years (3 to 5)
of support.

In this specific setup, 32-bit OS won’t hurt, as BGP on 9001 and
9006’s RSP is perfectly capable of driving ~2M+ FIB and ~20M RIB
entries (if used with multiple BGP instances, 7M+ for single instance).

> If you need new entry level ASR9K at similar price points as 9001, talk to 
> your account
> team about ASR-9901-120G.  It's 64-bit and licensed to same capacity as fully 
> loaded
> 9001 (120 Gbps).

That’s true of course. 9901 would be better entry-level choice with
years in front of it.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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 4000 series (4461) as a BGP router?

[Łukasz Bromirski]

> On 23 Oct 2019, at 13:50, Patrick M. Hausen  wrote:
> 
> Hi all,
> 
> would you recommend the 4461 to run a handful of
> full feeds for v4 and v6? The model seems to be quite
> affordable compared to ASR 9000 series routers and
> throughput is not our main concern for upstream.

It will do fine. Memory and performance shouldn’t be an issue until you
reach around 7Gbps (with BOOST license, if you’re not running virtual
containers).

If that’s not enough, consider ASR 1001X/1001HX.

— 
./
___
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 multicast hardware forwarding missing

[Łukasz Bromirski]

Christian,

What does the 'show mls cef exception status’ say?

If you want, send the SR # to my @cisco.com address (lukasz.bromirski) and I’ll
look into what’s going on at the TAC end.

Thanks!
-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

___
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] OSPF flapping between Nexus 7000 and ASR 1001x

[Łukasz Bromirski]

> On 9 Jul 2019, at 17:58, Richard Mikisa  wrote:
> 
> Hi All,
> 
> I am running OSPF across a point to point link between a Nexus 7000
> and an ASR1000x.
> 
> The OSPF works fine but every couple of hours, it breaks and neighbor
> state goes into EXCHANGE and remains there for another 40 minutes or
> so. It then goes into full, OSPF comes up and all is well for another
> couple of hours or so and then the cycle starts again. All the time,
> IP connectivity between the two point to point IPs is up.

Apart from OSPF config changes already mentioned, check what’s going
on in your CoPP policies on both ends. This doesn’t look like a directly
config-related problem, rather environmental (like circuit switchover and
problems with MTU) but it may also be something related to amount
of traffic hitting CoPP policies from time to time and OSPF traffic overflowing
defined queues.

—
./


signature.asc
Description: Message signed with OpenPGP
___
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 920 Replacement

[Łukasz Bromirski]

Gert,

> On 27 Jun 2019, at 18:00, Gert Doering  wrote:
> 
> Hi,
> 
> On Thu, Jun 27, 2019 at 05:49:42PM +0200, ??ukasz Bromirski wrote:
>> There are currently no such plans, but the natural current replacement would
>> be NCS 540 (IOS-XR box) and NCS 560 (XR box as well, more alike
>> ASR 903/907 if you need modularity).
> 
> The boxes look very nice.
> 
> The table on software licensing looks like the usual Cisco nightmare,
> just more of it.

Oh c’mon, what would happen if we’d nail down *both* product and
licensing? Hell would freeze ;)

— 
./

___
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 920 Replacement

[Łukasz Bromirski]

> On 27 Jun 2019, at 17:53, Mark Tinka  wrote:
> 
> On 27/Jun/19 17:49, Łukasz Bromirski wrote:
> 
>> 
>> 
>> Putting my Cisco hat for a moment:
>> 
>> There are currently no such plans, but the natural current replacement
>> would
>> be NCS 540 (IOS-XR box) and NCS 560 (XR box as well, more alike
>> ASR 903/907 if you need modularity).
> 
> I don't know why for a Metro-E application, IOS XR is simply too
> heavy... maybe it's just me.
> 
> I've not ran IOS XR in anything other than a CRS or ASR9000, so can't
> say whether it's any quicker in an NCS*. But if not, I wouldn't want to
> be the one speaking to the NOC about why 700 boxes in the Metro are down
> for longer than what we had on an ASR920 (IOS XE) for a simple code
> upgrade :-).

:D “Good old days of solid iron with QNX-running XR”.

NCS 540 boots in ~90 seconds depending on the complexity of the
configuration. I just did reboot one to check if I’m right.

— 
./
___
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 920 Replacement

[Łukasz Bromirski]

> On 27 Jun 2019, at 10:15, Mark Tinka  wrote:
> 
> On 27/Jun/19 01:46, Laurent Dumont wrote:
>> Overall, it looks like specific IOS versions are being eol-ed.
> 
> That is common, and expected.
> 
>> Has anyone seen any indication that the hardware platform itself would
>> be phased out?
> 
> Nope.


Putting my Cisco hat for a moment:

There are currently no such plans, but the natural current replacement would
be NCS 540 (IOS-XR box) and NCS 560 (XR box as well, more alike
ASR 903/907 if you need modularity).

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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 1006 nat performance

[Łukasz Bromirski]

> On 21 Mar 2019, at 16:59, Satish Patel  wrote:
> 
> Folks,
> 
> We are building openstack cloud and we need solic network gateway for
> handling out NATing for virtual instances.
> 
> I have Cisco ASR 1006 with 40G ESP, How many NAT translation it can
> handle concurrently?
> what about the performance hit?

2M, Table 20:
https://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/datasheet-c78-731640.html
 


— 
./
___
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 4k Performance and Boost Licensing

[Łukasz Bromirski]

> On 30 Jan 2019, at 15:11, Adam Greene  wrote:
> 
> Rick,
> 
> My impression from reading the documentation has been that the Boost license
> can be activated independently of the Performance license.
> 
> Maybe someone who's actually implemented it can confirm! ;)

Yes, “boost" is all you need if you need performance *only*. Take note however 
all
cores are used so no-no for the VMs or any other apps on top of ISR.

— 
./
___
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] Max usable RAM on a Cisco 3945E?

[Łukasz Bromirski]

You can put 4GB safely into 3945E:

> On 13 Jan 2019, at 19:54, Mark Leonard  wrote:
> 
> Hi all,
> 
> I recall reading back in the day that the ISR G2 series (specifically
> the 3900s) couldn't address more than 2GB of RAM even though kits were
> available for 4GB.  Was this ever resolved through an IOS update?
> 
> Situation: I have a (new to me) 3945E that I'd like to have do
> multiple peers with full IPv4 tables.  It has 1GB and that's
> clearly not enough (started running out of RAM with the first peer).
> 
> Are there any FIB/CEF limits that I will end up hitting if I proceed
> with the 3945E?  Should I cut my losses and start saving up for an
> ASR1k?

System Bootstrap, Version 15.1(1r)T4, RELEASE SOFTWARE (fc1)
[…]
Total memory size = 4096 MB - DIMM0 = 2048 MB, DIMM1 = 2048 MB
CISCO3945-CHASSIS with C3900-SPE250/K9 with 3145728 Kbytes of main memory
Main memory is configured to 72/72(dimm 0/1) bit mode with ECC enabled
[…]
Cisco CISCO3945-CHASSIS (revision 1.0) with C3900-SPE250/K9 with 
2839552K/306176K bytes of memory.
Processor board ID […]
8 Gigabit Ethernet interfaces
2 terminal lines
1 Virtual Private Network (VPN) Module
DRAM configuration is 72 bits wide with parity enabled.
256K bytes of non-volatile configuration memory.
2572272K bytes of USB Flash usbflash0 (Read/Write)
250880K bytes of ATA System CompactFlash 0 (Read/Write)
500472K bytes of ATA CompactFlash 1 (Read/Write)

Router#sh mem stat
HeadTotal(b) Used(b) Free(b)   Lowest(b)  Largest(b)
Processor   22B0A394   2572115052   145640160   2426474892   2426406192   
2426253124
  I/O   1000A394   31352422491213096   222311128   222311128   83280

ASR 1001X/1001HX is always best bet for hardware forwarding :)

—
./


signature.asc
Description: Message signed with OpenPGP
___
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] ASR1001 maximum FIB size

[Łukasz Bromirski]

> On 27 Dec 2018, at 00:51, Robert Hass  wrote:
> 
> Hi
> I'm looking for information what is maximum FIB size for ASR1001 (with 16GB
> RAM) platform ?
> 
> Is it 1M or 2M ? (IPv4)

For 1001 it’s 1M IPv4 or IPv6 with 8/16GB RAM. Note 1001 is EoS.

1001-X has 1M for 8GB and 3.5M for 16GB (Table 8):
https://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/data_sheet_c78-441072.html
 
<https://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/data_sheet_c78-441072.html>

HTH,
--
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A


signature.asc
Description: Message signed with OpenPGP
___
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 DFZ convergence time - FIB programming

[Łukasz Bromirski]

Robert,

> On 5 Oct 2018, at 09:17, Robert Hass  wrote:
> 
> Hi
> I'm looking for share experiences regarding time needed to program full DFZ
> table (710K IPv4 prefixes) on NCS 5500 boxes.
> 
> Right now we testing competitors (Jericho based boxes) and results are not
> impressive - time needed to program is aroud 2min 30sec up to 3min.
> 
> How fast NCS 5500 is handing FIB programming ?

Please take a look here:
https://xrdocs.io/cloud-scale-networking/tutorials/ncs5500-fib-programming-speed/
 
<https://xrdocs.io/cloud-scale-networking/tutorials/ncs5500-fib-programming-speed/>

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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] router suggestion for backup link

[Łukasz Bromirski]

Gert,

> On 14 Jul 2018, at 08:25, Gert Doering  wrote:
> 
> This very much depends on what this box needs to do, except "2.5 Gbit".
> 
> ISR44xx ends at 2 Gbit/s for the 4451, so it's not interesting anyway.

ISRs can get ‘performance’ or ‘boost’ license, with which the internal
shaper “goes to eleven” (with ‘performance’) license and is turned off
completely (with ‘boost’). You can’t run VMs on ISR 4k’s anymore
with those, but the performance goes way above 2.5Gbit/s required.

The latest slide decks on ciscolive.com <http://ciscolive.com/> should have it 
as this slide
was presented on the ISR architecture session, however all I can
get now fast is this small screenshot from German blog:
https://alln-extcloud-storage.cisco.com/gblogs/sites/48/Bildschirmfoto-2018-02-11-um-14.45.48-500x284.png

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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] IPsec throughput on Cat6800 Sup2T

[Łukasz Bromirski]

> On 30 Apr 2018, at 18:01, Hunter Fuller <hf0...@uah.edu> wrote:
> 
> Hi all,
> 
> Does anyone know what throughput I can expect from IPsec terminated on a
> Supervisor 2T?

Zero. It’s not supported.

IPsec if it will be available and actually working (IOS code still contains full
IPsec stack, so it may actually work) will hit directly Your CPU. At
good times You may even get some serious Mbit/s but at the expense of
stability of your whole platform.

That’s why IPsec should be offloaded to dedicated SPA.
-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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] Nexus 7707 as Internet Edge Router?

[Łukasz Bromirski]

> On 16 Nov 2017, at 08:49, Gert Doering <g...@greenie.muc.de> wrote:
> 
> Hi,
> 
> On Wed, Nov 15, 2017 at 11:03:50PM +0100, ??ukasz Bromirski wrote:
>> 2901 supports VRRP. 
> 
> Yes, but not VRRPv3 for IPv6 (at least in the code base we've rolled
> out, haven't investigated if it's in some sort of 15.6T or later).

It may be. That’s from my home terminal server:

rtr-ts#sh ver | i IOS
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.6(2)T1, 
RELEASE SOFTWARE (fc1)
rtr-ts(config)#fhrp version vrrp v3

That’s a version that was published July last year.

>> Those things are ???PI??? code (Platform Independent).
> Right, so why is there no HSRPv2 on ASR920, or EIGRP on NCS5000, or static
> LSPs on 6500?  These are all control plane features, independent off the 
> underlying hardware.

It’s up to BU to pull the code. I never wrote anywhere that, You
know, everybody is pulling all the code they can find just for
the sake of having everything :) The trend these days is exactly
opposite thanks to years of roasting us (Cisco) for having too
much features and in effect - too much bugs. PMs for BUs it
seems started to be picky in terms of what goes in. This is in
addition to the fact, that right now every new platform should
run IOS-XE, which by itself is perfectly capable of running
modular, and this again add options. ASR 9xx are quite complex
in terms of hardware offload capabilities BTW, and each SKU may
have it’s own ‘specialities’. It’s worth double-checking release
notes and config guides with local SE before booking time for
testing.

Having said that - there may be some hardware dependencies with
HSRP or LSPs (for EIGRP the only think I can think of is no immediate
need to run it in SP networks). But that’s just me guessing, not
our official policy.

>> As soon as you hit hardware dependencies however in platforms that
>> offload something to hardware??? yes, world isn???t a fairy tale, no matter 
>> which
>> vendor you decide to lock-in-to.
> 
> I fully understand hardware limitations, coming from a world full of
> 6500 :-) - and the 6500/7600 split was a good example of "no, these lacking
> features have nothing to do with hardware capabilities”.

I know You do :) 

> Things like missing EIGRP or HSRPv2 cannot even be properly explained
> with BU in-fighting (like, OTV vs EVPN) if the code is already there for
> the OS used…

It’s probably more like Inception (the movie). Layers of layers over
layers of different requests, priorities, platform positioning challenges,
and so on.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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] Nexus 7707 as Internet Edge Router?

[Łukasz Bromirski]

Gert,

> Return to Step 1 - "why, if you have customers actually *liking* your
> vendor-lock-in features, why would you stop shipping them?".
> 
> Actually they seem to be really liking that... ASR920 doesn't do HSRPv2
> (though it *does* support HSRPv1).  So, if you have a 2901 + ASR920
> as router pair, no IPv6 first-hop redundancy for you (while ASR920 will
> do VRRP instead, 2901 won't).

2901 supports VRRP. Those things are “PI” code (Platform Independent).
As soon as you hit hardware dependencies however in platforms that
offload something to hardware… yes, world isn’t a fairy tale, no matter which
vendor you decide to lock-in-to.

—
./


signature.asc
Description: Message signed with OpenPGP
___
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] ISIS/BFD Monitoring

[Łukasz Bromirski]

> On 18 Sep 2017, at 11:36, Nick Hilliard  wrote:
> 
> Graham Beneke wrote:
>> We also have setup "ip sla" on some links. The status of the ip sla can
>> then be polled by the NMS over SNMP to detect the state of the link.
> 
> My favourite failure mode is when a provider drops the link MTU without
> notice.

During internal reroute event. Once every n-th months during random
time of the day. When Mars and Moon have this specific setting in
the sky.

But event then.. not always of course.

— 
;)
___
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 1k vs 9k as a non-transit BGP router with full tables?

[Łukasz Bromirski]

Mark,

> On 4 Aug 2017, at 10:43, Mark Tinka <mark.ti...@seacom.mu> wrote:
> 
> On 4/Aug/17 00:52, Łukasz Bromirski wrote:
>> 
>> - the ‘HX’ series currently consist only of 1001HX and 1002HX, so both
>> fixed platforms with some modularity included; there are no HX fully
>> modular chassis, so my comment above was misleading in terms of
>> 1001HX/1002HX supporting RP3 - they simply can’t
> 
> Understood.
> 
> So for all intents & purposes then, the only RP3-based systems today are the 
> fully modular ASR1006-X, ASR1009-X and ASR1013, yes?

Yes, that’s correct.

The fastest RP in fixed builds is in 1002HX, however it will be still
slower than what you should expect from RP3.

Additionally, RP3 offers four times more RAM than any other RP on
ASR 1000 - 64GB vs 16GB in RP2 and in fixed units.

HTH,
— 
./
___
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 1k vs 9k as a non-transit BGP router with full tables?

[Łukasz Bromirski]

Mark,

> On 3 Aug 2017, at 10:39, Mark Tinka  wrote:
>> ‘HX’ versions are current-gen, newest boxes, that can use
>> RP3 and up to 64GB of RAM. For fixed options there are 1001HX and 1002HX
>> as of now and they scale up to 16GB of physical RAM (1001HX)
>> and 32GB of physical RAM (1002HX).[1]
> So just to clarify, the fixed -HX units are all RP3-based, yes?

Sorry, mixed couple of things in one paragraph. To clarify my clarification:

- RP1 is PowerPC based, long gone, not very bad, but FIB programming
for example was not stellar in terms of speed

- RP2 and RP3 are x86 64-bit capable, with RP3 only recently getting
support in 16.3 train which may be showstopper for some of you

- RP2 supports maximum of 16GB, while RP3 supports up to 64GB

- 1001HX in terms of RP performance envelope is closer to 1002X, so
RP2 based system; fixed configs have usually slightly scaled down Xeons
inside to meet more restrictive temperature environment

- 1002HX RP performance is around that of RP2, however in some
scenarios can be 20-25% faster; again, fixed platform having it’s own
requirements that are absent in fully modular chassis and more powerful
fans and cooling capabilities

- the ‘HX’ series currently consist only of 1001HX and 1002HX, so both
fixed platforms with some modularity included; there are no HX fully
modular chassis, so my comment above was misleading in terms of
1001HX/1002HX supporting RP3 - they simply can’t

HTH,
— 
./

___
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 1k vs 9k as a non-transit BGP router with full tables?

[Łukasz Bromirski]

> On 3 Aug 2017, at 09:10, Patrick M. Hausen  wrote:
> 
> The use case is simply "full tables BGP" with currently 4x 1GB/s
> uplinks and possibly 6 in the near future. Upgrade to something
> 10G-ish not planned at the moment. 300-400 Mbit/s aggregate
> traffic across all uplinks currently.

Quite low aggregate bandwidth needs for 6500 :)

> So we are too memory heavy for the C6500 (SUP720-10G) and
> then there's the TCAM limitation ... although our bandwidth requirements
> are rather small. And then the C6500 definitely starts to rot - I wonder
> if I will ever get anything beyond 12.2(33)SXJ10 if (when!) the next
> remote security bug hits.

For that kind of scenario, Sup720-10GE can still do it’s job if
You use Selective Route Download. You don’t need full tables as
Spotify’s SIR project have shown. You’re even better than Spotify,
as You’re end station for the traffic, not transit as I understood.
Just take a look here (and read on):
https://labs.spotify.com/2016/01/26/sdn-internet-router-part-1/ 


You should live well with the same traffic engineering accuracy
with anywhere between 30k and 60-70k for IPv4 unicast put into
FIB and then into TCAMs. At the same time, You should be fine
(maybe with *some* filtering) to fit the 4-6 tables in RAM while
doing SRD (that will select specific routes and put only them as
candidates for FIB installation via BGP).

This however assumes, You want to play with CLI and possibly
NetFlow data to correlate telemetry.

Also, try to stick to 15.xS lines. It seems You’re doing quite simple things
and there’s no real value in staying on 12.2(33) line unless some
hardware dependencies.

BTW, you can upgrade RAM on 720-10GE to 2GB. This is of course not
officially supported, but as You’re anyway running on refubrished equipment,
you don’t care that much. Just remember to upgrade both RP and SP 
memory, as in theory with this Sup you wouldn’t need to care anymore
as SP is just a stub, but may actually play buffer allocation tricks
and if there’s disrepancy between RP and SP RAM size, you may
run into trouble (RP loosing SP, stalling and then rebooting on
watchdog - it isn’t pretty and for sure - not predictable).

— 
./
___
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] 3750G Hardware revision information

[Łukasz Bromirski]

> On 14 Jan 2017, at 18:18, Kenny Long <long.ke...@gmail.com> wrote:
> 
> For the 3750G-24PS-E I notice there are different hardware versions (ie
> V05, V06).  Does Cisco publish the details of these revisions?  If you know
> of a resource documenting this information I would appreciate it.

They are not published, and reflect internal changes to the production
process that shouldn’t change hardware and software characteristics.

If there are some specific fixes that work only after some specific
hardware revision, they are usually documented in the release notes.
For that kind of platforms they’re rare, for platforms with linecards - 
they do happen sometimes.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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] Cat6500 VLAN cannot be assigned to a routed port sub-if?

[Łukasz Bromirski]

> On 16 Sep 2016, at 17:32, Nick Cutting <ncutt...@edgetg.com 
> <mailto:ncutt...@edgetg.com>> wrote:
> 
> Depends on supervisor - With sup 2t - you could reuse vlans on subinterfaces, 
> here is 2 subinterfaces on different ports, and an SVI all on vlan 281
> 
> !
> interface Vlan281
> no ip address
> shutdown
> end
> !
> interface TenGigabitEthernet2/5/9.281
> encapsulation dot1Q 281
> end
> !
> interface TenGigabitEthernet2/5/8.281
> encapsulation dot1Q 281
> end

That’s actually config that will work with all Supervisors, wrong example :)

I understand Patrick is looking for a way to distinguish switched VLANs from
routed VLANs, and indeed VLANs can be reused to forward different traffic with
VLAN local significance on 6500/7600 starting from Sup2T.

For that (Patrick) needs bridge domains, so EVC infra - which is available
on Sup2T with all ports, even with classical “LAN” cards - no SIPs needed.

Config examples for different scenarios - google found it:
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-2SY/config_guide/sup2T/15_2_sy_swcg_2T/ethernet_virtual_connection.pdf
 
<http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-2SY/config_guide/sup2T/15_2_sy_swcg_2T/ethernet_virtual_connection.pdf>

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
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] 6VPE on 7600 RSP720 3CXL

[Łukasz Bromirski]

> On 22 Oct 2015, at 17:42, Gert Doering <g...@greenie.muc.de> wrote:
> 
> Hi,
> 
> On Tue, Oct 20, 2015 at 09:20:43PM +0200, ??ukasz Bromirski wrote:
> [..]
>>> you're in trouble;
>> Well, not exactly.
> [..]
>> In other words - you???re safe, the box won???t melt, but the situation
>> will require fixing & reload.
> 
> Well, "require reload" definitely smells like "in trouble", no? ;-)

Sure, but just look at the bright side - after couple of years we
finally managed to get mls rate-limiter protection. Before it was
node suddenly vanishing from the network. An edge node vanishing
may be trouble squared ;P

-- 
Łukasz Bromirski, luk...@bromirski.net
CCIE R/SP #15929, CCDE #2012::17
___
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] 6VPE on 7600 RSP720 3CXL

[Łukasz Bromirski]

> On 20 Oct 2015, at 10:55, James Bensley <jwbens...@gmail.com> wrote:
> 
> I will probably aim for 60k IPv6 routes, so it's enough to phase out
> the boxes and that's it. Be careful that these boxes will start to CPU
> switch packets before you run out of TACM. When you see these logs
> you're in trouble;

Well, not exactly.

Last I remember, it was changed in 12.2(33)SXH - when the PFC hits
exception on TCAM, it’ll switch “exception” packets (packets to
destination that’s outside of known TCAM programmed entries) with
a mls hardware-limiter set to 10kpps.

In other words - you’re safe, the box won’t melt, but the situation
will require fixing & reload.

-- 
Łukasz Bromirski, luk...@bromirski.net
CCIE R/SP #15929, CCDE #2012::17

___
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 uRPF/ Bogon route help

[Łukasz Bromirski]

> On 12 Oct 2015, at 23:27, f287c...@opayq.com wrote:
> 
> Today.. I only have one ISP and uRPF works fine with this syntax 
> -> " ip verify unicast source reachable-via any 2699" 
> I'm moving to a router with multiple  ISP and IX connections and some of our 
> traffic is now asymmetric.
> The above uRPF config didn't work and was removed. 

This should work, but there’s little detail provided.

Did you configure it on both of the uplinks?
How did you monitor the drops and concluded that it ‘didn’t work’?
How you get the default route, is it pointing on one
of the uplinks? ‘allow-default’ may be important here.

-- 
"Those pople who think they know  |   Łukasz Bromirski
 everything, are a great annoyance to |  jid:lbromir...@jabber.org
 those of us, who do."   Isaac Asimov |http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco IOS SLB performance under Supervisor 2T

[Łukasz Bromirski]

> On 02 Sep 2015, at 22:52, Peter Kranz <pkr...@unwiredltd.com> wrote:
> 
> This document indicates a maximum of 8G of throughput for IOS SLB under a
> Supervisor 720-3BXL
> 
> http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/persiste
> nt-storage-device-module/product_data_sheet0900aecd806b5dc9.html
> 
> Is anyone aware of what the performance limitation of this feature is under
> the newer Supervisor 2T-10G-XL?

IOS SLB is old feature that was deprecated some time ago in
the IOS. The natural migration path was Cisco CSM, then ACE
service card, but then it was itself EoSed.

Right now it’s either F5 or Citrix for large-scale load
balancing. Or our beloved L3/L4 which you mentioned in 
previous post.

While Sup720 may still support it, 15.1Y and newer versions for
Sup2T don’t. This means: some commands may be there in the parser,
trick you in entering them, and then kill you with performance,
bugs, or simply do not work at all, which sometimes is blessing.

-- 
Łukasz Bromirski
___
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 multipath load balancing.. broken sessions upon hash change

[Łukasz Bromirski]

Peter,

> On 02 Sep 2015, at 22:49, Peter Kranz <pkr...@unwiredltd.com> wrote:
> 
> I’m using bgp maximum-paths and several peers announcing the same /32 to
> create a poor man’s load balancer. This works well with up to 16 peers after
> which the CEF number of buckets is exceeded.
> 
> However, if the number of connected peers change, all sessions break, which
> I would like to avoid.

That’s the way CEF works - it has to rebuild the hash every
time new nexthop appears or vanishes. 

This is 6500 you’ve mentioned in different post, right? What
is the overall architecture of the thing you’re trying to
achieve here (remote terminal access?). 

— 
Łukasz Bromirski
___
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] ASA and BGP

[Łukasz Bromirski]

 On 31 Jul 2015, at 10:23, Nick Cutting ncutt...@edgetg.co.uk wrote:
 
 Just got confirmation that it is ~22,000 routes. 4 gig of ram on a 5515x. 
 should be fine.  
 However, I'm worried that no one is doing this, anywhere.

There’s quite a number of ASA edge deployments around the world, and most of
them are full BGP feeds. It’s being done, but maybe not yet “at large”, as 
typically
people tend to let boxes like ASR 1k or 7200 do the edge BGP stuff.

(I’m from Cisco BTW, should have stated this immediately in first post)

If you have some specific questions please let us know - otherwise, I presume
you’re just worried about the “installed base” experience :)

— 
./
___
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] ASA and BGP

[Łukasz Bromirski]

 On 30 Jul 2015, at 15:20, Nick Cutting ncutt...@edgetg.co.uk wrote:
 
 I've tried running BGP on the ASA, just few routes, seems to work fine.
 
 But now I may need to take in a whole lot more, in a location that only has a 
 pair of ASAs in Asia. 
 
 I cannot find any documentation about routing limits on the ASA, except for 
 IGP, which states as many as the config(flash) and memory supports.
 
 Now that BGP is supported on the ASA, has anyone been crazy enough to take in 
 a full table, or a few thousand routes?

Sure, 580k+. Shouldn’t be a problem, RAM is plentiful if you’re
not doing thousands of translations/etc.

-- 
| There's no sense in being precise  |Łukasz Bromirski |
|  when you don't know what you're|   jid:lbromir...@jabber.org |
|  talking about.   John von Neumann | http://lukasz.bromirski.net |

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] GRE tunnel 8000kbit (8Mbit) limit issue

[Łukasz Bromirski]

 On 15 Jul 2015, at 19:34, a.l.m.bu...@lboro.ac.uk wrote:
 
 hi,
 
 okay...have googled and looked around...and no current joy.

Tunnel bandwidth configured on the interface, or being default is
only for information, and is not being enforced in any way. 

 we have a GRE tunnel between a 6506 (sup2T) running IOS 15.1 and a 3750 
 running IOS 15.2

3750 doesn’t support GRE, you’re hitting limitation of the platform.
It’s miracle it works - mostly propably, because it hits software
forwarding path, and even if it’s not supported, it works - somewhat.

-- 
| There's no sense in being precise  |Łukasz Bromirski |
|  when you don't know what you're|   jid:lbromir...@jabber.org |
|  talking about.   John von Neumann | http://lukasz.bromirski.net |

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] GRE tunnel 8000kbit (8Mbit) limit issue

[Łukasz Bromirski]

 On 15 Jul 2015, at 20:50, a.l.m.bu...@lboro.ac.uk wrote:
 
 Hi,
 
 we have a GRE tunnel between a 6506 (sup2T) running IOS 15.1 and a 3750 
 running IOS 15.2
 
 3750 doesn’t support GRE, you’re hitting limitation of the platform.
 It’s miracle it works - mostly propably, because it hits software
 forwarding path, and even if it’s not supported, it works - somewhat.
 
 3750x  - not 3750 (the classic 3750g etc) or 3750e

OK, still no luck though - 3750x doesn’t support GRE
termination, you’re going through software CEF path.

-- 
| There's no sense in being precise  |Łukasz Bromirski |
|  when you don't know what you're|   jid:lbromir...@jabber.org |
|  talking about.   John von Neumann | http://lukasz.bromirski.net |

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] New IOS release time frame, when bug is identified

[Łukasz Bromirski]

Hi CiscoNSPList (we love that anonymous names!),

 On 15 May 2015, at 06:21, CiscoNSP List cisconsp_l...@hotmail.com wrote:
 
 Hi Everyone,
 
 Ive unfortunately uncovered a bug on the ME3600, and Cisco are recommending I 
 wait until IOS version with fix is released...problem is that they have given 
 me a date of 30th September 2015 for the release date!

Do you have an active support contract?

What’s the bug? It is forwarding-impacting? Maybe it’s
cosmetic? 

What the case owner actually said/wrote? Can you give us
case number, or bug number?

-- 
Those pople who think they know  |   Łukasz Bromirski
 everything, are a great annoyance to |  jid:lbromir...@jabber.org
 those of us, who do.   Isaac Asimov |http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Load balancing

[Łukasz Bromirski]

 On 12 May 2015, at 09:55, M K gunner_...@live.com wrote:
 
 Do you ever hear that REP is in an exam

Yes it is.

 

First exclamation mark was OK.

Second was sign of something gone horribly wrong.

You didn’t fix formatting, and added a lot more of exclamation marks.
I stopped reading after eight, which is long enough to start
laughing maniacally.

Have a good day,
-- 
Those pople who think they know  |   Łukasz Bromirski
 everything, are a great annoyance to |  jid:lbromir...@jabber.org
 those of us, who do.   Isaac Asimov |http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco iWAN Solution

[Łukasz Bromirski]

 On 02 May 2015, at 19:52, Pavel Skovajsa pavel.skova...@gmail.com wrote:
 
 Hello Ranjith,
 
 The IWAN solution is relatively new, so you will not find a lot of people
 with experience with it.

True.

 Also there are interesting operational issues that are probably much harder
 to fix in IWAN world. For example the customer calls you and tells you that
 yesterday at 9:35AM their application did not work in SiteA. How would you
 know which path the traffic took? It is dynamic, so how would you
 troubleshoot?

PfR logs prefix decisions, and you can store them either in some
syslog server, or in other software solutions that provide more
capabilities than just checking.

 Now to your questions:
 How good is the PFR feature for load balancing effectively among multiple 
 internet
 links
 PFR is traditionally excellent in this, without configuration it actually
 loadbalances almost precisely 50/50.

Well, that’ll depend on the configuration and traffic characteristics.

 If I understand correctly what you are asking is whether PFR works for
 Direct Internet Access. No, it does not, my understanding is that PFR only
 works inside the DMVPN cloud inside the Enterprise. The reason is simple -
 PFR not only changes the forward path, but also the return path, hence you
 need full control of both sides.

PfR works on prefixes and reachability information, so no, it is not
dependent on the DMVPN cloud. You can run (and people usually do) for
pure IP traffic. It’s capability to actually run and use different
types of tunnels makes it more flexible.

-- 
Those pople who think they know|  Łukasz Bromirski
 everything, are a great annoyance to   | jid:lbromir...@jabber.org
 those of us, who do. Isaac Asimov |   http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Upgrading Catalyst 6500 from 720-3B to 720-3BXL

[Łukasz Bromirski]

Fernando,

 On 28 Apr 2015, at 18:18, Fernando García Fernández lis...@cutre.net wrote:
 
 Hello John and Gert
 
 I assume that I must reboot. But what I wanted is to have a procedure that 
 minimizes the downtime and allows me to go back if anything goes wrong.
 
 If I don’t activate redundancy, could I copy the configuration from the 
 active RSP to the new one so when I reboot with it (shuting down, removing 
 old RSP) It can go up with the new one?

It will work, but the 3BXL Sup will boot in 3B mode. After you do
all the copying, cleaning and so on, you’ll need to remove the 3B
and reboot the 3BXL.

BTW, if you plan to run on one Sup only, you can actually move
the 6748 into the vacant Sup slot to use power reserved anyway for
Sup and keep other slots free. But it will also influence the 
config (interface numbering).

-- 
There's no sense in being precise when |Łukasz Bromirski
you don't know what you're talking  |   jid:lbromir...@jabber.org
about.   John von Neumann  | http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] One Cat6k/Sup2T is software switching, its identical partner is not

[Łukasz Bromirski]

Hi Jeroen,

 On 17 Apr 2015, at 13:16, Jeroen van Ingen jer...@zijndomein.nl wrote:
 
 We have two Cat6k's with Sup2T in our network, both running IOS 15.1(1)SY3.

Are they really identical, down to Sw/Hw revisions and ROMMON 
versions?

It seems that something on the device side either interprets
the configuration in different order and this hits some
rare bug, or there’s something other at the software/hardware
border that you’re hitting.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 3850?

[Łukasz Bromirski]

 On 11 Apr 2015, at 00:26, Adam Greene maill...@webjogger.net wrote:
 
 We're not actually doing Netflow of any kind yet. 

OK.

 It looks like most of our input queue drops are due to 'encapsulation failed' 
 ... i.e. bogus traffic to non-existent hosts. So far it hasn't affected 
 legitimate network performance, as far as we can tell.

I’d SPAN that traffic and take a look. You shouldn’t have that much
traffic resulting in encapsulation failed, unless it’s very “dirty”
access network, with a lot of botnets spewing spoofed/random traffic
all around.

 So maybe the 3750/3750G's will actually be able to support 450Mbps aggregate 
 gracefully and we can afford to avoid upgrading for now ... that's a nice 
 surprise.

3750/3750G are gigabit switches, and they should support up to
1Gbit/s per port. I actually read whole thread, and the first
answer You got was about tuning buffers - did you do that?

Remember, those are “Enteprise” switches, so their QoS and
buffers by default reflect access scenario with rather lazy
workstation generating traffic in peaks.

You need to turn MLS QoS on, and then tune buffers to be
able to accept traffic at high rates.

 (b) to respond to customer congestion complaints by explaining, you are 
 using your whole pipe to download windows updates: schedule those for 
 off-hours! etc.

If that’s also a problem, try to set up local cache to offload
that kind of things as close customers as you can.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 3850?

[Łukasz Bromirski]

 On 10 Apr 2015, at 12:42, Marco van den Bovenkamp ma...@linuxgoeroe.dhs.org 
 wrote:
 
 
 I think there's an uplink module for the 3750-X series which does
 netflow now, too?
 
 Yep. The C3KX-SM-10G. That'll do line-rate FNF (or so thaey claim; haven't 
 used them yet).

It does and the only limitation here is cache size. There is a
way to RPSAN traffic from all ports in the switch despite this
module capable of monitoring only traffic transitioning it’s
ports using SFP loopback cable and one of the ports.

Without this module you can force generic 3k’s to generate
NetFlow info triggered by some specific events on the switch
by feature called Smart Logging and Telemetry:

http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-series-switches/product_bulletin_c25-658743.html

For truly all-ports NetFlow capable solutions in Cisco access
portfolio go with 3650 and/or 3850.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 3850?

[Łukasz Bromirski]

 On 09 Apr 2015, at 22:55, Adam Greene maill...@webjogger.net wrote:
 
 Thanks guys. 
 3750G#sh int g2/0/17 stats
 GigabitEthernet2/0/17
 Switch pathPkts In   Chars In   Pkts Out  Chars Out
   Processor   97455044 1696659687   11378007 1004114773
 Route cache9380325 20154948421774316  128292897
   Total  106835369 3712154529   13152323 1132407670
 
 A ' debug ip cef drop' shows that the cef drops appear to be on traffic
 destined for an interface with multiple secondary IP addresses and CAR on
 it. Hmm. Maybe I'll remove the CAR; don't really need it there anymore.

CAR is long deprecated. If you need some rate-limiting, use
the broadcast/unicast storm control or MQC with MLS QoS.

 Re: FNF  NBAR, it sounds like I should plan to leave off the NBAR. Thought
 it would be nice for classifying the traffic, but not if it's going to cause
 performance hits. We can leave NBAR to the routers.

I’m lost here on which platform you’re doing that stuff - if that’s
3750 (as host name from quote above suggests) NBAR works anyway only
for RP-bound traffic so you should turn it off as it’s not supported.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Wired - ISE Posture + AnyConnect (ISEPostureCFG.xml not found)

[Łukasz Bromirski]

Hi Manu,

 On 31 Mar 2015, at 18:12, Manu Chao linux.ya...@gmail.com wrote:
 
 I am running a PoC with ISE (802.1x up/running) with Posture with AnyConnect 
 on wired PC (win7).
 
 Could you please share ISEPostureCFG.xml (not found, using default) to be 
 configured on wired PC?
 
 Right now, AnyConnect ISE Posture module installed on wired computer cannot 
 detect ISE servers:
 - No policy server detected

PoC is usually assisted by one of Cisco Partners. Try to
look up them using Partner Locator
(http://www.cisco.com/go/partnerlocator) and ask for help.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] power requirement for WS-X614E-GE-45AT in reverse POE mode

[Łukasz Bromirski]

Nick,

 On 01 Apr 2015, at 14:35, Nick Hilliard n...@foobar.org wrote:
 
 On 01/04/2015 08:38, Gert Doering wrote:
 If I run a WS-X6148E-GE-45AT in reverse POE mode (feeding power into
 the 6500), but do not use the ports for actual switching, will the line
 card still require power?
 
 I've run this configuration in production on a number of occasions and it
 works quite well up to and including powering up a fully loaded 6509.

I’ve digged up some old docs, and while they’re internal only,
I can share that it doesn’t work on the NEBS chasiss.

 There are two things you need to be careful about: first, you need to
 ensure that you get the POE load balancing right across all the port groups
 on this particular blade.  If you inject too much power into a single port
 group, parts of the blade will suffer from brownout.

There’s other thing to note here - watch out for DFCs installed in
the chassis. The reverse-PoE trick causes a lot of failures here.
I wouldn’t do that kind of deployment with any DFCs in the chassis.

 One of the local data centres is looking into this as a mechanism for doing
 remote power supply for some section of their data centres which have
 inadequate input power supply.  I'm interested to see how it will scale, as
 obviously there are going to be some issues with UTP cross-connects.  I
 believe they're also looking at using PoE over fibre, due to the higher
 capacity available.  Will let you know how it pans out.

PoE over fibre? Nah, you must have had misunderstood the specs.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] power requirement for WS-X614E-GE-45AT in reverse POE mode

[Łukasz Bromirski]

 On 01 Apr 2015, at 16:30, Joe Loiacono jloia...@csc.com wrote:
 
 cisco-nsp cisco-nsp-boun...@puck.nether.net wrote on 04/01/2015 09:04:04 
 AM:
 
  From: Łukasz Bromirski luk...@bromirski.net 
 
   One of the local data centres is looking into this as a mechanism for 
   doing
   remote power supply for some section of their data centres which have
   inadequate input power supply.  I'm interested to see how it will scale, 
   as
   obviously there are going to be some issues with UTP cross-connects.  I
   believe they're also looking at using PoE over fibre, due to the higher
   capacity available.  Will let you know how it pans out.
  
  PoE over fibre? Nah, you must have had misunderstood the specs. 
 
 I'm sure he meant PoE over wireless. 

Yeah, but that’s for security cameras/etc - the DCs here in Europe are already
deploying that kind of installations.

I have to talk to my fellow TMEs in DC group, Nexus 7k with full ZX optics 
could actually
power a lot of stuff remotely.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] L2TPv3 ME3600 and SIP10 ASR1006

[Łukasz Bromirski]

 On 31 Mar 2015, at 16:19, Mark Tinka mark.ti...@seacom.mu wrote:
 On 31/Mar/15 16:04, James Bensley wrote:
 
 
 Yeah ISRG2 boxes do support L2TPv3. I have very successfully deployed
 them in very forgettable ways.
 
 Okay.
 
 So safe to say any software-based router should support it (excluding
 VM-based images, of course).

Theses days ‘software’ is becoming too general.

QFP on ASR1k are in essence programmable CPUs but with scalability
and performance similar to hardware platforms.

L2TPv3 is supported on all ISRs, including the new 44xx series, which
are - like ASR1k - also spending CPU cores (albeit, under common IOS
processing) to do forwarding job separately from control plane (which
one of the cores is doing).

CSR1k should also support L2TPv3 BTW.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] L2TPv3 ME3600 and SIP10 ASR1006

[Łukasz Bromirski]

 On 31 Mar 2015, at 16:41, Mark Tinka mark.ti...@seacom.mu wrote:

 If the ASR1000 does, then the CSR1000v would do it too. I assumed the
 ASR1000 didn't support it because it was a hardware box. But yes,
 considering the make-up of the QFP, it would make sense.
 
 So that leaves boxes built on IOS XR. As those don't do L2TPv3, it might
 be that XRv does not support it either.

Doesn’t. XRv generally barks at anything hardware-specific and that’s
good. Unfortunately, not always very specifically as to what it doesn’t
accept.

 Although not sure if the ASR920 would support it, considering it runs
 IOS XE a la ASR1000, but may not have a QFP setup.

It does, starting from 3.13S:
http://www.cisco.com/c/en/us/td/docs/routers/asr920/release/notes/ASR920_rel_notes/new_features.html

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ISR detects interface status with delay

[Łukasz Bromirski]

 On 08 Feb 2015, at 01:40, Martin T m4rtn...@gmail.com wrote:
 
 Lukasz,
 
 thanks for the reply! Just to make sure, there isn't a way to decrease
 this polling interval on ISR platform, is there?

In current code no, according to my knowledge.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ISR detects interface status with delay

[Łukasz Bromirski]

 On 06 Feb 2015, at 10:36, Martin T m4rtn...@gmail.com wrote:
 
 In order to illustrate this behavior I made a short video where IOS
 detects that interface Fa0/0 went down with almost 13 seconds delay.
 Usually this delay is around 5 to 8 seconds, but sometimes up to 15
 seconds. Video can be seen here:
 https://www.dropbox.com/s/yb9o379935s3hou/20150206_110347.mp4 PHY chip
 should detect this within micro- or milliseconds and as seen from the
 video, LED's indicating the link status went off immediately when I
 removed the cable, but why does it take so long for IOS to detect
 this?

First of all, carrier-delay on ISRs is not supported. The command is for
that hardware platforms, that have more extensive instrumentation
on the edge between hardware and software.

Second, ISR polls interface controllers for up/down, so your
better bet would be to use BFD, despite it being CPU-intensive,
to detect link up/down event.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASR1000 QFP/ESP utilization

[Łukasz Bromirski]

Chuck,

 On 15 Jan 2015, at 13:06, Chuck Church chuckchu...@gmail.com wrote:
 
 I took that as
 meaning the % of BW against your ESP limit such as 5 gigabit in this case.
 Our two I'm looking at (both running 3.7.4) look like this (bottom 3 lines):
 
 Total (pps)  344698  357155  334210
 340850
 (bps)   2266105832  2329040800  2187654192
 223908
 Processing: Load (pct)   4   5 4
 4
 
 The % listed is 4 or 5, yet the bps total seems to be about 2.2 gigabit, or
 approaching half  of what the ESP5 should be able of doing.  Should I just
 use the bps line and ignore the processing load line?  I'm not sure what
 it's indicating a percentage of.  The total bps line matches up pretty well
 with the 5 minute input count of all interfaces.

The processing load (percentage) is quite low, as ESP CPU may not be
tasked with lot of things to do on the traffic itself. Depending on the
features configured you may be either higher or lower.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ospf mtr

[Łukasz Bromirski]

 On 12 Dec 2014, at 21:56, Mohammad Khalil eng_m...@hotmail.com wrote:
 
 Hi all i am trying to configure osp mtr (multi-topology routing) 
 When configuring the policy-map i get the error cant provision policies of 
 type 2 any ideas

What’s the exact thing you’re trying to achieve and what’s
the exact error message you’re getting?

For QoS with MTR enabled take a look here:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mtr/configuration/15-s/mtr-15-s-book/qos-mqc-support-mtr.html

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Silly question regarding C3K-NM-10G

[Łukasz Bromirski]

 On 11 Sep 2014, at 16:12, Drew Weaver drew.wea...@thenap.com wrote:
 
 In the instructions for removing a network module from a 3560x it states 
 'carefully press the tab on the right side of the module'.
 
 I can't seem to locate a tab on the NM-10G which releases it from the slot.
 
 Is it under the mounting bracket? Under the faceplate? Is anyone aware of 
 where this mythical tab resides?

That’s an error in the doc, it should be corrected. There’s no
tab. You just unscrew the module and pull it.

-- 
There's no sense in being precise when |   Łukasz Bromirski
you don't know what you're talking |  jid:lbromir...@jabber.org
about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7301 - copper vs fibre port throughput

[Łukasz Bromirski]

On 31 Aug 2014, at 23:00, Tom Storey t...@snnap.net wrote:

 Hi all.
 
 Been watching a thread on a forum where someone using a 7301 was
 suffering rather lousey speeds through a 7301 when using an onboard
 copper port between him and his ISP - only able to obtain about 25mbit
 or so of throughput (all traffic NATed.)
 
 After moving the ISP link over to fibre, the throughput shot up to
 500-600mbit (NATed.)
 
 Theres not much room for playing around with the setup at this stage,
 but does anyone have any ideas why this might be so?
 
 The onboard ports are all gigabit as far as I know, whether or not you
 use copper or fibre, and the copper port augo negotiated at 100/full
 with the remote device so I cant think of a reason for the disparity.

And how was the fiber connected on the other end?

It looks like problem with the autonegotiation. Or maybe flow
control - is the remote device using fiber natively and going
to copper through some intermediate converter? Those can cause
such problems also.

We need way more info to get this through troubleshooting. Or maybe
they should involve TAC?

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Limitation on Cisco catalyst 3550 ?

[Łukasz Bromirski]

In terms of packet/sec you can either use storm control or, if I remember 
correctly, 3550 also had an option to do service-policy MQC construct that 
policed not to bits/s but pps.

In terms of flow - no, there's no microflow engine like in the 6500. The 
closest you can achieve is to limit number of TCP SYNs per second using MQC and 
ACL. This will be however generic construct, as not all sessions are TCP and it 
won't give you control over the number of sessions.

-- 
./

 On 16 Aug 2014, at 23:48, Olivier CALVANO o.calv...@gmail.com wrote:
 
 Hi
 
 anyone know if it's possible on a cisco catalyst 3550 to limit the number
 of packets/sec and flow a on specific port ?
 
 if the limit is reached the port goes into shutdown
 
 thanks
 olivier
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Strange corrupt DNS Cache in IOS

[Łukasz Bromirski]

Open a case with TAC. That's what they are for, right?

-- 
./

 On 15 Aug 2014, at 18:05, Sascha E. Pollok s...@iphh.net wrote:
 
 Frank, Jared,
 
 I understand your point and I even share it. Sometimes there are setups
 that do not make much sense any other way (this box with DNS server
 mainly serves one single device and no other DNS server around that is
 suitable for the job).
 
 And before I go ahead and try to deploy some other device for that
 purpose I simply wanted to see if I can make it work with what there is.
 
 Thanks
 Sascha
 
 Am 15.08.2014 16:46, schrieb Frank Bulk:
 Right, but that's all non-Cisco.  My comments were intended to be
 constrained to Cisco.  
 
 Frank
 
 -Original Message-
 From: Jared Mauch [mailto:ja...@puck.nether.net] 
 Sent: Friday, August 15, 2014 9:42 AM
 To: Frank Bulk
 Cc: Sascha E. Pollok; cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] Strange corrupt DNS Cache in IOS
 
 
 On Aug 15, 2014, at 10:34 AM, Frank Bulk frnk...@iname.com wrote:
 
 Don't use a router as a DNS resolver for customers.  Just don't.
 
 Or if you are, use something that is properly designed for that function.
 Check out the UBNT EdgeRouter stuff, cheap, vyatta (JunOS-like), and gives
 you shell access to do other more advanced stuff.  Basically, you can't lose
 at the unit cost, etc.
 
 - Jared
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Strange corrupt DNS Cache in IOS

[Łukasz Bromirski]

True. But each has it's own place :)

-- 
./

 On 15 Aug 2014, at 23:23, Jared Mauch ja...@puck.nether.net wrote:
 
 Can get more luck with voodoo dolls some days. 
 
 Jared Mauch
 
 On Aug 15, 2014, at 4:12 PM, Łukasz Bromirski luk...@bromirski.net wrote:
 
 Open a case with TAC. That's what they are for, right?
 
 -- 
 ./
 
 On 15 Aug 2014, at 18:05, Sascha E. Pollok s...@iphh.net wrote:
 
 Frank, Jared,
 
 I understand your point and I even share it. Sometimes there are setups
 that do not make much sense any other way (this box with DNS server
 mainly serves one single device and no other DNS server around that is
 suitable for the job).
 
 And before I go ahead and try to deploy some other device for that
 purpose I simply wanted to see if I can make it work with what there is.
 
 Thanks
 Sascha
 
 Am 15.08.2014 16:46, schrieb Frank Bulk:
 Right, but that's all non-Cisco.  My comments were intended to be
 constrained to Cisco.  
 
 Frank
 
 -Original Message-
 From: Jared Mauch [mailto:ja...@puck.nether.net] 
 Sent: Friday, August 15, 2014 9:42 AM
 To: Frank Bulk
 Cc: Sascha E. Pollok; cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] Strange corrupt DNS Cache in IOS
 
 
 On Aug 15, 2014, at 10:34 AM, Frank Bulk frnk...@iname.com wrote:
 
 Don't use a router as a DNS resolver for customers.  Just don't.
 
 Or if you are, use something that is properly designed for that function.
 Check out the UBNT EdgeRouter stuff, cheap, vyatta (JunOS-like), and gives
 you shell access to do other more advanced stuff.  Basically, you can't 
 lose
 at the unit cost, etc.
 
 - Jared
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] cisco GGSN tethering

[Łukasz Bromirski]

On 28 Jul 2014, at 11:43, nareshbtech--- via cisco-nsp 
cisco-nsp@puck.nether.net wrote:

 So that means 
 We have to upgrade our hardware 
 Can't the SAMI modules provide this feature 

No. But talk to your favorite Cisco account team. They may be able to
have a talk with you on virtualized ASR 5k.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Updated Portable Product Sheets - Routing Performance

[Łukasz Bromirski]

Hi,

On 22 Jun 2014, at 10:47, Skeeve Stevens 
skeeve+cisco...@eintellegonetworks.com wrote:

 Hi all,
 
 Does anyone know if Cisco is still maintaining Portal Product Sheets -
 Routing Performance at
 http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf

That was done mainly with focus on access platforms, Catalyst were
added there just for the sake of the moment… and no, I haven’t heard
anybody is updating this.

 I am looking for something that has all the ASR1k and ASR9k options.

For ASR 1k’s you’re looking for ESP performance, which is documented
here:
http://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/data_sheet_c78-450070.html

For ASR 9k’s such simple table doesn’t make any sense, as it’s
distributed platform and the numer of Mpps you’ll get is dependent
on the specific LCs.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Updated Portable Product Sheets - Routing Performance

[Łukasz Bromirski]

Sender: cisco-nsp-boun...@puck.nether.net
On-Behalf-Of: luk...@bromirski.net
Subject: Re: [c-nsp] Updated Portable Product Sheets - Routing Performance
Message-Id: ef1a5b32-aa32-4146-8073-542ebc30e...@bromirski.net
Recipient: adam.atkin...@damovo.com
Recipient: darren.coll...@damovo.com
---BeginMessage---
Hi,

On 22 Jun 2014, at 10:47, Skeeve Stevens 
skeeve+cisco...@eintellegonetworks.com wrote:

 Hi all,
 
 Does anyone know if Cisco is still maintaining Portal Product Sheets -
 Routing Performance at
 http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf

That was done mainly with focus on access platforms, Catalyst were
added there just for the sake of the moment… and no, I haven’t heard
anybody is updating this.

 I am looking for something that has all the ASR1k and ASR9k options.

For ASR 1k’s you’re looking for ESP performance, which is documented
here:
http://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/data_sheet_c78-450070.html

For ASR 9k’s such simple table doesn’t make any sense, as it’s
distributed platform and the numer of Mpps you’ll get is dependent
on the specific LCs.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/---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] ASR 1002-X as LNS

[Łukasz Bromirski]

Mike, James,

 On 04 Jun 2014, at 19:13, Mike mike-cisconspl...@tiedyenetworks.com wrote:
 
 On 06/04/2014 09:12 AM, James Bensley wrote:
 Hi All,
 
 I'm expecting some 1002-X's to tun up soon for deployment as LNS's.
 
 Does anyone have a working config they could send me (off list, minus
 sensitive details etc) so I have a base to work from?
 
 I'm new to both IOS XE and ASR's and whilst I have used ASRs with XE
 and all seems well so far, it would be very handy to have a basic
 config for an LNS to work from in case there is any major difference
 from the more traditional 7200 series LNS we're all used to using :)
 
 I second that - if anyone would post on the list it would be a great help.

Shameless plug - but it’s all Cisco material, unfortunately
in Polish. Configs seems universal though ;)

http://www.data.proidea.org.pl/plnog/7edycja/materialy/prezentacje/Krzysztof_Mazepa_Konfiguracja_uslug_szerokopasmowych_na_urzadzeniach_ASR1000.pdf

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Replacing 3750X stack

[Łukasz Bromirski]

Why you say Cisco doesn't see any longevity for 4500X?

4500X is here to stay, as part of 4500 family, which itself is also here to 
stay. Roadmap points far into future.

You can go ahead with 4500X deployments, or experiment with other metro 
platforms - ME3600/3800 or even 6880.

-- 
./

 On 2 maj 2014, at 02:20, CiscoNSP List cisconsp_l...@hotmail.com wrote:
 
 
 Hi,
 
 We have a 3750X stack (2 switches) doing pure L2 at a small POP (Acting as a 
 core switch) - The small buffers are causing a lot of performance issues, 
 so we are looking to upgrade them.
 
 We run pairs of 4500X's (In VSS) at some other POPs, and are quite happy with 
 them, but Cisco dont appear to see this platform as having any longevity?
 
 Hoping for some recommendations on replacement switch(es) for the 3750 - The 
 6800's look very nice, but Ive got no idea on price?  
 
 We are a small Service Provider, and primarily provide private 
 networks(VRF's) to customers - All L3 is currently done on 7200's and ASR1K's
 
 Cheers.
 
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco CGN question

[Łukasz Bromirski]

Pavel,

 On 25 kwi 2014, at 10:43, Pavel Dimow paveldi...@gmail.com wrote:
 
 Hi,
 
 Does CGN on ASR 1001 refers to NAT44 only or it can be used for statefull
 NAT64 also?

Yes, it can. Take a look here:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/asr1000/nat-xe-3s-asr1k-book/iadnat-stateful-nat64.html

-- 
Łukasz Bromirski
___
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 CGN question

[Łukasz Bromirski]

Pavel,

On 25 Apr 2014, at 14:07, Pavel Dimow paveldi...@gmail.com wrote:

 Hi Lukasz,
 
 I saw that, but I am confused with CGN terminology and license. 
 Cisco says I need separate license for CGN and separate license for NAT64, 
 yet they can't be used together.
 More over, they say you can have NAT 256000 sessions per box or you can have 
 50 CGN sessions.
 Can I buy CGN license and have 50 NAT64 sessions or CGN is NAT44 sessions 
 only?

Both licenses are RTU and interchangeable. The limits you’re about
to hit come from ESP scalability, not from license enforcement.

Who’s your Partner? I can make sure somebody from Cisco in your
country will help you in discussing the proper configuration
(I’m from Cisco and based in Poland).

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Sup2T interface ACL limitations

[Łukasz Bromirski]

On 20 Dec 2013, at 14:36, Phil Mayers p.may...@imperial.ac.uk wrote:

 On 16/12/13 14:26, Rolf Hanßen wrote:
 
 These are all pretty basic questions; you might want to re-read the docs
 a few times to get a better understanding.
 
 Unfortunatelly the docs only describe the theory.
 
 I wrote a long answer, but decided on a short one:
 
 Very large ACLs e.g. with 100k entries aren't that common. It's an odd thing 
 to do, IMHO, and you should speak to your Cisco account manager / SE to get 
 feedback from the platform team on the scale limits.
 Personally, I wouldn't do what you're doing - a 100k ACE ACL is just asking 
 for trouble.

Indeed. Even if something that huge will fit into hardware to not
compromise speed, it will be unmanageable (and on most platforms it
will not).

I’ve witnessed two or three customers that I was responsible for @Cisco,
that were at the 60-80k entries mark. They were essentially
(no pun intended) coming from Checkpoint land, where ACLs were tool
to do anything. All of them essentially said: we no longer can manage
this, we no longer can track this, we no longer know what’s going on,
please find us some solution. Heck, I saw RFPs asking for
500-600k ACEs in hardware! (someone haven’t done any market research).

If you need that kind of scale, go for BGP blackholing coupled with
uRPF, and you will a) use the things routers are best in (using their
FIB) and b) dynamically scale/manage the solution.

ACLs are good for basic sanity checks and segmenting the traffic for
ports (L4+). BGP scales way better for L3 than them and it’s faster
and way easier to dynamically update the entries.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] cheap core switch for a hacker space (nonprofit association)

[Łukasz Bromirski]

Markus,

On 10 Dec 2013, at 21:19, Markus H hauschild.mar...@gmail.com wrote:

 I have found a Cisco Catalyst 4948-S to be less expensive on ebay than two 
 3750G-24 (and both options are far cheaper than any
 Juniper EX on ebay).

4948 without letter ‘E’ at the end signifies a version based on the
older Supervisor design without hardware forwarding of IPv6.

You should definitely look at 4948E or newest 3650.

Also, being non-profit organization, you should work with the local
Cisco account team. They should be able to work on something special
in terms of discounts for that kind of organization. If you fail,
please write to me at lbromirski (@cisco.com), I’ll try to connect you
with proper people.

-- 
There's no sense in being precise when |   Łukasz Bromirski
you don't know what you're talking |  jid:lbromir...@jabber.org
about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] XRv (xr on a server)

[Łukasz Bromirski]

On 03 Oct 2013, at 17:12, Aaron aar...@gvtc.com wrote:

 VIRL sounds awesome.
 
 I saw in Cisco TAC Case Open Tool, under IOS XR...   XRv (XR on a server).
 XRv same as VIRL ?

VIRL is a platform for virtualized software packages.

vIOS, XRv, CSR 1000v and so on are examples of such packages.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] XRv (xr on a server)

[Łukasz Bromirski]

On 03 Oct 2013, at 17:18, quinn snyder snyd...@gmail.com wrote:

 On Oct 3, 2013, at 8:12, Aaron aar...@gvtc.com wrote:
 
 I saw in Cisco TAC Case Open Tool, under IOS XR...   XRv (XR on a server).
 XRv same as VIRL ?
 
 xrvr == xr within virl. 
 
 doesn't ncs run virtualized xr (xrv)?

Yes it does.

-- 
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASR1000 RP1 and BGP

[Łukasz Bromirski]

You're mistaking FIB for RIB. RIB will take whatever fits in available memory, 
usually way more than 1M of IPv4 routes. FIB is limited to 1M prefixes, but 
only bestpaths land here, so with number of full feeds you'll usually anyway 
land at around 460k of prefixes. Try to search in archives for a lot of details.

-- 
./

 On 6 wrz 2013, at 07:51, CiscoNSP List cisconsp_l...@hotmail.com wrote:
 
 
 Another question on the ASR1000 :)
 
 RP1 supports 1M IPv4 routes i.e. ~2 full tables...If you bring on a third 
 full table, will you see rib failure (memory) for all routes that exceed 1M? 
 (Assume yes?)
 
 How is the rib allocation calculated?  if you added(peered) 4 full tables 
 (sequentially, one after the other), would the bgp sessions after the 1st and 
 second be the ones that are rejected, and then it is based on route churn? 
 (So would routes from peer 3 and 4 be added during churn?)
 
 Cheers. 
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] asr1001 4 full bgp feed

[Łukasz Bromirski]

Yes, FIB only stores best paths (400k+), so you need to make sure you have at 
least 8GB of RAM and should be good to go.

On the other hand, having better ESP would make sense in terms of future 
growth, so take a look at ASR 1002X.

-- 
./

Dnia 1 sie 2013 o godz. 08:09 Hitesh Vinzoda vinzoda.hit...@gmail.com 
napisał(a):

 hi all,
 
 could anyone confirm if asr1001  can take 4 full bgp feed of 450k routes
 each.
 
 i know that it has limitation of 512k for fib but not sure  if thats for
 only forwarding table which i reckon would be all best routes around 450k
 but assuming that we can hold 1.4 million routes that is 450k from each
 peer in rib using more ram.
 
 please comment
 
 thanks
 Hitesh
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] multicast issue

[Łukasz Bromirski]

ASR 9000 has video monitoring capabilites built in. No need to use additional 
gear in most of the scenarios.

-- 
./

Dnia 17 lip 2013 o godz. 19:06 Thong Hawk Yen hawk.yen.th...@time.com.my 
napisał(a):

 Hi,
 
 Our version is video verifier which is specially design for IPTV.  I am not 
 sure if they have a version that do non-video multicast.
 You might want to have a look at their range of  product at their homepage at 
  http://www.exfo.com/
 
 Regards
 Amos Thong
 
 
 From: dim0sal [mailto:dim0...@hotmail.com]
 Sent: Wednesday, July 17, 2013 11:53 PM
 To: Thong Hawk Yen; cisco-nsp@puck.nether.net
 Subject: R: RE: [c-nsp] multicast issue
 
 Hi
 Is brixvision suitable also for not iptv mcast flows?
 We run financial market mcast flows. ..
 
 Tks
 
 
 
 Sent with Mobile
 
 
  Messaggio originale 
 Da: Thong Hawk Yen hawk.yen.th...@time.com.my
 Data:
 A: R S dim0...@hotmail.com,cisco-nsp@puck.nether.net
 Oggetto: RE: [c-nsp] multicast issue
 
 
 Hi,
 
 We run a BGP NG-MVPN for IPTV content delivery, with Juniper MX480 in the PE 
 layer and Cisco CRS in the P layer. With RSVP-TE P2MP LSP running from the 
 Sender PE ( which is connecting to the multicast upstream HE router ) to the 
 Receiver PE routers ( with downstream GPON IPTV subscribers ).
 
 We have BrixVision IPTV probes at the Sender PE router before the traffic 
 enter our MPLS cloud and the same type of probes at Receiver PE routers.
 So far there is no need for IPTV probes along the RSVP-TE P2MP LSP path. This 
 will help to determine the traffic quality in the IP/MPLS core.
 
 At the downstream we have STB probe aka Single Channel Probe from the same 
 brand deployed at the customer's place if there is a picture quality 
 complaint. This will help us to determine issue from receiver PE router 
 through the GPON networks towards the customer home.
 
 We had evaluated Ineoquest before, however we found Brixvision was more 
 suitable to our environment.
 
 In the early stage of deployment we kept our eye on the IAT and MLR on the 
 probe almost everyday. The Brixvision has very detail real time zoomed-in 
 analysis like TS Sync, PAT, CRC and etc per group.
 
 Hope this help.
 
 Regards
 Amos Thong
 
 -Original Message-
 From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of R S
 Sent: Wednesday, July 17, 2013 12:53 AM
 To: cisco-nsp@puck.nether.net
 Subject: [c-nsp] multicast issue
 
 Hi all
 
 Just a brainstorming and your possible help.
 
 
 I manage a network where multicast is the most important traffic and
 sometimes I get issue by customer where they state that some packets are 
 lost...
 
 
 Does anybody have an idea or can help me in understanding a possible
 solution in monitoring traffic in real time manner, maybe with the use of some
 software or appliance or whatelse.
 
 In my idea I could monitor traffic on the source and on the destination,
 then with  a sort of parsing understand
 if it's my network loosing the packets or not...
 
 
 
 Any idea ? suggestion ?
 
 
 tks
 ___
 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/
 
 
 
 CONFIDENTIALITY
 -
 The contents of and any attachments to this email are private and 
 confidential. If you are not the intended recipient or addressee indicated in 
 this message, please notify the sender of the error and destroy the email and 
 any attachments. Please do not reproduce the contents of the email or its 
 attachments as such reproduction is a breach of confidentiality and for which 
 legal action including injunctive relief may be sought against you. If it is 
 your company policy that official communications are not by email, please 
 advise immediately. Any opinions, conclusions and other information in this 
 message that do not relate to the official business of TIME dotCom shall be 
 understood as neither given nor endorsed by TIME dotCom, nor shall TIME 
 dotCom shall be liable (directly or vicariously) for such opinions, 
 statements or communications.
 
 
 
 CONFIDENTIALITY
 -
 The contents of and any attachments to this email are private and 
 confidential. If you are not the intended recipient or addressee indicated in 
 this message, please notify the sender of the error and destroy the email and 
 any attachments. Please do not reproduce the contents of the email or its 
 attachments as such reproduction is a breach of confidentiality and for which 
 legal action including injunctive relief may be sought against you. If it is 
 your company policy that official communications are not by email, please 
 advise immediately. Any opinions, conclusions and other information in this 
 message that do not relate to the official business of TIME dotCom 

Re: [c-nsp] acl on bvi in ios xr (9k) 4.1.2

[Łukasz Bromirski]

On 7/20/12 1:08 PM, Gert Doering wrote:


On Thu, Jul 19, 2012 at 02:58:58PM -0400, Jared Mauch wrote:

I think my point is..  If you are buying an asr9k
you can likely afford an ethernet switch vs using an
expensive router port.

Sometimes BVI are the poor man's multi-chassis etherchannel to
get redundant links to downstream switches...


On ASR9k you can configure MC-LAG, which is present for that kind of
scenarios, and you don't need to use BVI to build some tricky
workarounds.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] global.xls?

[Łukasz Bromirski]

On 7/18/12 10:08 PM, Nick Hilliard wrote:


It was much better when this information used to be available easily.
Please fix this, Cisco.  You didn't need to break it in the first place.


It's hard to fix something, that's not broken.

Cisco sells through Partners. Part of the money Partners make is
their own set of pricing which they're freely to define. Some decide
to rise the pricing of the parts, and lower the pricing of the service,
some decide they'll offer you a price from the pricing list and the
service separately - but it's Partner choice how they want to conduct
business and Cisco commitment to letting Partner protect the investment
he made in the training, services and so on in the way Partner chooses
to do.

As soon as you're so big, that your internal team is autonomous in
terms of logistics, integration, installation and maintenance, your
level of orders with Cisco will propably anyway give you an option to
ask for direct contract, with access to the pricing list and some
other benefits.

That's fundamental difference from other networking vendors, in the way
Cisco operates. Most of the competitors follow similar path, realizing
pros of scaling the operation world-wide through Partner network and
most of them also don't share publicly the pricing list.

Simple as that.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7600 w/ WS-SUP720-3B IOS 15.x

[Łukasz Bromirski]

On 7/1/12 3:25 PM, Asbjorn Hojmark - Lists wrote:

On Sun, 1 Jul 2012 11:00:40 +0200, you wrote:


Numer of trains is limited, development is more focused, and
the code reuse is progressing.



12.2SX next, please :-)



That's 15.0 SY



Well, I was asking for SX-for-6500 (SXI, SXJ), not whatever else
might be using an IOS called 12.2SX.


15.0 SY *is* for the 6500.


Yep, Asbjorn has it right. 15.0SY is the current line, and 12.2SX is
going out. The roadmap for 15.0SY, and where things converge is still
lurking somewhere in the dark. The 6500 architecture session on the
recent Cisco Live covered this in some detail.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7600 w/ WS-SUP720-3B IOS 15.x

[Łukasz Bromirski]

On 6/30/12 11:41 AM, Gert Doering wrote:

Hi,

On Sat, Jun 30, 2012 at 01:31:41AM +0200, ?ukasz Bromirski wrote:

15.1S is the same train, save for hardware-dependent features.


That's good news.  What I heard was more like 15.1S is just a relabeled
12.2SRE and has not much relationship to 15.0/15.1.


That's more complicated. 12.2SR code went into the common train
that became 15.xS. Some features:


OTOH since 15.1M is still missing features that 12.2SX/12.2SR have, it
would be interesting to see where those features went regarding 15.1S
(like: IPv6 HSRP with global unicast address)...


...are still being synchronized to this tree. That was about the same
time when IOS-XE was split, and many different changes did happen in
Cisco.

I could fill a whole slot on the PLNOG/EURONOG/SWINOG/NANOG just
touching the very basics of what's there and what's not currently, but
the progress you see on the receiving end should be already visible.

Numer of trains is limited, development is more focused, and the
code reuse is progressing.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7600 w/ WS-SUP720-3B IOS 15.x

[Łukasz Bromirski]

On 6/30/12 8:48 AM, Doug McIntyre wrote:


I think the main point was that 12.2 came out, then 12.4 came out, 12.4T,etc.
and then 12.2S came out.


Yep, as 12.2S is build using 12.0S as base, and just syncing up
changes/progress made in the newer trees.


Which is different than on the switches, which stuck in 12.1 for the
longest time, and it is current in the switches to be 12.2, until of
course everything was synced back into 15.x again.


Yes, and that again was made as a number of changes went into effect,
including launch of couple of new platforms. Some of which are based
on IOS-XE.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7600 w/ WS-SUP720-3B IOS 15.x

[Łukasz Bromirski]

On 6/29/12 10:09 AM, Gert Doering wrote:


Always keep in mind that this is 15.1*S*, not 15.1 - completely different
IOS train.


Yes.


(Though I'm wondering how 15.1S-for-7600 and 15.1S-for-others relate...
IOS trains, feature distribution and hardware support is more cloudy than
ever)


15.1S is the same train, save for hardware-dependent features.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 7600 w/ WS-SUP720-3B IOS 15.x

[Łukasz Bromirski]

On 6/30/12 1:24 AM, N. Max Pierson wrote:


I think that for simplification purposes, Cisco has somewhat taken the
confusion out of what the 'latest' train would be for any device running
run IOS. Now it's simply 15.x/insert variable for hardware here/. I think
they went real awry with the 7200 having 12.4(M/T) and 12.2(SRx) which
really confused folks in regards to feature set. Not necessary IMHO.


M/T were enterprise feature sets, where anything with 'S' meant
Service Provider. For the CPU-driven platforms and 7600 it is still
the case.


I've never really understood the 7600 either in regards to the hardware
part (I'm a router, I'm a switch ... Pat from SNL anyone :)


It's a router, with switch LCs unless you're equipped with ES/ES+/SIP
linecards. Starting from Sup2T it's router even with traditional LCs,
as VLAN interfaces were coupled with the logical interface ID, and
that effectively provided VLAN independence per-port.


Hopefully we'll be retiring this pair of 7600's soon in exchange for 7k's.


All I want for Christmas is multi-chassis CRS-3 :D

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ASR9000/RSP440 Console Issue

[Łukasz Bromirski]

While I'm sure you're right and I fully concur with the separate
CMP being an option, a couple of feedback and observations I've
gathered from some time spent as a Cisco filed sales guy:

On 6/15/12 1:16 PM, Benny Amorsen wrote:


IMHO no switch or router should have management access enabled on an
interface which can be configured to pass non-management traffic.


Some customers actually dropped Cisco offering and went with the
competition, when they've learnt, that the management traffic is for
MANAGEMENT only. It can't pass the user traffic.

I saw customer dropping our 4900M after learning the FE0 management
can't be used to route it's default route to the internet for the
rest of multi-10GE customers. True story as they say. No amount
of education at this point can make him change his mind.

You'll hit customers saying it's needed, and those saying it's
forbidden.


Absolutely. RS232 is not quite useless, but it is far from a proper OOB
management solution.


Again, the same story. We won't ditch our console servers! is very
often confronted with the Only proper OOB is Ethernet OOB!. Hard
to judge if you're trying to sell to everyone :)

Somebody said it costs 80$ to add CMP CPU, and it's not that simple.
While the cost of the part itself propably is even cheaper, when you
add additional PCB space, connections, heating requirements,
enviromental requirements, MTBF numbers and so on, you end up with
the cost of the board higher. LJ Wobker spoken recently at NANOG,
and while his talk was more about power dillemas of modern router
architectures, it's worth to note the reality.

But don't get me wrong - I'm for the true CMPs on the RP boards,
be it a combo of RS+Ethernet.


Do the Cisco servers have proper OOB management? If so, can they send a
few people from the various other business units on a field trip to the
server guys?


Truth is, a lot of wisdom is shared between BU, trust me. Simply
speaking, feedback we receive from various customers usually doesn't
add up to a single, best-of-the-breed solution. Sometimes the
requirements can't be fulfilled at the same time.

Some of you don't see a need for separate CMP. Some of you do. It's
a matter of talking to your account team, and as somewhat noted on
this list already a number of times (Mark? Gert?) you need to vote
with your money.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] VS-S720-10G (6509 VSS Engine) 10G Port Issue

[Łukasz Bromirski]

On 2012-06-13 05:55, Pete Templin wrote:

On 6/12/12 11:06 AM, Łukasz Bromirski wrote:


In reality, Sup720-10GE sold with the VS prefix is a
perfectly normal Supervisor. What is changed is that the
fabric matrix is actually 20x20Gbit/s not 18x20Gbit/s, so
you get additional 2 channels for 20Gbit/s.


Oh, is that for the 6511 chassis?


6511? Never heard about it.


18x20Gbit/s means 2x20Gbit/s per slot * 9 slots, so the Supervisor slots
already have 2x20Gbit/s feeding them to drive the front-panel ports.

 Why would they need a 19th or 20th channel?

To drive the uplink (2x10GE) at full speed without oversubscription,
as those are VSL links.

In old Sup720 design, the Supervisor itself is connected to the
fabric using one channel. This channel is used by Hyperion ASIC
to provide for bus interface, and multicast/SPAN features. Because
there's no other way to connect the uplinks on the Sup itself, the
Hyperion has it's interface also terminating the uplinks (2xGE)
thus limiting effective throughput/etc. BTW, both PFC and MSFC
are also connected to the rest of the chassis linecards by Hyperion
(PFC) and Pinnacle (MSFC).

On the Sup720-10GE, the separate, 19th channel is used to connect
the uplinks directly into fabric. Hyperion is still there, it still
takes the channel belonging to the slot which Supervisor itself
is in, but thanks to such design doesn't limit in any way
performance you can achieve on the 2x10GE uplinks (or 4xGE). In
the new design, Hyperion takes care of providing connectivity to MSFC3
complex, while Metropolis (ASIC terminating the uplinks and connected
to fabric) takes care of providing transport to PFC3C/CXL.

The 20th channel is used in the same fashion for the redundant
Sup if it's inserted into chassis.

Hope that clears it a bit.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] VS-S720-10G (6509 VSS Engine) 10G Port Issue

[Łukasz Bromirski]

On 2012-06-12 16:28, Xu Hu wrote:


We bought VS-S720-10G engine for VSS in 6509, but now the customer don't
want use the VSS mode, they just want to use that as normal engine.
So now we are wondering if we use the 10G port for normal Layer2 or Layer3
traffic, will it impact our engine performance or CPU utilization? Is there
any detail document talking about this?


In reality, Sup720-10GE sold with the VS prefix is a
perfectly normal Supervisor. What is changed is that the
fabric matrix is actually 20x20Gbit/s not 18x20Gbit/s, so
you get additional 2 channels for 20Gbit/s.

The 19th fabric channel drives the uplink on the active Sup
and the 20th fabric channel drives the uplinks on the standby
Sup.

The bonus features for VSS among other things come from
the next-gen PFC card, PFC3C or PFC3CXL.

In terms of L2/L3 traffic processing, the job is always at
hand of PFC on the Supervisor, or the DFCs on the linecards.

The uplink ports on the Supervisor itself are serviced by
the PFC on the Supervisor itself, with the upper limit being
48Mpps for the PFC3.


If ok, then by default, each engine will have two X2 port, so totally we
will have four 10G port to use as normal data transmission?


Yes, and it's indeed default config when you get the VS-SUP720
from the factory - it's just a standalone Supervisor.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Cisco Crashinfo file

[Łukasz Bromirski]

On 2012-05-01 09:24, bha Qaqish wrote:

Dear
Am having router with crashinfo file .
I opened the file and its big.
How can I analyze the file , and is there any software for it


Open a case with Cisco TAC. They have tools to assist in pointing to
the root cause of the crash.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Network performance question - TCP Window issue?

[Łukasz Bromirski]

On 2012-04-29 19:57, John Neiberger wrote:

The timing of this is coincidental. I've been helping to troubleshoot
a similar problem at work for days. Let's say we have three servers,
A, B and C. We transfer files between them and here is what we see:

A to B: Fast (around 18 MB/s)
B to A: Slow (around 1 MB/s)
A to C: Slow (around 1MB/s)
C to A: Fast (around 18MB/s)

In our case, Server A is fast when sending to B but not when sending
to C. C can send at a high speed when sending back to A, though.


Typical problems with the different speed depending on the direction
are caused either by duplex mismatch at access port (test, don't
trust what one side tells you!) or problems with negotiating the
TCP windows size (depending on the TCP/IP stack, application and tool
you may get a number of different results).

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] OSPFv3 in a VRF on a 7600

[Łukasz Bromirski]

On 2012-04-10 12:47, Benny Amorsen wrote:

Is it possible to run OSPFv3 in a VRF on a 7600? I cannot for the life
of me figure it out from the documentation, and the obvious commands
like ipv6 router ospf 123 vrf whatever do not work at least on SRC4.


Actually, it should work with the just released 15.2(2)S image.

Unfortunately, the configuration guide is not yet linked in, just
a command reference:

http://www.cisco.com/en/US/docs/ios/15_2s/release/notes/15_2s_feats_important_notes_15_2_2s.html

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Embedded hash not found

[Łukasz Bromirski]

On 2012-04-05 23:27, Brault, Ryan wrote:

I ran into the same thing a few weeks back with the same hardware,

 same version, different feature-set - 1841, 12.4(25f), IP Base.
 I figured it was corrupt as well.  Verified file size, MD5, etc.
 All checked out except the embedded hash.  Reloaded the box and
 all is well.

The reason for such behavior is simply a bug. Not going into details,
the function printing the message doesn't always do it's job right,
because of various dependencies.

In the 12.4/12.4T images it surfaced in different versions of
the code.

It was fixed in 12.4T train in 12.4(15)T17. It can also be found in
12.2SX and 12.2SR images, but again was fixed in 12.2(33)SXI and
12.2(33)SRD6 respectively.

If the MD5 hash matches the one on CCO - you're on the right track.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] WS-X6704-10GE, WS-X6708-10GE

[Łukasz Bromirski]

On 2012-03-05 14:10, tao wrote:


Both 6704 and 6708 have two complex of Fabric ASICs.
The 6708 you can see on figure 21 here:

http://www.cisco.com/en/US/__prod/collateral/switches/__ps5718/ps708/prod_white___paper0900aecd80673385.html

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html

suppose there are port A and port B belong to fabric channel 1 and port C
belongs to fabric channel 2.

how does traffic pass from port A to port B  with/without DFC ?


It goes up to the Port ASIC. CFC requests decision to be taken by
a PFC on the Supervisor and DFC can take the decision locally. It
is then looped back to port B. The CFC communication takes place
over the shared bus which is limiting factor for packets per second
(on each of it the CFC has to query PFC for decision). The limit
for such system is 15 or 30Mpps. The limit for DFC system is
48Mpps per linecard.


and any difference for traffic passing from port A to port C ?


Yes, the CFC/DFC decision process will be the same, but the
traffic will leave the LC using channel 1, and then come back
to the LC using channel 2 to leave out of port C.


  I am wondering whether the traffic pass through switch fabric ? Is switch
fabric a passive component?


Passive in what sense? It doesn't do any network operations as is,
but it's powered up and processing traffic by means of frames +
additional headers. Switch fabric physically is a either a compex of,
or in the newer versions, single pretty large ASIC on the Supervisor
under the heatsink.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] WS-X6704-10GE, WS-X6708-10GE

[Łukasz Bromirski]

On 2012-03-02 09:13, Artyom Viklenko wrote:


I'm tring to clarify my understanding of switching paths on these
line cards. From one point of view, Cisco docs says that if the
traffic should ingress via one port on the line card and then
should egress through another port on the same line card it will
never leave this line card. So it will be switched via internal
bus. Right?


No, and if it says so somewhere, please point it to the doc team
to fix it.

Both 6704 and 6708 have two complex of Fabric ASICs.
The 6708 you can see on figure 21 here:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html

The port mappings for Fabric ASICs should be found in the hardware
installation notes under the 'Switch fabric connections' in the
tables for specific LC:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Module_Installation/Mod_Install_Guide/02ethern.html#wp1048010

Essentially, traffic from one Fabric ASIC to the ports on the
other Fabric ASIC will go over the fabric itself. Only traffic
belonging the the same Fabric ASIC will be switched locally if of
course there's a DFC installed.

--
There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about.   John von Neumann |http://lukasz.bromirski.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/