Hi Vincent,
I've seen this too, its very annoying.
The reason is it is sampling the rate over a 1 or 2 second interval as opposed
to the interface rate which by default is 5 minutes altho you can go to as low
as 30s (load-interval 30).
Cisco: it would be very nice if we could tune that
Hi Vincent,
I'm saying it works just fine but the implementation is sucky. I use it
extensively but you just need to set your thresholds pretty high to make sure
they arent tripped. I also usually have it just filter rather than shut the
port that way it will auto-recover.
As to what 'pretty
On Wed, Jul 04, 2007 at 06:32:16PM +0300, Saku Ytti wrote:
On (2007-07-04 15:44 +0100), Stephen Wilcox wrote:
I take it you mean unicast frames with mac addresses that are currently
unknown to the switch on that port? In which case you cant limit it that
way.. but you have two options
On Wed, Jul 11, 2007 at 03:49:24PM +0800, Nick Kraal wrote:
Hi all,
A memory loss problem here.
We/ISP_A are trying to leak prefixes (which are not seen on the public
Internet) to a remote network/ISP_B via BGP. At this point of time we
are planning to build this via BGP over a IPv4
Hi Hitesh
On Thu, Jul 12, 2007 at 09:25:07PM +0530, Hitesh Vinzoda wrote:
hey Guyz,
Thanks for your suggestions... but we are going pretty deep inside.
i dont want to sync my 6509 to sync with any public time sources.
I think the point was that unless you setup proper external syncing your
compare to this.. i assume you are missing routing or ppp isnt really up etc
http://www.thedogsbollocks.co.uk/tech/cisco837-adsl.txt
On Mon, Jul 30, 2007 at 03:15:54PM +0200, R.L. Nevot wrote:
Perhaps you have only one public IP address? are you performing NAT?
post your configuration might
Hi Tuc,
can you provide a basic diagram, I'm confused reading the below. Also, what
outside nat translations do you have that you are referring to
Steve
On Mon, Jul 30, 2007 at 02:36:23PM -0400, Tuc at T-B-O-H.NET wrote:
Hi,
Recently I've gotten more into doing NAT at sites. I've
On Wed, Aug 01, 2007 at 08:54:16AM +0200, Gert Doering wrote:
Hi,
On Wed, Aug 01, 2007 at 04:43:20PM +1000, Gunjan GANDHI (BR/EPA) wrote:
Because ebgp routes are preferred over ibgp routes.
Thats is a tie breaker if the MED is equal. Which it isn't.
So indeed this is puzzling.
Um
Hi Christian,
a quick test says its the negotiated speed, which is what you would expect.
The exact mechanism its worked out with tho is a bit of voodoo.
Firstly I know they use a 1 or 2 second average which means it catches spikes
that your interface counter will never see and that arent
On Thu, Aug 02, 2007 at 05:25:07PM +0100, Euan Galloway wrote:
The difference was at step 7 Prefer eBGP over iBGP paths.
Which thankfully comes before step 6 Prefer the path with the lowest
multi-exit discriminator (MED). (huge list of med related caveats apply).
Unless we changed
.
Any comments?
thanks
___
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/
--
Stephen Wilcox
Technical Director, Packetrade Ltd
On Thu, Aug 30, 2007 at 11:07:36AM -0400, Jon Lewis wrote:
On Wed, 29 Aug 2007, Andy Dills wrote:
Don't forget that you can prepend incoming announcements as well as
outgoing announcements.
For instance, to account for the fact that there is essentially an
extra AS in your transit
Hmm I have to express some concern over the summary of responses.
The responders dont know much about your implementation, when asked
'will this router run BGP' the answer was yes but that doesnt mean
that the router will do its job correctly.
What isnt know is what you are trying to acheive
On 3 Sep 2007, at 03:58, Hock Jim wrote:
Sorry for being slightly off-topic, but hoping to seek some advise on
what is typically the case for ISP response in the case of a DDOS.
its fine but check out nanog which is more Internet operational than
here..
In the case of a DDOS attack that
1400 bytes is a size. 2Mbps is a rate
How much bandwidth it uses will depend on how many packets are sent
and how quickly..
Standard cisco ping will send 5 packets so this should result in
approximately 0Mbps when displayed by a cisco 'show int'
I would suggest if you see the link running
It means the interface MAC received data faster than it could be
passed to the controller.
I have seen it when there is a bad interface or bad cabling. It can
also be caused if you are trying to do some clever features with the
card and its not processing the packets quick enough.
68/627m
This is one shortcoming of static routing, a 'feature' if you like..
Perhaps this lack of dynamic ability of the statics would help with
the politics as to why routing is sensible? :)
Steve
On 5 Oct 2007, at 07:51, Kevin Barrass wrote:
Hi
Cheers for the below iam testing this out now
On 28 Sep 2007, at 20:15, Mark Kent wrote:
This is the first of what could be an annnoying sequence of questions.
Please turn on your fixed-width font viewer...
Here is the scenario:
{ISP1} {ISP2}
[7301] [7301]
[4948] [4948]
{servers}
and the question is What's the
It will support hundreds .. the issue is how many paths you learn
which is what will use both CPU and memory.
I dont exactly remember the limit but I think when we hit 12 BGP
routes was when I had to take my NPE-200s out of service just because
it ran out of memory. But even before the
Hi Marc,
as Gert says they vary over time so this has occurred because either its
putting out more power or the sensor has it wrong. You should test it with
a light meter. It may go faulty, this could be a sign its on its way out.
So, its probably not going to do any damage to a receiving optic,
20 matches
Mail list logo
