On (2007-06-23 08:22 -1000), Randy Bush wrote:
for those wishing historical perspective on route flap damping, document
ripe-378 (may 2006) says
i.e., it's time to turn it off. you are damaging your customers and
others' customers.
I've always thought that damping as an idea is a good
On (2007-04-12 11:20 +0200), Iljitsch van Beijnum wrote:
What do you guys think about a mechanism that allows hosts and
routers on a subnet to automatically discover the MTU they can use
towards other systems on the same subnet, so that:
1. It's no longer necessary to limit the subnet
On (2007-04-12 16:28 +0200), Iljitsch van Beijnum wrote:
On 12-apr-2007, at 16:04, Gian Constantine wrote:
I agree. The throughput gains are small. You're talking about a
difference between a 4% header overhead versus a 1% header overhead
(for TCP).
6% including ethernet overhead
Or compared without tcp timestamp and 1500 to 4470.
[EMAIL PROTECTED] ~]% echo 1460/(1+7+6+6+2+1500+4+12)*100|bc -l
94.92847854356306892000
[EMAIL PROTECTED] ~]% echo 4410/(1+7+6+6+2+4470+4+12)*100|bc -l
97.82608695652173913000
Apparently 70-40 is too hard for me.
[EMAIL PROTECTED] ~]%
On (2007-04-12 19:51 +0200), Iljitsch van Beijnum wrote:
8 bytes preamble
14 bytes ethernet II header
20 bytes IP header
20 bytes TCP header
12 bytes timestamp option
4 bytes FCS/CRC
12 bytes equivalent inter frame gap
90 bytes total overhead, 52 deducted from the ethernet payload, 38
On (2007-04-13 00:17 +0100), Will Hargrave wrote:
At LONAP a jumbo frames peering vlan is on the 'to investigate' list. I
am not sure if there is that much interest though. Another vlan, another
SVI, another peering session...
Why another? For neighbours that are willing to peer over eg.
On (2007-04-12 20:00 -0700), Stephen Satchell wrote:
From a practical side, the cost of developing, qualifying, and selling
new chipsets to handle jumbo packets would jack up the cost of inside
equipment. What is the payback? How much money do you save going to
jumbo packets?
It's
On (2007-01-23 12:25 -0500), Jamie Bowden wrote:
Virginia Power replaced our meter over the summer with a new one that
has wireless on it. The meter reader just drives a truck past the
houses and grabs the data without him/her ever leaving the truck. I
have no idea what protocol they're
Consider this topology
GSR - 3750 --(GE over 4xVC4) - NSE100 - NSE100 --(GE over 4xVC4) -- 3550 -
GSR
This should have been Nortel GBE, not Lucent my bad.
My first best guess was right, it was lucent system after all.
We've now solved the issue, problem is in GBE card in Lucent in
On (2007-09-21 16:12 +0300), Saku Ytti wrote:
(oops technical question in nanog, wearing my asbestos suit)
Consider this topology
GSR - 3750 --(GE over 4xVC4) - NSE100 - NSE100 --(GE over 4xVC4) -- 3550 - GSR
This should have been Nortel GBE, not Lucent my bad.
Anyhow, just wanted
(oops technical question in nanog, wearing my asbestos suit)
Consider this topology
GSR - 3750 --(GE over 4xVC4) - NSE100 - NSE100 --(GE over 4xVC4) -- 3550 - GSR
All other fibres are dark fibres, except marked.
When we ping either NSE100 - GSR leg, when there is no background traffic
there
On (2006-09-21 06:32 -0700), David Temkin wrote:
traffic also. We've tried to turn PXF off in NSE100. Packets
Silly question (considering that you stated that IS-IS is borked also,
which is not handled by PXF - but did you try disabling PXF?
Not silly question at all, it was just longer
On (2006-09-21 18:49 +0100), Sam Stickland wrote:
Did you try power cycling the Lucents after changing the auto-neg
settings? I've seen some broken autoneg implementations in the past on
managed media converters that didn't change settings immediately. It's
worth a shot as you seem to be
On (2006-09-08 18:03 +0200), Mikael Abrahamsson wrote:
Could anyone point me to a market-share by-country overview of broadband
provider in Scandinavia (Denmark, Sweden, Norway, Finland, Iceland). Any
help would be appreciated.
For Sweden, you can go to www.pts.se, more exactly
On (2006-07-21 10:48 -0400), Joe Abley wrote:
As it happens, Tony Li, Rex Fernando and I wrote up a proposal for a
new attribute which might help in some of these situations. (It's a
crude mechanism, but not as crude as NO_EXPORT).
On (2006-07-21 11:38 -0400), Joe Abley wrote:
That seems to me like another perfectly valid approach, and one that
already exists to some extent (e.g. by pre-poisoning AS_PATH
attributes with AS numbers of remote networks that you don't want to
accept particular routes). I'm told that
On (2006-02-20 21:54 -0600), [EMAIL PROTECTED] wrote:
Reality Check:
32Gbps Backplane (Counted packet-in, packet-out, each direction, with all
packets the same size, multicast?) and 52 GE interfaces.
Not exactly non-blocking.
Gotsta do the CiscoMath.
And no hierarchial QoS, which was
On (2005-12-31 17:18 -0500), Deepak Jain wrote:
Linux seemed to survive happily too
[EMAIL PROTECTED] ~]% dmesg|tail -n1
Clock: inserting leap second 23:59:60 UTC
Curious though that not so many people who've I asked got these messages,
only explanation I can think
Hey,
Could someone please point me out if there is already boxes that support
acting as (H)VLPS HUB's for Martini EoMPLS spokes, with VLAN rewrite?
Hopefully this helps more than hurts:
L2_cust--L2--PE1---EoMPLS-+
|
On (2005-08-15 09:28 -1000), Randy Bush wrote:
There are real solutions to the problem, which include monitoring
the end-user traffic and do traffic steering for infected hosts
to a web page thats helps solving their problem.
for we who are under-clued, do you have a url for suggested
On (2005-08-03 06:24 -0400), Joe Maimon wrote:
But at the same time, now that I think they already are, I will say it's
not as bad as you probably think it is. Not yet ... because the version
that makes this an unstoppable critical problem is not out yet.
What exactly does this mean?
On (2005-08-03 09:02 -0500), Church, Chuck wrote:
I eventually got an email stating it couldn't associate my email address
with an active CCO ID. I'm guessing their system is getting backed up
because it's affecting lots of people. Next step:
Send three times from mutt, and got same
http://www.eweek.com/article2/0,1759,1841669,00.asp
Cisco still seems to be spinning it, though. The important part of
Lynn's presentation wasn't the IPv6 exploit, but how future exploits can
be used to execute arbitrary code on Cisco equipment. By making a big
deal about the IPv6
On (2005-05-25 11:49 -0400), [EMAIL PROTECTED] wrote:
Out of curiosity, what did you hope to accomplish by zeroing that field?
IMHO only reason not to zero TOS byte on AS ingress border is that you
explicitly agreed with your neighbour how it is used (what traffic it
can contain, what is
On (2005-05-25 14:15 -0400), [EMAIL PROTECTED] wrote:
If you're seeing enough DoS traffic that an incorrect TOS is causing an issue
for you, you probably need to find better ways to mitigate that traffic.
Remember
that at the *source* end, the DoS traffic is pretty minimal, and at the
On (2005-05-25 14:44 -0400), Eric A. Hall wrote:
4) The default of no-modify should also apply to non-payinng customers
since they may be flagging their packets for special processing on their
own networks (and they don't want the flags to poof away when the traffic
crosses your hop).
On (2005-05-25 15:06 -0400), Eric A. Hall wrote:
Beatiful idea, how in practice do you suggest this is done, how will
my router know if it should just ignore the TOS bytes or do expedited
forwarding as configured for given value of TOS byte?
VLANs? Different route paths? Any of a dozen
On (2005-05-25 11:16 -0700), Fred Baker wrote:
I guess the question is why, just because you don't want to offer a
specific service, you want to prevent other ISPs from offering a stated
service to a user? There are some fairly good-sized ISPs offering
services based on the TOS octet.
On (2004-04-21 23:24 -0700), Alexei Roudnev wrote:
If you ever read SNMP specs, you can realize, that there is not any C or C++
SNMP implementation without such problem. So, rule number 1 is _never
expose SNMP to Internet, and be careful to filter out any inbound packets,
forwarded to your
On (2002-10-18 00:15 -0400), John Fraizer wrote:
2) 'TTL' community.
-just think about the amount of route-maps :
Whoa. Decrementing a single community integer value while leaving others
unchanged would seem to be a bit tricky. This would require much more
work on the part of
On (2002-10-18 04:13 -0400), John Fraizer wrote:
You receive a prefix with the communities :1 :2 :3 and
TTL-COMM:2. You need to decrement the TTL-COMM value while leaving the
other 3 communities unchanged.
Yes this would need change in IOS/JunOS but it wouldn't actually be
hard
How feasible would these ideas be?
1) Signaling unwanted traffic.
You would set community which would just inform that you are receiving
unwanted traffic. This way responsible AS# with statistical netflow
could easily automaticly search for these networks and report to NOC if
both there is
32 matches
Mail list logo
