, CCIE #18473 (RS)
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-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.
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
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
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
BGP
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 rdobb...@arbor.net // http://www.arbornetworks.com
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 wars,
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 MSTP.
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
---
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
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 work
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
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
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
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
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 at
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.
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
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
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
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
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 caveats
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
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
SNIP
XL or non-XL has nothing to do with the number
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 a full BGP Table
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 chassis
Hi,
On Thu, Jun 11
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 routes.
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
Once upon a time, Gert Doering g...@greenie.muc.de 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
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
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
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
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
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).
34 matches
Mail list logo
