- NANOG - lists.nanog.org

looking glass resources, as promised :)
by Ariel Biener 30 Nov '00

30 Nov '00

Ok, this is what I gathered: Looking Glass locations: http://www.caida.org/analysis/routing/reversetrace/ http://www.traceroute.org Looking glass software: http://net.doit.wisc.edu/~plonka/FlowScan/ http://www.paranode.com/lg/ http://nitrous.digex.net/source/source.html ftp://ftp.enterzone.net/looking-glass/mrlg-3.0/ ftp://ftp.shrubbery.net/rancid/rancid-2.1b.tar.gz Charles Sprickman <spork(a)inch.com> also mentioned that some of the sites that offer LG service also have a link to the source they use, so, you can also try that, YMMV. again, thanks for the input, --Ariel -- Ariel Biener e-mail: ariel(a)post.tau.ac.il PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html

1 0

Fw: Internet access in Honolulu, HI ? (fwd)
by Brian 29 Nov '00

29 Nov '00

Someone asked about Hawaii access, I got this from a coworker that used to live there. He can try the "Internet Cafe." I can't remember what street that is on. But, for the price of coffee he can stay there for hours. At least that's the way it use to be! Brian

2 1

Re: Traceroute versus other performance measurement
by smd＠clock.org 29 Nov '00

29 Nov '00

| I thought the 5th tuple of 5-tuple is usually the L4 protocol (TCP, UDP, | ICMP, etc.). If your algorithm also takes DS values into account, you'd | have a 6-tuple. It's possible to take into account TCP/UDP/whatnot but breaking fate-sharing based on something that is not inherently a hint to the routers of the Internet seems rather strange, especially considering that you can end up in weird situations where ICMP works and TCP doesn't, or vice-versa, making things very hard to diagnose. If a 5-tuple is being used, TOS/diffserv makes much more sense, because the settor of that byte is explicitly signalling to the routing system that packets are to be treated differently from others with different values in the same byte. There is also the fact that splitting traffic across multiple paths based on passenger transport protocol is unlikely to produce much of a win anyway; the bulk of traffic by packets and by bytes is associated with the other 4 elements is very likely to be TCP, and thus there is not much better opportunity for statistical traffic separation than by using the TOS/diffserv byte. While most traffic simply is not coloured today, the opportunity to colour in order to improve traffic separation is greater when there is an element involved that you are allowed to change. This is in essence a "poor man's explicit routing" in that the source (or something in between) can move traffic between one source and destination in a different way. That is somewhat different from using L4 type, which is and must always be invariant. Sean.

1 0

Re: Traceroute versus other performance measurement
by smd＠clock.org 29 Nov '00

29 Nov '00

| At the expense of using all their bandwidth ttcp should provide some | reasonable measure of performance under those circumstances. ttcp has the disadvantage of invariant 5-tuple, which is germane to this problem. Sean.

2 1

Re: Traceroute versus other performance measurement
by smd＠clock.org 29 Nov '00

29 Nov '00

Daniel Senie writes: | All the theory sounds great. Now, you've got a customer using the utility to | test a circuit between two boxes, and calls to complain that he's only | seeing 1/2 of the expected bandwidth, because Pathchar tells him he's | getting X, and we said we provisioned 2X. Perhaps it's just a customer | education issue. Or perhaps he is using pathchar correctly to measure the end-to-end path characteristics between a specific source and a specific destination, and is correctly complaining that your load-balancing solution does not result in anything near the expected end-to-end available bandwidth. | I think you're making assumptions about how load is shared on parallel | links. Often this is done by hashing the IP address or mac address of the | packets as a way to ensure there will be no packet reordering issues on the | parallel links. You can send traffic until you clog one of the two pipes, | but will never cause spill to the other link. Yeah yeah I know nothing about leon the cleaner... Consider the pathchar chase where the 5-tuple is hashed into buckets which can be spread evenly among a set of lines; pathchar is thus either a single flow or lots of flows, depending on how it does things. If it's lots of flows, it represents the aggregate bandwidth, which is meaningful if the end-to-end traffic is going to be spread across lots of flows (e.g. web traffic, lots of small transfers). If it's a single flow, it will measure a component, and will be meaningful if the traffic is going to be big single flows -- the degerate case of which is a single (encrypted) tunnel for VPN-ish purposes. If your customer expects to have traffic like the first case, and complains because the component is measured, he or she needs a simple explanation, and a simple demonstration (vary the 5-tuple, or whatever information is used to generate the hash),. However, if your customer expects to have traffic like the second case, then perhaps she or he is right complain when the component is measured. You look good in any case if pathchar measures the aggregate of the parallel paths; undeservedly so if real traffic is not balanced properly. Definitions: n-tuple: a set of data of n discrete elements 5-tuple: dest addr, src addr, dest port, src port, tos/diffserv 1-tuple: dest addr [or dest prefix] | You're making the assumption that you'll see change in the path FROM THE ONE | STARTING POINT where you're running pathchar. This is simply not going to | happen in many cases. Equal cost multipath, trunking and even unequal cost | pathing will result in you seeing only a part of the picture. Pathchar is not psychic; it assumes you are measuring the path characteristics between the testing station and some arbitrary (but fixed) destination. A big yellow warning label might be used to indicate that the path characteristics to even the "previous" or "next" address "beside" the target destination can result in dramatically different results because of 5-tuple hash-based load-balancing is probably useful. | Yet people run the tools, believe the results, even though the results | aren't telling them the truth. This is backed up by observations in the real | world, customer complaints and all. Hey, people use all sorts of strange measurement tools which they lack the skills to interpret. Many of them are in marketing departments... Oh hey, there is a potential gun-control analogy here. :-) Sean. (is that Godwin's Law yet?)

2 1

RE: Internet access in Honolulu, HI ? (fwd)
by Mathew Butler 29 Nov '00

29 Nov '00

Good, cheap access can be found at www.flex.com. 5-minute setup, and since you're on this list you should meet their definition of 'clueful user'. :) -Mat Butler -----Original Message----- From: Brian [mailto:bri@sonicboom.org] Sent: Wednesday, November 29, 2000 7:24 AM To: nanog(a)nanog.org Subject: Fw: Internet access in Honolulu, HI ? (fwd) Someone asked about Hawaii access, I got this from a coworker that used to live there. He can try the "Internet Cafe." I can't remember what street that is on. But, for the price of coffee he can stay there for hours. At least that's the way it use to be! Brian

1 0

Re: Traceroute versus other performance measurement
by smd＠clock.org 29 Nov '00

29 Nov '00

Daniel Senie writes: | Programs such as pathchar can AT MOST tell you about latency, not about | bandwidth. Well, this is simply wrong. The theory of operation for pathchar is very simple: it attempts to build a queue at an interface, and measure the amount of time it takes two back-to-back packets to pass through. The law of large numbers says that for any interface, given enough traffic emitted from pathchar, there will be a time when pathchar will successfully observe the minimum packet inter-arrival time, and/or the minimum delay for a set of varying-length packets, either of which will indicate the bottleneck bandwidth. Pathchar is robust against nearly everything except a bottleneck mismatch[*]: trying to measure a faster bottleneck (interface) than one closer to the pathchar-running host is subject to huge errors, and the very clever maths used to improve the SNR increase of the nearer slower interface is sometimes just insufficient. | Any cases where links are in parallel (e.g. multilink PPP of | multiple ISDN or T1 lines, or trunked Ethernet links) will typically NOT | show up in the calculations, Simple logic tells us that this doesn't matter: you end up either measuring the bottleneck bandwidth of the aggregate of the multiple paths, or the bottleneck bandwidth of a single component, depending on how the load-balancing works. Pathchar tries to avoid measuring only the component bandwidth. More interesting is non-parallel equal-cost paths, and pathchar does tricks to measure the various components as can be seen; the problem is that there are non-parallel equal-cost paths that are invisible (tunnels of whatever sort, of which MPLS is a bad variety). Your complaint about this would be reasonable if pathchar weren't trying to measure the path characteristics that would be seen by a flow ORIGINATING AT THE PATHCHAR TEST BOX. If in the multiple-path case such a flow is constrained to a single component, then pathchar is correct to report that. IOW, yes, pathchar is poor at identifying some types of network infrastructure, but that is not its job. It is very good at its job, which is indicating the bottlenecks from source to destination, and giving a very good guess at the bottleneck bandwidths. | This compounds other issues with trying to determine path characteristics | with such tools, most especially (and as others mentioned) asymmetric paths. On the contrary; if real live traffic (which pathchar generates) observes path flutter over finite time, then other real live traffic (as generated by users) also likely will flutter over finite time. This is backed up by other observations, such as Vern Paxson's, that attempt to characterize the routing, delay and loss aspects of the Internet over long periods of time (taking advantage of the law of large numbers). Pathchar just works faster and tries to answer the question of bottleneck bandwidth, and make educated guesses about the bandwidths of subsequent bottlenecks. The paper is quite good at describing alot of the theory of operation, http://www.caida.org/tools/utilities/others/pathchar/ and deals explicitly with some of Daniel Senie's objections. Sean. - -- [*] it is also not robust against "slow path" bottlenecks, which occur when the test traffic is treated substantially differently than "real" traffic, although since test traffic "through" a router en route to a subsequent hop is _unlikely_ to be treated differently (as compared with test traffic _to_ the same router), one can filter out undesirable artefacts to some degree by using data collected by measuring "end-to-end".

3 2

More on AS Transition
by Daniel L. Golding 29 Nov '00

29 Nov '00

A little more on the earlier AS Number transition question... Cisco does have a feature than can do this, the link is: http://www.cisco.com/warp/customer/459/39.html. This is very similar to the Juniper feature, with one key difference: The Juniper feature allows the "spoofed" AS number to be stripped out by using the "private" keyword after the spoofed AS number. Cisco does not, currently. This can result in an additional element is added to the AS-Path of both incoming and outgoing routes - a prepend. This can unexpectedly change routing characteristics, so caution is in order when using the Cisco version of this command (or the Juniper version without the private keyword). i.e. Your downstream asking you why the traffic on their circuit to you dropped 30%, and why the route announcements look different on Looking Glass servers. - Dan Golding NetRail, Inc.

1 0

Re: Traceroute versus other performance measurement
by smd＠clock.org 29 Nov '00

29 Nov '00

I was imprecise because I was jumping between tools, oops. Pathchar as we know it does not build a queue of depth 1 at an interface, it in fact seeks to measure additive RTT and attempt to figure out how much of the previous measured RTT was spent inside the router rather than being propagated along TDM transmissions gear and the like. Queue depth 1 is a mooted refinement, is all... Sean.

1 0

RE: Traceroute versus other performance measurement
by Mark Borchers 29 Nov '00

29 Nov '00

Presumably you're asking if it's a good tool to measure *available* bandwidth or lack thereof, i.e. congestion and its byproducts of packet loss and increased latency. No, it isn't! - Congestion resulting from asymmetric paths can be misinterpreted through traceroute. - Cases where ICMP performance with respect to the routers themselves is significantly lower than throughput of production traffic will often skew results. Having said that, where traceroutes suggest a POSSIBLE problem on my own network, I'd check further. However, I would never ask the operator of another network to troubleshoot solely on the basis of traceroute output. > > -----Original Message----- > > From: Paul Bradford [mailto:paul@adelphia.net] > > Sent: Wednesday, November 29, 2000 9:08 AM > > To: nanog(a)merit.edu > > Subject: Traceroute versus other performance measurement > > > > I need help with a reality/sanity check. Traceroute is a > > good tool for > > checking for routing type problems (loops). Does anyone feel > > it's a good tool > > to use for testing "bandwidth".... >

2 1