December 2005 - Test - lists.nanog.org

Testing the route
by Kaustubh Atrawalkar 18 Dec '05

18 Dec '05

Hello , I am trying to send a test packet to the router for which my router has received an update packet containg the route. So that i can test the route and check its validity for any false route information. also it will be helpfull to keep eye on security issues. Plz comment. Is this possible ? if not why? if yes give me your feedback.

1 0

Need a clue at rr.com mail operations
by Mark Jeftovic 17 Dec '05

17 Dec '05

Our forwarders are being blocked and we've been trying for a few days to get in touch with your mail admins about this. please contact me offlist -- Mark Jeftovic <mark(a)easydns.com> President & CEO, easyDNS Technologies Inc. ph: +1-(416)-535-8672 ext 225 fx: +1-(866)-273-2892

2 1

AT&TMPLS Issues?
by Elijah Savage 17 Dec '05

17 Dec '05

All, I had about 20 customer down today which connect back to me via vpn connectivity across the internet, but we also have a private Sprint MPLS conection that was down at this time. My VPN tunnels all started to come up at about 2:20pm today at the same time and at exactly that time my private Sprint MPLS connectivity came back up which was weird. Below you will find traceroutes that stops in Sprints address space but then after it all came back up the very next hop is AT&TMPLS. I then did some correlation and found out that all my tunnels that were down the peering address belongs to AT&T all were 12.x addresses. Were there some sort of routing issue between AT&T and Sprint between Noon and 2:30 today? I do not peer with AT&T or Sprint so I am sure they will not give me any info if I called in. But I do have a ticket open with my provider to see if they can get info out of them. Incomplete 1 68.250.30.130 4 msec\par 2 66.73.28.97 0 msec\par 3 65.43.25.116 4 msec\par 4 151.164.188.201 12 msec\par 5 151.164.242.129 20 msec\par 6 151.164.42.168 20 msec\par 7 151.164.191.114 20 msec\par 8 151.164.42.139 20 msec\par 9 144.223.241.57 24 msec\par Complete 1 68.250.30.130 0 msec\par 2 66.73.28.97 4 msec\par 3 65.43.25.116 0 msec\par 4 151.164.188.201 12 msec\par 5 151.164.242.129 180 msec\par 6 151.164.42.168 20 msec\par 7 151.164.191.114 20 msec\par 8 151.164.42.139 20 msec\par 9 144.223.241.57 20 msec\par 10 192.205.32.141 236 msec\par 11 AT&T[MPLS: Label 32752 Exp 0] 52 msec\par 12 12.122.10.46 [MPLS: Label 32451 Exp 0] 52 msec\par 13 12.122.9.141 [MPLS: Label 32326 Exp 0] 52 msec\par 14 12.122.10.90 [MPLS: Label 32259 Exp 0] 52 msec\par 15 12.122.9.161 [MPLS: Label 32279 Exp 0] 52 msec\par 16 12.122.10.130 [MPLS: Label 32761 Exp 0] 52 msec\par 17 12.122.12.150 [MPLS: Label 450 Exp 0] 56 msec\par

1 2

Is Internet security ISPs' problem?
by Hank Nussbacher 17 Dec '05

17 Dec '05

http://insight.zdnet.co.uk/internet/security/0,39020457,39242604,00.htm -Hank

1 0

RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
by Fergie 16 Dec '05

16 Dec '05

Sean, And let's see: What was the problem again? ;-) Oh, yeah -- some telco execs want to degrade traffic in their networks based on __________. (Fill in the blank.) - ferg -- Sean Donelan <sean(a)donelan.com> wrote: On Fri, 16 Dec 2005, Christopher L. Morrow wrote: > Maybe part of the discussion problem here is the overbroad use of 'QOS in > the network!' ? Perhaps saying, which I think people have, that QOS [snip] If you want to define QoS as a strawman, you can. But it doesn't solve the problem. -- "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: The Qos PipeDream [Was: RE: Two Tiered Internet]
by Christopher L. Morrow 16 Dec '05

16 Dec '05

On Fri, 16 Dec 2005, Min Qiu wrote: > Hi Chris, > hey :) > > -----Original Message----- > From: owner-nanog(a)merit.edu on behalf of Christopher L. Morrow > Sent: Thu 12/15/2005 10:29 PM > To: John Kristoff > Cc: nanog(a)merit.edu > Subject: Re: The Qos PipeDream [Was: RE: Two Tiered Internet] > > snip... > > > Speaking to MCI's offering on the public network it's (not sold much) just > > qos on the end link to the customer... It's supposed to help VOIP or other > > jitter prone things behave 'better'. I'm not sure that we do much in the > > way of qos towards the customer aside from respecting the bits on the > > packets that arrive (no remarking as I recall). So, what does this get you > > aside from 'feeling better' ? > > Not 100% true. Through I agree QoS has little impact in the core > that has OCxx non-congested backbone (more comments below). In the > edge, it does has its place, as Stephen Sprunk and Mikael Abrahamsson > explained/described. I recalled we were busy at one time to find out > why one of our _most_ important T1 customer's poor VoIP performance. > It turned out his T1 was peaked in those peroid. yup, for t1 customers (or dsl or dial) qos matters only if your like is full when you want to do something with stringent delay/jitter/loss requirements (voip). Possibly a better solution for both parties in the above case would have been MLFR ... possibly. (someone would have to run the numbers, I'm not sure how much the 'qos' service costs in real $$ not sales marked-down-for-fire-sale $$) > > > snip... > > > most large networks (as was said a few times I think) don't really need it > > in their cores. I think I've seen a nice presentation regarding the > > queuing delay induced on 'large pipe' networks, basically showing that qos > > is pointless if your links are +ds3 and not 100% full. Someone might have > > a pointer handy for that? > > There is a little problem here. Most of the studies assume packet arrive > rate governed by poision rule. Those data collections were from application > sessions-->normal distribution when number of sessions-->infinity. However, > this can only apply to core, specially two tiered core where packet arrive > rate are smoomthed/aggregated. I did experied long delay on a DC3 backbone > when the utilization reach to 75%~80%. Packet would drop crazy when the > link util reach to ~90% (not 100% tied to quenueing, I guessed). That said, i think this is where WRED is used... avoid the sawtooth effect of tcp sessions, random drop some packets and force random flows to backoff and behave. I think I recall WRED allowing (with significant number of flows) usage to reach 95+% or so smoothly on a ds3... though that is from some cisco marketting slides) > it only move the threahold in the core from DC3 to OC12 or OC48 (see Ferit > and Erik's paper "Network Characterization Using Constraint-Based Definitions > of Capacity, Utilization, and Efficiency" > (http://www.comsoc.org/ci1/Public/2005/sep/current.html I don't have the > access). I'm not sure the study can applied to customer access edge > where traffic tend to be burst and the link capacity is smaller in > general. Maybe part of the discussion problem here is the overbroad use of 'QOS in the network!' ? Perhaps saying, which I think people have, that QOS applied to select speed edge interfaces is perhaps reasonable, I'd bet it still depends on the cost to the operator and increased cost to the end-user. it may be cheaper to get a second T1 than it is to do QOS, and more effective. Alternately, customers could use other methods aside from QOS to do the shaping, assuming 'QOS' is defined as tos bit setting and DSCP-like functions, not rate-shaping on protocol or port or source/dest pairs.

3 2

Re: Whatever happened to intelligence in the applicattion [Was: Re: Th e Qo s PipeDream]
by Fergie 16 Dec '05

16 Dec '05

Agreed. Although my preference is (as you stated earlier) 'graceful degradation' in the face of congestion, not intentional degradation of traffic based on some arbitrary monetray boundary. Again, there should never be a case for _intentional_ "less- than-best-effort", in the traditional sense. Of course, these arguments assume that the service provider does the Right Thing (tm) w.r.t. capacity planning & engineering. ;-) - ferg -- Lamar Owen <lowen(a)pari.edu> wrote: On Friday 16 December 2005 09:21, Fergie wrote: > Doesn't anyone really remember the whole smart-v.-stupid network > analogy? Not meaning to start a flame war here, but trying to stick > all of the intelligence back into the network is not exactly a win-win > proposal. A stupid network is easier for malicious applications to exploit. Need a balance point, not either extreme. -- "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: The Qos PipeDream [Was: RE: Two Tiered Internet]
by Fergie 16 Dec '05

16 Dec '05

Bingo. Very well stated. - ferg -- Lamar Owen <lowen(a)pari.edu> wrote: [snip] On the operational end, the challenge becomes designing networks that in the presence of ubiquitous oversubscription degrade gracefully and allow certain features to have lesser degradation. Thus QoS. [snip] -- "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

Whatever happened to intelligence in the applicattion [Was: Re: The Qo s PipeDream]
by Fergie 16 Dec '05

16 Dec '05

I think you just tossed a red herring into the discussion. :-) I would suggest that a semi-intelligent playback bufferring scheme in the VoIP application, plus a 'semi-lossless' link, would be just fine. ;-) Doesn't anyone really remember the whole smart-v.-stupid network analogy? Not meaning to start a flame war here, but trying to stick all of the intelligence back into the network is not exactly a win-win proposal. - ferg -- Mikael Abrahamsson <swmike(a)swm.pp.se> wrote: On Fri, 16 Dec 2005, Christopher L. Morrow wrote: When you're running voip over a T1/E1, you really want to LLQ the VOIP packets because VOIP doesn't like delay (not so much a problem) nor jitter (big problem), nor packetloss (not so much a problem if it's less than a 0.1 percent or so). So combining voip and data traffic on a link that sometimes (more often now when windows machine have a decent TCP window) go full, even just in a fraction of a second, means you either go QoS or do what Skype does, crank up the jitter buffer when there is high-jitter, which means latency for the call goes up. [snip] -- "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/

5 4

RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
by Hannigan, Martin 16 Dec '05

16 Dec '05

Hey there Fergie: > Martin, > > You can 'see' anything you'd like, buy your reality > does not match everyone else's -- my opinion, of course. > > QoS is a myth -- it doesn't exist. > > What you're obviosuly trying to tell us is that less-than-best- > effort is somehow good? Never sell it. > > This vein will come back and bite you guys who think like this. > I'm not sggesting that this be the way the Internet operate at all. The poster asked how this would work if it did (my interpretation) and where there is will (customers) and money (ISP's) there is always a way. The old school in me says "never!", but the experience in me says "possible". I think it *is* unlikely though. Consider the busy signal approach for a second though. Can we build, pay for, and sustain an Internet that never has congestion or is never "busy". If you have a web server and a limited amount of memory or net you tune down the number of httpd's that are spawned and when they are all busy, your site doesn't answer and you get a 404. That's akin to a busy signal and is already in practice today. If I'm Google, for example, I buy thousands of servers so this does not happen. If I'm just plain old me and I am running some popular faq on my personal site, I accept the 404's because I am not going to pay for 100% performance. They can try again later, or, I can pay for more memory or more network to insure optimal performance. Hope that makes a little more sense. And let me turn the question around to you. If the Internet were to work like this, how would we do it? > - ferg > > > -- "Hannigan, Martin" <hannigan(a)verisign.com> wrote: > > > > What I'm interested in is how the two service > > providers will build a two tiered Internet. > > The PSTN is tiered both in architecture and operation. > Switching hiearchies and a seperate SS7 network which > is basically a billing network. > > I think the thought is service levels vs. congestion control. > For example, CO's have call overflow mechanisms to tandem switch > points which basically seek out excess capacity and use it as > overflow for call termination if and when possible. > > I could see an internet hiearchy where preferred traffic was > switch onto hicap overflow links with controlled congestion and > other traffic, non premium traffic, "got a fast busy". > > -M< > > -- > "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/ > > >

3 2