Re: [c-nsp] full routing table / provider-class chassis

On Jun 18, 2009, at 6:04 PM, Roland Dobbins wrote: Because those are intended to be deployed as coreward-facing cards, they aren't optimized for edge features like NetFlow, uRPF, and ACLs. To clarify, I mean these cards are for use in core routers only - edge routers need the features on t

Re: [c-nsp] full routing table / provider-class chassis

On Jun 18, 2009, at 5:48 PM, Antonio Soares wrote: Why are you not including E4 or E4+ ? Because those are intended to be deployed as coreward-facing cards, they aren't optimized for edge features like NetFlow, uRPF, and ACLs. --

Re: [c-nsp] full routing table / provider-class chassis

nio Soares, CCIE #18473 (R&S) amsoa...@netcabo.pt -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Roland Dobbins Sent: quinta-feira, 18 de Junho de 2009 1:55 To: Cisco-nsp Subject: Re: [c-nsp] full routing table / provider

Re: [c-nsp] full routing table / provider-class chassis

On Jun 18, 2009, at 6:59 AM, Jo Rhett wrote: I'd prefer something that can handle both edge and core duties. GSR w/E3 or E5 LCs, CRS-1, or ASR 1K. --- Roland Dobbins // Unfortunately,

Re: [c-nsp] full routing table / provider-class chassis

> > We don't have core and edge -- our switches do both. Every port on > the switch is either a BGP peer/uplink/downlink or a > customer. Every port layer3-routed with only a few handfuls > of customers with dual links. > > Purchasing a switch to be the edge and then another to handle > B

Re: [c-nsp] full routing table / provider-class chassis

On Jun 15, 2009, at 11:29 AM, Kevin Graham wrote: Given the 192 ports of 10/100/1000, presumably this is aggregating customers, in which case it'd be best to roll these up on 7600/RSP720 (along with their associated BGP, since most of them would probably be suitable for peer-groups). uRPF w

Re: [c-nsp] full routing table / provider-class chassis

On Jun 16, 2009, at 1:48 AM, Kevin Graham wrote: "ready to fall over at 150kpps" is only right if traffic is being entirely software switched on the MSFC3. Concur. I'd start here: sh proc c sort | e 0.00 sh fm sum --- Ro

Re: [c-nsp] full routing table / provider-class chassis

> Hah, keep drinking the cool aid! I have a pair of 6500s ready to fall > over at about 150kpps. All WS-67xx LAN cards with DFCs. CPU averages > 60% and often maxes. > > No netflow, no uRPF, no multicast, no IPv6, no BFD, no MPLS, no ACLs > in the forwarding plane. Very basic OSPF, BGP, and M

Re: [c-nsp] full routing table / provider-class chassis

> > Was the original intention of this thread not to find out exactly what *is* > the best tool for the above scenario? :) > > GSR w/E3 or E5 LCs, ASR 1K, CRS-1, or N7K, depending upon the circumstances Probably none of them -- N7K seems squarely targeted at enterprise DC, so given BU turf wa

Re: [c-nsp] full routing table / provider-class chassis

On 2009-06-13 13:23, Łukasz Bromirski wrote: It should 'fall over' It *shouldn't* of course. My bad :) -- "Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net _

Re: [c-nsp] full routing table / provider-class chassis

On 2009-06-12 17:42, Kevin Loch wrote: A 6509 should not "fall over without DFC's" unless you are doing more than 30mpps. That is 15gbit/s of 64 byte packets or 360gbit/s of 1500 byte packets. It should 'fall over' even if the traffic will rise, and there won't be enough PFC Mpps to do the wor

Re: [c-nsp] full routing table / provider-class chassis

On 2009-06-12 22:52, Ross Vandegrift wrote: No netflow, no uRPF, no multicast, no IPv6, no BFD, no MPLS, no ACLs in the forwarding plane. Very basic OSPF, BGP, and MSTP. About 2000 VLANs, 80% of which have associated layer 3 SVIs. Something is killing the CPU with that config though, just as

Re: [c-nsp] full routing table / provider-class chassis

Now, let's stop talking about non-DFC cards and start talking about equipment which can handle uRPF on every port, full Netflow analysis of up to 8 ports at a time, every port layer 3, every port filtered, colo facility core/peering. On Jun 12, 2009, at 3:03 PM, Peter Rathlev wrote: If this is

Re: [c-nsp] full routing table / provider-class chassis

On Jun 13, 2009, at 9:27 AM, Tom Lanyon wrote: Was the original intention of this thread not to find out exactly what *is* the best tool for the above scenario? :) GSR w/E3 or E5 LCs, ASR 1K, CRS-1, or N7K, depending upon the circumstances (note initial FIB-size limitation on N7K; I don't

Re: [c-nsp] full routing table / provider-class chassis

On Jun 13, 2009, at 3:52 AM, Ross Vandegrift wrote: I have a pair of 6500s ready to fall over at about 150kpps. It sounds as if you've a lot of stuff being punted, which should bear further investigation. --- Roland Dob

Re: [c-nsp] full routing table / provider-class chassis

On 13/06/2009, at 7:33 AM, Peter Rathlev wrote: Now, let's stop talking about non-DFC cards and start talking about equipment which can handle uRPF on every port, full Netflow analysis of up to 8 ports at a time, every port layer 3, every port filtered, colo facility core/peering. If this is t

Re: [c-nsp] full routing table / provider-class chassis

On Fri, 2009-06-12 at 12:58 -0700, Jo Rhett wrote: > Now let's talk about reality: 1/10 inbound/outbound ratios, 5% of > received traffic is Internet cruft requiring (wasted) TCAM lookups, > etc and such forth than any provider peering router observes, and > you're down to a much lower ratio.

Re: [c-nsp] full routing table / provider-class chassis

On Fri, Jun 12, 2009 at 11:42:45AM -0400, Kevin Loch wrote: > A 6509 should not "fall over without DFC's" unless you are doing more > than 30mpps. That is 15gbit/s of 64 byte packets or 360gbit/s of > 1500 byte packets. Hah, keep drinking the cool aid! I have a pair of 6500s ready to fall over a

Re: [c-nsp] full routing table / provider-class chassis

On Jun 12, 2009, at 8:42 AM, Kevin Loch wrote: Łukasz has already addressed this; suffice to say he's right, and the above is not correct. A TCAM lookup *is* the forwarding operation, and the DFC has all information required locally to switch the packet (via the fabric) to the output linecar

Re: [c-nsp] full routing table / provider-class chassis

Phil Mayers wrote: Kevin Loch wrote: Unfortunately, Cisco's partners are useless. They propose 6509s without the DFCs, which we know will fall over. Well that depends... The DFC's only do next-hop (tcam) lookups and netflow. All packets are switched on the centralized PFC. Each line c

Re: [c-nsp] full routing table / provider-class chassis

On 2009-06-11 21:01, Phil Mayers wrote: I would avoid the sup720, the rsp720 has 2x the ram and more Obviously it's worth emphasising that the RSP720 is 7600-only, and from posts on this list it's still not in general availability I think? True, the RSP is 7600-only, but only the RSP720-10GE

Re: [c-nsp] full routing table / provider-class chassis

Kevin Loch wrote: Unfortunately, Cisco's partners are useless. They propose 6509s without the DFCs, which we know will fall over. Well that depends... The DFC's only do next-hop (tcam) lookups and netflow. All packets are switched on the centralized PFC. Each line card has two 20Gbit/s

Re: [c-nsp] full routing table / provider-class chassis

On 2009-06-11 18:40, Kevin Loch wrote: You've got something messed up Kevin: The DFC's only do next-hop (tcam) lookups and netflow. DFCs are doing all and exactly the same work as PFC on Supervisors locally on the LC that they are installed to. They're the same in terms of hardware, just in a

Re: [c-nsp] full routing table / provider-class chassis

Jo Rhett wrote: I've been trying to spec Cisco for an upgrade of our Force10 backbone for nearly 2 months now. I'm just trying to clarify which platform Cisco recommends for full routing table/hardware forwarding/provider-class environments. Unfortunately every time I get through to the supp

Re: [c-nsp] full routing table / provider-class chassis

Once upon a time, Gert Doering said: > As far as I understand, Juniper handles this a bit different, with no > separate tables for "inside BGP" stuff, so things might look different > there. Juniper JUNOS keeps all routes (static, OSPF, BGP, etc.) in the "route table" in the routing engine (where

Re: [c-nsp] full routing table / provider-class chassis (Roland Dobbins)

On Jun 11, 2009, at 9:22 PM, Jeff Bacon wrote: Is there a good list of these caveats somewhere I can look at? NetFlow: 256K mls tables at 93% efficiency (~233K entries). No packet-sampled control of flow creation can lead to mls table overflow & non-deterministic skewing of stats/heuristi

Re: [c-nsp] full routing table / provider-class chassis

Hi, On Thu, Jun 11, 2009 at 05:17:01PM +0200, Gert Doering wrote: > > Are you saying that the limit on the number of routes, is actually in > > the FIB, ie active routes, so currently would always be about 280k, and > > multiple full tables is OK. > > BGP paths that don't go to the FIB are not

Re: [c-nsp] full routing table / provider-class chassis

Thanks Gert, excellent answer. > -Original Message- > From: Gert Doering [mailto:g...@greenie.muc.de] > Sent: 11 June 2009 16:17 > To: Ian MacKinnon > Cc: Gert Doering; Jo Rhett; cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] full routing table / provider-class chas

Re: [c-nsp] full routing table / provider-class chassis

Hi, On Thu, Jun 11, 2009 at 03:57:11PM +0100, Ian MacKinnon wrote: > > "XL" or "non-XL" has nothing to do with the number of *peers*. > > > > "XL" decides on the number of prefixes that you can have in your > > forwarding table (hardware FIB) - and this will be about the same for > > "1 peer with

Re: [c-nsp] full routing table / provider-class chassis

Hi Gert, > -Original Message- > From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- > boun...@puck.nether.net] On Behalf Of Gert Doering > Sent: 11 June 2009 14:41 > To: Jo Rhett > Cc: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp > "XL" or "non-XL" has nothing to do with the n

Re: [c-nsp] full routing table / provider-class chassis

Hi, On Wed, Jun 10, 2009 at 05:58:04PM -0700, Jo Rhett wrote: > Unfortunately, Cisco's partners are useless. They propose 6509s > without the DFCs, which we know will fall over. Whether or not you need DFCs really depends on the throughput on the box, and the features used. DFCs are good d

Re: [c-nsp] full routing table / provider-class chassis (Roland Dobbins)

> On Jun 11, 2009, at 7:58 AM, Jo Rhett wrote: > > > What are people using today for this kind of environment? > > GSR, ASR 1K, CRS-1 all work quite well. > > Avoid 6500/7600 for edge applications due to NetFlow, uRPF, & ACL > caveats (they're fine in the core). Is there a good list of these ca

Re: [c-nsp] full routing table / provider-class chassis

On Jun 11, 2009, at 7:58 AM, Jo Rhett wrote: What are people using today for this kind of environment? GSR, ASR 1K, CRS-1 all work quite well. Avoid 6500/7600 for edge applications due to NetFlow, uRPF, & ACL caveats (they're fine in the core). ---

[c-nsp] full routing table / provider-class chassis

I've been trying to spec Cisco for an upgrade of our Force10 backbone for nearly 2 months now. I'm just trying to clarify which platform Cisco recommends for full routing table/hardware forwarding/provider- class environments. Unfortunately every time I get through to the supposed right gro

Re: [c-nsp] full routing table

Alex Howells wrote: >>> Thanks guys :) Was just pondering whether a Catalyst 4948 would be good >>> enough for deployment with two partial feeds, as 76xx series is somewhat >>> expensive for that particular project! >>> >>> Guessing the FIB on it will be the limiting factor. >> Very very partial f

Re: [c-nsp] full routing table

>> >> Thanks guys :) Was just pondering whether a Catalyst 4948 would be good >> enough for deployment with two partial feeds, as 76xx series is somewhat >> expensive for that particular project! >> >> Guessing the FIB on it will be the limiting factor. > > Very very partial feeds. The 4948 is l

Re: [c-nsp] full routing table

Alex Howells wrote: > Deepak Jain wrote: >>> For lower-end platforms like ISRs, You could go with 384MB. However >>> 512MB is really recommended for things like soft-reconfig/etc. >>> >>> For higher-end platforms, the platform itself won't propably just >>> "do full BGP" so Your mileage may vary wi

Re: [c-nsp] full routing table

Deepak Jain wrote: >> For lower-end platforms like ISRs, You could go with 384MB. However >> 512MB is really recommended for things like soft-reconfig/etc. >> >> For higher-end platforms, the platform itself won't propably just >> "do full BGP" so Your mileage may vary wildly. >> >> Think "512MB or

Re: [c-nsp] full routing table

> > For lower-end platforms like ISRs, You could go with 384MB. However > 512MB is really recommended for things like soft-reconfig/etc. > > For higher-end platforms, the platform itself won't propably just > "do full BGP" so Your mileage may vary wildly. > > Think "512MB or more" for safe sleep

Re: [c-nsp] full routing table

[EMAIL PROTECTED] (Alex Howells) wrote: > Quick question since my Google-fu is failing me: what's the DRAM > requirement to take a full routing table from a provider these days? That would depend on your architecture. My SUP720-3B has it this way: rt#sh ip bgp summary BGP router identifier xx.xx

Re: [c-nsp] full routing table

Alex Howells wrote: > Quick question since my Google-fu is failing me: what's the DRAM > requirement to take a full routing table from a provider these days? For lower-end platforms like ISRs, You could go with 384MB. However 512MB is really recommended for things like soft-reconfig/etc. For high

[c-nsp] full routing table

Quick question since my Google-fu is failing me: what's the DRAM requirement to take a full routing table from a provider these days? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http: