No. You need to research lan qos. That card is a LAN card.
On Mar 26, 2011 6:56 PM, "Peter Olsson" wrote:
> We usually use this QoS config to give voice traffic priority:
> class-map match-all VOICE
> match ip dscp ef
> policy-map BRANCH-WAN-EDGE_child
> class VOICE
> priority percent 10
> class
Hi,
On Sat, Mar 26, 2011 at 03:51:02PM -0400, ML wrote:
> If the Host under attack doesn't have a gateway and is dependent on
> proxy ARP then it would be possible for the CAM to overflow.
That would be such a serious misconfiguration that all ensuring pain
is well-deserved.
Agreeing with
We usually use this QoS config to give voice traffic priority:
class-map match-all VOICE
match ip dscp ef
policy-map BRANCH-WAN-EDGE_child
class VOICE
priority percent 10
class class-default
fair-queue
random-detect dscp-based
policy-map BRANCH-WAN-EDGE_parent
class class-default
shape
Hi,
On Sat, Mar 26, 2011 at 03:51:02PM -0400, ML wrote:
> If the Host under attack doesn't have a gateway and is dependent on
> proxy ARP then it would be possible for the CAM to overflow.
That would be such a serious misconfiguration that all ensuring pain
is well-deserved.
gert
--
USENET is
On 3/26/2011 9:08 AM, Jeroen van Ingen wrote:
> Assuming the DoS attack is routed traffic (since it's in netflow) it
> won't cause overflows in L2 forwarding table CAM.
Unless there's a layer2 device downstream from the router.
Not even then. Layer 2 source/dest addresses are rewritten on eve
DFC is optional on CEF256 cards. CEF256 is just a family name. The
"dCEF" under CEF mode indicates whether it's doing central or
distributed (d = distributed, ie, DFC).
sh module will clearly tell you whether a DFC is present or not,
under the Sub-Module heading.
Tim
At 12:22 PM 3/26/2011,
My bad. Somehow I've got the impression only 67xx using DFC.
On Sat, Mar 26, 2011 at 8:32 PM, Tim Stevenson wrote:
> DFC is optional on CEF256 cards. CEF256 is just a family name. The "dCEF"
> under CEF mode indicates whether it's doing central or distributed (d =
> distributed, ie, DFC).
>
> sh
disregard =)
On Sat, Mar 26, 2011 at 8:22 PM, Andriy Bilous wrote:
> As far as I'm aware there is no DFC in 6516, it's a "legacy" card with
> a single 8Gb (duplex) connection to the fabric. Your output actually
> confirms that, saying CEF256. Are there any other modules in the
> chassis?
>
> On S
Hi Jeff,
Removing the DFC from a 65xx card & letting the PFC do the work is
HIGHLY preferable to letting traffic punt for your shortest mask
prefixes, which are the ones that won't get into the h/w if you blow
out the FIB TCAM.
In order of preference:
* get an XL DFC, list price on a DFC3CXL
Hi,
On Sat, Mar 26, 2011 at 03:05:13PM -0400, Jeff Kell wrote:
> > If you're not doing that much traffic, is removing the DFC from the
> > WS-X6516-GBIC an option?
>
> I don't know, that's why I'm asking, but if that's a viable option, will
> certainly give it a try.
Well, it will fall back to c
As far as I'm aware there is no DFC in 6516, it's a "legacy" card with
a single 8Gb (duplex) connection to the fabric. Your output actually
confirms that, saying CEF256. Are there any other modules in the
chassis?
On Sat, Mar 26, 2011 at 8:05 PM, Jeff Kell wrote:
> On 3/26/2011 2:32 PM, Jon Lewis
On 3/26/2011 2:32 PM, Jon Lewis wrote:
> On Sat, 26 Mar 2011, Jeff Kell wrote:
>> I intended to upgrade this to "something" suitable for full routing
>> tables, and went for a Sup720/PFC3CXL. A million routes, right?
>
> Not really. The million routes thing is highly misleading.
It at least "dep
On Sat, 26 Mar 2011, Jeff Kell wrote:
I had a 6509/Sup2 (clearly can't do full tables) for some time, using
various route-maps and filtering tricks to keep the IPv4 routes under
128K (which seems to be the magic number with uRPF enabled). If that is
exceeded, it generates TCAM overflow errors a
This topic seems to come up periodically... and I thought I had it
figured out... but apparently not. So I'm seeking some real-world
answers and opinions on my particular combination/options.
I had a 6509/Sup2 (clearly can't do full tables) for some time, using
various route-maps and filtering tr
On Mar 25, 2011, at 2:11 AM, Drew Weaver wrote:
> Basically what is happening is a host in a VLAN is getting flooded with http
> requests and when this happens the http requests are being unicast to all
> ports in this VLAN.
How was this diagnosed?
Are you sure that the /32 of the individual
> Assuming the DoS attack is routed traffic (since it's in netflow) it
> won't cause overflows in L2 forwarding table CAM.
Unless there's a layer2 device downstream from the router.
Not even then. Layer 2 source/dest addresses are rewritten on every
router hop. All traffic going through
On 03/25/2011 05:11 PM, John Neiberger wrote:
> Hmm, I noticed when I looked in the netflow for the attack traffic that
there were more than 400,000 source IPs participating in the attack, they were
obviously spoofed/what-have-you, but would that make a difference? I don't think
I've ever see
17 matches
Mail list logo
