- NANOG - lists.nanog.org

Re: Route instability in the N.E. US this morning?
by Fergie (Paul Ferguson) 26 May '05

26 May '05

Looked like a "routing tsunami" from down here in Austin. :-) Knocked us out for about a half-hour.... concur with the suspected origin. Given all the the discussion on the list regarding s*BGP, for a few minutes there I thought someone was just trying to teach us all a hard lesson by injecting massive instability into the DFZ. ;-) - ferg -- "Jonathan M. Slivko" <jonathan(a)slivko.org> wrote: I saw *almost* 100% packet loss to Verio in Boca Raton, FL this morning, looks like it all started in Ashburn (it was about 80% after a few minutes of mtr running). Fergie (Paul Ferguson) wrote: > > Anyone know of any issues in the NE this morning? Lot's of > routing instability.... > > - ferg >

3 2

Re: Suggestions for failover/data-rate limiting
by Sargon 26 May '05

26 May '05

On Thursday, 26-May-2005 12:11, you wrote: > There's a lot of 'it depends' here. > - what are the loads of the links in a steady-state? Peer A typically runs at 80 Mbps. Peer B typically runs at 15 Mbps. Peer C (Internet2) typically runs at 15 Mbps, but frequently spikes to 60 Mbps for extended periods of time. > - how do you rate limit the 2nd link? The upstream currently has a rate limit (and so do we, just in case the provider fat-fingers something in a config), but we want to move away from that, since that would entail manual intervention. > - how are you balancing load among the three links? We aren't. I created the current route maps based on what they wanted (from a financial viewpoint). Based on those financial considerations, we will not load balance, at least not with the three providers we are currently using (and there are no plans to change providers in the near future). > I expect your answer will be in removing any rate limiting > configuration, and setting up some local-prefs on AS's to balance > traffic. Then your expensive 2nd link will take load (and incur > cost) upon failure of link 1. We currently have local prefs in place. They work fine, but we still have the data-rate problem: as long as we make the call to Peer B (or I can get to a computer fast enough to ssh into a router and drop the rate limits), no one complains Management is terrified of getting a huge bill from Peer B, so the rate limits (on both sides) will stay in place until we can find an "automated" solution. I gave up fighting that battle long ago.... Thanks.

1 0

Route instability in the N.E. US this morning?
by Fergie (Paul Ferguson) 26 May '05

26 May '05

Anyone know of any issues in the NE this morning? Lot's of routing instability.... - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

Suggestions for failover/data-rate limiting
by Sargon 26 May '05

26 May '05

We currently have three BGP and MBGP peering sessions, one of which is an Internet2 peer. Our primary peering session (peer A) is a 100 Mbps connection. Our secondary connection (peer B) also is a 100 Mbps connection rate-limited to 19 Mbps (for financial reason). The Internet 2 connection (peer C) is a 100 Mbps connection. Through various route maps, the Internet2 connection has the highest priority. Should that peer go away, Internet2 traffic will then route through peer B. All non-Internet2 traffic takes the path through peer A except for traffic destined for ASs within peer B's network. I have been asked to find a solution which does the following. A. In the event of losing connectivity to peer A, bandwidth limit of 19 Mbps to peer B is automatically increased to 45 Mbps within 1 minute or less, and do this without any manual intervention (i.e., phone call to upstream to change the rate limit). B. The design will need to be resilient to failure (hardware redundant) or, in the case of failure, it should fail safely (do nothing but function as a dumb, pass-through device). All suggestions will be greatly appreciated. Thanks. Sargon

1 0

BCP regarding TOS transparancy for internet traffic
by Mikael Abrahamsson 26 May '05

26 May '05

I've been debating whether the TOS header information must be left untouched by an ISP, or if it's ok to zero/(or modify) it for internet traffic. Does anyone know of a BCP that touches on this? My thoughts was otherwise to zero TOS information incoming on IXes, transits and incoming from customers, question is if customers expect this to be transparent or not. Reading <http://www.sanog.org/resources/sanog4-kaulgud-qos-tutorial.pdf> it looks like in the Diffserv terminology, it's ok to do whatever one would want. Any feedback appreciated. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

11 27

Be afraid: IPv6 techies get bent out of shape.... again
by Fergie (Paul Ferguson) 26 May '05

26 May '05

Hmmmm. IPv6 bullies again? http://www.washingtonpost.com/wp-dyn/content/article/2005/05/25/AR200505250… :-) - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: Stanford Hack Exposes 10,000
by Fergie (Paul Ferguson) 26 May '05

26 May '05

Everything is new again. - ferg -- Adam McKenna <adam(a)flounder.net> wrote: On Thu, May 26, 2005 at 12:28:32AM +0000, Fergie (Paul Ferguson) wrote: > I really didn't mean to start an off-topic rat-hole discussion, > but instead, point out how bad (nonchalant, cavalier) site security > has become with reagards to storing sensitive information. Has it really 'gotten' bad or just been that way all along? I don't know how the security was where you went to college, but at my school, people's SSN's were posted up on grading sheets for all to see. The names were missing, but still, you could easily get them just by watching people check their grades. --Adam -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: Stanford Hack Exposes 10,000
by Fergie (Paul Ferguson) 26 May '05

26 May '05

I really didn't mean to start an off-topic rat-hole discussion, but instead, point out how bad (nonchalant, cavalier) site security has become with reagards to storing sensitive information. This is just gettinh waaaay out of hand. And appears to be getting worse. Operational issue? You decide.... - ferg -- Mark Newton <newton(a)internode.com.au> wrote: On Wed, May 25, 2005 at 05:12:18PM -0700, Adam McKenna wrote: > On Wed, May 25, 2005 at 11:59:17PM +0000, Fergie (Paul Ferguson) wrote: > > Yet another unfortunate disclosure... > > http://www.techweb.com/showArticle.jhtml?articleID=163701121 > > I wonder when schools are going to get the hint and stop using SSN's as ID > numbers.. Around about whenever the US Federal Government gets the hint and passes a bill which makes it illegal to use social security numbers for any purpose other than the administration of social security. - mark -- Mark Newton Email: newton(a)internode.com.au (W) Network Engineer Email: newton(a)atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223

2 1

RE: Stanford Hack Exposes 10,000
by Dave Hilton 26 May '05

26 May '05

Just like the original law provided. "Around about whenever the US Federal Government gets the hint and passes a bill which makes it illegal to use social security numbers for any purpose other than the administration of social security." Hilton But I'll bet you knew that and I just bit down HARD on the hook :)

1 0

IDS/DDOS prevention hardware that doesnt cost $80,000+?
by Drew Weaver 25 May '05

25 May '05

I'm wondering if there is such an animal out there? All of the ones I have seen are made for the multi-gigabit service provider there aren't any for the smaller mid-rangers out there. Can anyone suggest anything that we can put in place? The attacks we're seeing are just a huge influx of PPS not so much the amount of bandwidth. Offlist to keep chatter low is fine with me. Sorry to be a bother, -D

6 5