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 goo
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-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 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 pay
> 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 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
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 subne
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 L
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.
Anyh
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
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 long
(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-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 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 t
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).
>
>http://www.ietf.org/internet-drafts/draft-ietf
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
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 of
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-+
|
L2_cust--L2--PE2---EoMPLSPE4-
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 sug
On (2005-08-15 18:51 +), [EMAIL PROTECTED] wrote:
> NetBIOS was never meant to be a WAN protocol, so no problem
> in blocking it.
I'm not nearly confident enough to decide on behalf of almost
billion other people how they should benefit from the Internet
and how not to.
There are real solu
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 com
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?
> >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 "I
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 (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
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 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 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 th
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 yo
On (2003-09-26 22:00 +1000), [EMAIL PROTECTED] wrote:
> 192.88.99.0/24 AS3246 SONGNETWORKS Song Networks
RFC3068.
--
++ytti
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
har
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 par
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 inc
34 matches
Mail list logo
