Re: it was damp in belleview

2007-06-24 Thread Saku Ytti
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

Re: Thoughts on increasing MTUs on the internet

2007-04-12 Thread Saku Ytti
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

Re: Thoughts on increasing MTUs on the internet

2007-04-12 Thread Saku Ytti
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.

Re: Thoughts on increasing MTUs on the internet

2007-04-12 Thread Saku Ytti
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

Re: Thoughts on increasing MTUs on the internet

2007-04-12 Thread Saku Ytti
> 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]

Re: Thoughts on increasing MTUs on the internet

2007-04-12 Thread Saku Ytti
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

Re: Thoughts on increasing MTUs on the internet

2007-04-12 Thread Saku Ytti
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

Re: Google wants to be your Internet

2007-01-23 Thread Saku Ytti
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

Re: Lucent GBE (4 x VC4) clues needed

2006-11-15 Thread Saku Ytti
> > 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

Re: Lucent GBE (4 x VC4) clues needed

2006-10-21 Thread Saku Ytti
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

Re: Lucent GBE (4 x VC4) clues needed

2006-09-21 Thread Saku Ytti
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

Re: Lucent GBE (4 x VC4) clues needed

2006-09-21 Thread Saku Ytti
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

Lucent GBE (4 x VC4) clues needed

2006-09-21 Thread Saku Ytti
(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

Re: Market Share of broadband provider in Scandidavia

2006-09-08 Thread Saku Ytti
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 >

Re: Deaggregation Disease

2006-07-21 Thread Saku Ytti
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

Re: Deaggregation Disease

2006-07-21 Thread Saku Ytti
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

Re: Cisco 3550 replacement

2006-02-20 Thread Saku Ytti
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

Re: Leap second reminder

2006-01-01 Thread Saku Ytti
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

Box with (H)VPLS hub+spoke (martini EoMPLS) support in the market?

2005-11-22 Thread Saku Ytti
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-

Re: zotob - blocking tcp/445

2005-08-15 Thread Saku Ytti
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

Re: zotob - blocking tcp/445

2005-08-15 Thread Saku Ytti
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

Re: OT: Cisco.com password reset.

2005-08-03 Thread Saku Ytti
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

Re: IOS new architechture will be more vulnerable?

2005-08-03 Thread Saku Ytti
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?

Re: eWeek: Cisco Comes Clean on Extent of IOS Flaw

2005-07-29 Thread Saku Ytti
> >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

Re: BCP regarding TOS transparancy for internet traffic

2005-05-25 Thread Saku Ytti
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.

Re: BCP regarding TOS transparancy for internet traffic

2005-05-25 Thread Saku Ytti
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

Re: BCP regarding TOS transparancy for internet traffic

2005-05-25 Thread Saku Ytti
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).

Re: BCP regarding TOS transparancy for internet traffic

2005-05-25 Thread Saku Ytti
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

Re: BCP regarding TOS transparancy for internet traffic

2005-05-25 Thread Saku Ytti
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

Re: snmp vuln

2004-04-22 Thread Saku Ytti
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

Re: The Cidr Report

2003-09-26 Thread Saku Ytti
On (2003-09-26 22:00 +1000), [EMAIL PROTECTED] wrote: > 192.88.99.0/24 AS3246 SONGNETWORKS Song Networks RFC3068. -- ++ytti

Re: attacking DDOS using BGP communities?

2002-10-18 Thread Saku 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

Re: attacking DDOS using BGP communities?

2002-10-18 Thread Saku Ytti
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

attacking DDOS using BGP communities?

2002-10-17 Thread Saku Ytti
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