Huawei on Mount Everest
https://telecoms.com/504051/huawei-and-china-mobile-stick-a-5g-base-station-on-mount-everest/ Why dont we leave the Everest alone? OTOH, we can now have tiktok videos and latest instagram posts from the summit. Yippe. Just when you think things cant get worse, they sink deeper.
Re: Flow based architecture in data centers(more specifically Telco Clouds)
Hi, On Mon, Feb 10, 2020 at 3:22 PM Saku Ytti wrote: > On Sun, 9 Feb 2020 at 23:09, Rod Beck > wrote: > > > I am curious about the distinction about the flow versus non-flow > architecture for data centers and I am also fascinated by the separate > issue of WAN architecture for these > > Based on the context of the OP's question, he is talking about > architecture where some components, potentially network devices, are > flow-aware, instead of doing LPM lookup per packet, they are doing LPM > lookup per flow. > This was exactly my question. > This comes up every few years in various formats, because with > flow-lookup you have one expensive LPM lookup per flow and multiple > cheap LEM lookups. However the LEM table size is unbounded and easily > abusable leading to a set of very complex problems. > > There are of course a lot of variation what OP might mean. Network > might be for example entirely LEM lookup with extremely small table, > by using stack of MPLS labels, zero LPM lookups. This architecture > could be made so that when server needs to send something say video to > a client, it asks orchestration for permission, telling I need to send > x GB to DADDR K with rate at least Z and no more than Y, orchestration > could then tell the server to start sending at time T0 and impose MPLS > label stack of [l1, l2, l3, l4, l5] > > Orchestration would know exactly which links traffic traverses, how > long will it be utilised and how much free capacity there is. Network > would be extremely dumb, no IP lookups ever, only thousands of MPLS > labels in FIB, so entirely on-chip lookups of trivial cost. > My question was rather simple. Many cloud operators use Open Vswitch (OVS) based dataplanes wherein each packet results in a new flow in the system. The first packet does a lookup in the slow path which causes the fast path (either OVS-DPDK or a smartNIC or VPP-like paradigm or something entirely different) to be programmed. All subsequent packets hit the fast path and reach the VM (which is hosting the VNF). The advantage of this scheme is that the operator knows the exact flows existing in their data center and can run some sort of analytics on that. This obviously becomes harder once you start aggregating the flows or with mega flows, but you hopefully get the drift. The other architecture is based on LPM and LEM lookups. BTW, when i spoke about the Telco Cloud i had meant pure software based routing. NO hardware. No baremetals and physical network functions. I had pure VNFs in my mind, I see that Mellanox (smartNIC) is also programmed using flows. Hence is it fair to say that most of the current telco cloud architectures are built around OVS style flow based network devices? Glen > > -- > ++ytti >
Flow based architecture in data centers(more specifically Telco Clouds)
Hi, Are most of the Telco Cloud deployments envisioned to be modeled on a flow based or a non flow based architecture? I am presuming that for deeper insights into the traffic one would need a flow based architecture, but that can have scale issues (# of flows, flow setup rates, etc) and was hence checking. Thanks, Glen
Blockchain and Networking
Hi, Do folks on this list see blockchain technology making inroads into the networking? I can see blockchain being used to secure the SDN environment where blockchain will allow encrypted data transfers between nodes (ones hosting different applications, the SDN controller, the data plane devices) regardless of the network size or its geographical distribution. Where else can blockchain be used in networking? Glen.
Re: IP and Optical domains?
Mikael, Thanks. I was looking at a technical problem. I say this because you may not have this problem when both are networks are being run by the same vendor equipment, say Alcatel-Lucent (or Nokia now). What are the technical problems because of which ISPs need to over-provision when there are IP and optical domains involved. OR rather let me rephrase my question -- what is the technical challenge involved in setting up an end to end path between two IP domains that have an optical domain in between. Thanks, Glen On Sun, Jun 19, 2016 at 3:30 AM, Mikael Abrahamsson <swm...@swm.pp.se> wrote: > On Sun, 19 Jun 2016, Glen Kent wrote: > > Can somebody shed more light on what it means to say that the IP and >> optical layers are run as independent kingdoms and why do ISPs need to >> over-provision? >> > > You have a group that runs fiber+dwdm+sonet(or SDH). You have another > group that runs IP. When the IP guys ask "please tell us how the optical > network is designed, and can we coordinate how they're built and btw, we > want to put DWDM optics in our routers", the answer from the > fiber+dwdm+sonet group is "no, but we can help you with transport using our > transponders, please just order circuits, just give us addresses for each > end and we'll take care of things, don't you worry your little IP engineer > brain how things are transported long distance". > > I believe this is still the case at a lot of ISPs. Not all, hopefully not > even most, but I'm sure there are some. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se >
IP and Optical domains?
HI, I was reading the following article: http://www.lightreading.com/optical/sedona-boasts-multilayer-network-orchestrator/d/d-id/714616 It says that "The IP layer and optical layer are run like two separate kingdoms," Wellingstein says. "Two separate kings manage the IP and optical networks. There is barely any resource alignment between them. The result of this is that the networks are heavily underutilized," or, from an alternative perspective, "they are heavily over-provisioned." Can somebody shed more light on what it means to say that the IP and optical layers are run as independent kingdoms and why do ISPs need to over-provision? Thanks, Glen
Re: Strange Problem with 16 byte packets
Thanks i will. However, the doubt is that what does introducing a 16 byte data into the steam does that causes the session to time out. I added instrumentation to push some dummy data so that instead of 16 bytes, we push 1 MB of data. In that case i saw no issues. Any idea if there is a firewall setting that could be coming into play here? On Thu, Jun 16, 2016 at 2:17 PM, Ruairi Carroll <ruairi.carr...@gmail.com> wrote: > Follow the TCP stream - which side times out the link, and for what > sequences of data do you get ACKs for? > > /Ruairi > > On 16 June 2016 at 10:43, Glen Kent <glen.k...@gmail.com> wrote: > >> Hi, >> >> I am using a proprietary protocol and sending a bunch of bytes to a >> Draytek >> router at an enterprise site. When i send the data in TCP batches of 1 MB >> i >> see no problem. However, when i first send 16 bytes followed by 1 MB of >> data, and then repeat this till the entire data has beeen sent out. During >> this process I see that my TCP session times out. Unable to understand why >> this could be happening? How can sending 16 bytes of data followed by 1MB >> of data affect the transfer. >> >> Thanks ! >> > >
Strange Problem with 16 byte packets
Hi, I am using a proprietary protocol and sending a bunch of bytes to a Draytek router at an enterprise site. When i send the data in TCP batches of 1 MB i see no problem. However, when i first send 16 bytes followed by 1 MB of data, and then repeat this till the entire data has beeen sent out. During this process I see that my TCP session times out. Unable to understand why this could be happening? How can sending 16 bytes of data followed by 1MB of data affect the transfer. Thanks !
Re: Drops in Core
Is there a paper or a presentation that discusses the drops in the core? If i were to break the total path into three legs -- the first, middle and the last, then are you saying that the probability of packet loss is perhaps 1/3 in each leg (because the packet passes through different IXes). That sounds too aggressive for the middle mile. Dont you think so? On Sat, Aug 15, 2015 at 10:51 PM, Owen DeLong o...@delong.com wrote: I would say that the probability of a packet drop at any particular peering point is less than the probability at one of the two edges. However, given that most packets are likely to traverse multiple peering points between the two edges, the probability of a packet drop along the way at one of the several peering points overall is roughly equal to the probability of a drop at one of the two edges. YMMV. Owen On Aug 15, 2015, at 10:07 , Glen Kent glen.k...@gmail.com wrote: Hi Bill, Just making sure that i get your point: Youre saying that the probability of packet drop at peering points would roughly match that at the edge. Is it? I thought that most core switches have minimal buffering and really do cut-through forwarding. The idea is that the traffic that they receive is already shaped by the upstream routers. Glen On Sat, Aug 15, 2015 at 10:33 PM, William Herrin b...@herrin.us wrote: On Sat, Aug 15, 2015 at 12:47 PM, Glen Kent glen.k...@gmail.com wrote: Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has entered the core then chances are high that the packet will safely get across till the exit in the core. Hi Glen, I would expect congestion loss at enough peering points (center of the core) to put it in the same league as noisy cable at the edge. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
Re: Drops in Core
Hi Bill, Just making sure that i get your point: Youre saying that the probability of packet drop at peering points would roughly match that at the edge. Is it? I thought that most core switches have minimal buffering and really do cut-through forwarding. The idea is that the traffic that they receive is already shaped by the upstream routers. Glen On Sat, Aug 15, 2015 at 10:33 PM, William Herrin b...@herrin.us wrote: On Sat, Aug 15, 2015 at 12:47 PM, Glen Kent glen.k...@gmail.com wrote: Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has entered the core then chances are high that the packet will safely get across till the exit in the core. Hi Glen, I would expect congestion loss at enough peering points (center of the core) to put it in the same league as noisy cable at the edge. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
Drops in Core
Hi, Is it fair to say that most traffic drops happen in the access layers, or the first and the last miles, and the % of packet drops in the core are minimal? So, if the packet has made it past the first mile and has entered the core then chances are high that the packet will safely get across till the exit in the core. Sure once it gets off the core, then all bets are off on whether it will get dropped or not. However, the key point is that the core usually does not drop too many packets - the probability of drops are highest in the access side. Is this correct? Glen
Re: Strange traceroute result to VM in EC2, Singapore
Ooops. The attachment was dropped last time. This time its inline: When my traceroute works: [image: Inline image 1] When it doesnt: [image: Inline image 2] Thanks, Glen On Thu, Aug 6, 2015 at 7:06 PM, Dovid Bender do...@telecurve.com wrote: No trace attached. On Thu, Aug 6, 2015 at 9:28 AM, Glen Kent glen.k...@gmail.com wrote: Hi, I have two internet connections and can reach the VM in EC2, Singapore over either connection. I am doing an experiment for which I traceroute to this VM from the two different internet connections (to really get an idea of the number of hops between my local machine and the VM over the 2 different connections) I have attached the output of my two traceroute's. While i am able to reach the exact VM when i am on one internet connection, i am not able to do the same, when am over the other internet connection. Both are broadband connections out of the same office premises. Any idea what could be happening? Thanks, Glen
Strange traceroute result to VM in EC2, Singapore
Hi, I have two internet connections and can reach the VM in EC2, Singapore over either connection. I am doing an experiment for which I traceroute to this VM from the two different internet connections (to really get an idea of the number of hops between my local machine and the VM over the 2 different connections) I have attached the output of my two traceroute's. While i am able to reach the exact VM when i am on one internet connection, i am not able to do the same, when am over the other internet connection. Both are broadband connections out of the same office premises. Any idea what could be happening? Thanks, Glen
Re: Strange traceroute result to VM in EC2, Singapore
Really sorry. Didnt realize that this is a text-only forum. When my traceroute to 52.74.124.136 works: ~$ traceroute 52.74.124.136 traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets 1 xxx xxx 0.412 ms 0.472 ms 0.439 ms 2 xxx xxx 2.98 ms 2.971 ms 2.999 ms 3 xxx xxx 5.345 ms 5.546 ms 5.519 ms 4 xxx xxx 3.172 ms 3.051 ms 3.010 ms 5 if-6-2.tcore2.SVW-Singapore.as6543.net (180.87.37.14) 56.751 ms 56.285 ms 54.592 ms 6 180.87.15.206 (180.87.15.206) 73.468ms 66.993 ms 66.734 ms 7 203.83.223.58 (203.83.223.58) 43.737 ms 43.513 ms 44.029 ms 8 203.83.223.15 (203.83.223.15) 47.239 ms 46.382 ms 203.83.223.74 (203.83.223.74) 44.144 ms 9 203.83.223.231 (203.83.223.231) 44.431 ms 203.83.223.233 (203.83.223.233) 45.699 ms 46.158 ms 10 ec2-52-74-124-136.ap-southeast-1.compute.amazon.com (52.74.124.136) 44.067 ms 43.492 ms 43.499 ms When it doesnt: ~$ traceroute 52.74.124.136 traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets 1 xxx xxx 23.272 ms 25.011 ms 26.072 ms 2 xxx xxx 27.058 ms 28.971 ms 29.999 ms 3 xxx xxx 33.025 ms 33.996 ms 38.822 ms 4 p38895.sgw.equinix.com (202.79.197.87) 78.964 ms 60.051 ms 83.010 ms 5 203.83.223.4 (203.83.223.4) 63.682 ms 64.610 ms 65.837 ms 6 203.83.223.17 (203.83.223.17) 67.271 ms 203.83.223.23 (203.83.223.23) 68.521 ms 203.83.223.17 (203.83.223.17) 70.526 ms 7 203.83.223.233 (203.83.223.233) 71.624 ms 72.805 ms 74.471 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
Re: Strange traceroute result to VM in EC2, Singapore
I find this bizzare because even when the traceroute doesnt work, I am actually able to ping and access the machine. I know that the VM responds to traceroutes, since it did respond to my traceroute when i was on the other broadband network. So i really fail to understand why the traceroute on the other network failed. Any pointers on this would be very helpful. Thanks, GLen On Thu, Aug 6, 2015 at 8:53 PM, Glen Kent glen.k...@gmail.com wrote: Really sorry. Didnt realize that this is a text-only forum. When my traceroute to 52.74.124.136 works: ~$ traceroute 52.74.124.136 traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets 1 xxx xxx 0.412 ms 0.472 ms 0.439 ms 2 xxx xxx 2.98 ms 2.971 ms 2.999 ms 3 xxx xxx 5.345 ms 5.546 ms 5.519 ms 4 xxx xxx 3.172 ms 3.051 ms 3.010 ms 5 if-6-2.tcore2.SVW-Singapore.as6543.net (180.87.37.14) 56.751 ms 56.285 ms 54.592 ms 6 180.87.15.206 (180.87.15.206) 73.468ms 66.993 ms 66.734 ms 7 203.83.223.58 (203.83.223.58) 43.737 ms 43.513 ms 44.029 ms 8 203.83.223.15 (203.83.223.15) 47.239 ms 46.382 ms 203.83.223.74 (203.83.223.74) 44.144 ms 9 203.83.223.231 (203.83.223.231) 44.431 ms 203.83.223.233 (203.83.223.233) 45.699 ms 46.158 ms 10 ec2-52-74-124-136.ap-southeast-1.compute.amazon.com (52.74.124.136) 44.067 ms 43.492 ms 43.499 ms When it doesnt: ~$ traceroute 52.74.124.136 traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets 1 xxx xxx 23.272 ms 25.011 ms 26.072 ms 2 xxx xxx 27.058 ms 28.971 ms 29.999 ms 3 xxx xxx 33.025 ms 33.996 ms 38.822 ms 4 p38895.sgw.equinix.com (202.79.197.87) 78.964 ms 60.051 ms 83.010 ms 5 203.83.223.4 (203.83.223.4) 63.682 ms 64.610 ms 65.837 ms 6 203.83.223.17 (203.83.223.17) 67.271 ms 203.83.223.23 (203.83.223.23) 68.521 ms 203.83.223.17 (203.83.223.17) 70.526 ms 7 203.83.223.233 (203.83.223.233) 71.624 ms 72.805 ms 74.471 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
UDP clamped on service provider links
Hi, Is it true that UDP is often subjected to stiffer rate limits than TCP? Is there a reason why this is often done so? Is this because UDP is stateless and any script kiddie could launch a DOS attack with a UDP stream? Given the state of affairs these days how difficult is it going to be for somebody to launch a DOS attack with some other protocol? Glen
Predicting TCP throughput
Hi, I am looking at deterministic ways (perhaps employing data science) to predict TCP throughput that i can expect between two end points. I am using the latency (RTT) and the packet loss as the parameters. Is there anything else that i can use to predict the throughput? A related question to this is; If i see an RTT of 150ms and packet loss of 0.01% between points A and B and the maximum throughput then between these as, say 250Mbps. Then can i say that i will *always* get the same (or in a close ballpark) throughput not matter what time of the day i run these tests. My points A and B can be virtual machines spawned on two different data centers, say Amazon Virgina and Amazon Tokyo? So we're talking about long distances here. What else besides the RTT and packet loss can affect my TCP throughput between two end points. I am assuming that the effects of a virtual machine overload would have direct bearing on the RTT and packet loss, and hence should cancel out. What i mean by this is that even if a VM is busy, then that might induce larger losses and increased RTT, and that would affect my TCP throughput. But then i already know what TCP throughput i get when i have a given RTT and loss, and hence should be able to predict it. Is there something that i am missing here? Thanks, Glen
Re: Interesting BFD discussion on reddit
http://www.ietf.org/proceedings/90/agenda.html - MPLS WG was heldin Sovereign on 4th March @ 1300-1400 http://www.ietf.org/audio/ietf89/ will you the audio recording for this talk. From the MOM http://www.ietf.org/proceedings/89/minutes/minutes-89-mpls its clear that there is no disagreement about NOT doing BFD authentication in hardware -- similar to what is claimed by the presenter. I think the hardware used was Broadcom. They have a few chipsets which do MD5 and (possibly) SHA in hardware for BFD -- which i have been told is pretty much useless when you start scaling. Glen On Mon, Feb 16, 2015 at 8:20 PM, Eygene Ryabinkin r...@grid.kiae.ru wrote: Mon, Feb 16, 2015 at 08:55:17AM +0530, Glen Kent wrote: I wonder if Trio, EZChip and friends could do SHA in NPU, my guess is yes they could, but perhaps there is even more appropriate hash for this use-case. I'm not entirely convinced doing hash for each BFD packet is impractical. [0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt You might want to take a look at: http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf Look at the slides 11 onwards. Were these people doing some real implementation in-hardware or were just theoretizing? I see prediction label for the number of authenticated sessions -- do you have an idea what that means? And on slide 14 you have smaller session limit numbers for BFD fully implemented in hardware than for hw-assisted case (slide 12). It makes me think that this presentation should either be supplemented with talking people or there are some errors in it. Or I am completely missing some fine point here. Doing HMAC calculation for each packet adversely affects the number of concurrent sessions that can be supported. Without mentioning the scope (which hardware and software) this assertion is either trivial or useless, sorry. TSO, frame checksums and other stuff hadn't been implemented in-hardware for ages, but now it is here and there all the time. And /me is interested why can't BFD be done on the interface chip level: it is point-to-point on L2 for the majority of cases. -- Eygene Ryabinkin, National Research Centre Kurchatov Institute Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Low BW between Mountain View and OR -- why?
Hi, I have a server in Mountain View and i am doing a speedtest with a server in Oregon. I see that the upload/download BW that i am getting is low -- around 10.0Mbps and 5.0Mbps. gkent@ubuntu:~/ics$ speedtest-cli --server 4082 Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Comcast Cable (50.250.251.210)... Hosted by Eastern Oregon Net, Inc. (La Grande, OR) [913.33 km]: 120.959 ms Testing download speed Download: 5.08 Mbits/s Testing upload speed.. Upload: 10.89 Mbits/s When i check my connectivity with a server in NYC, its much better, though the server is much further away. gkent@ubuntu:~/ics$ speedtest-cli --server 2947 Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Comcast Cable (50.250.251.210)... Hosted by Atlantic Metro (New York City, NY) [4129.02 km]: 307.568 ms Testing download speed Download: 38.52 Mbits/s Testing upload speed.. Upload: 10.62 Mbits/s I am trying to understand why this is so? I would wager that NYC being further away would give me a worse throughput than OR, but the speedtest tells me otherwise. The 2nd and more puzzling observation is that while OR is giving a download of around 5.08Mbps, it will improve and become much better later in the day. There are times when i see it going up as high as 48Mbps. Sometimes while a transfer is in progress i see that my download suddenly goes down from 48Mbps to 2Mbps. Can somebody here tell me why such a drastic fluctuation is seen? Thanks, Glen
Re: Interesting BFD discussion on reddit
I wonder if Trio, EZChip and friends could do SHA in NPU, my guess is yes they could, but perhaps there is even more appropriate hash for this use-case. I'm not entirely convinced doing hash for each BFD packet is impractical. [0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt You might want to take a look at: http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf Look at the slides 11 onwards. Doing HMAC calculation for each packet adversely affects the number of concurrent sessions that can be supported. Glen. -- ++ytti
link monitoring and BFD in SDN networks
Hi, Routers connected back to back often rely on BFD for link failures. Its certainly possible that there is a switch between two routers and hence a link down event on one side is not visible to the other side. So, you run some sort of an OAM protocol on the two routers so that they can detect link flaps/failures. How will this happen in SDN networks where there is no control plane on the routers. Will the routers be sending a state of all their links to a central controller who will then detect that a link has gone down. This just doesnt sound good. I am presuming that some sort of control plane will always be required. Any pointers here? Is there any other reason other than link events for which we would need a control plane on the routers in SDN? Thanks, Glen
Overlay as a link
Hi, When youre doing overlay networking, i.e., you have tunnels from one virtual machine in a DC to another in another DC, then can i consider a tunnel between the two virtual machines as a physical link that exists in a regular network? I am wondering on what possibly can be the difference between a tunnel being considered as a link and a true physical link. I could run routing algorithms on both. The tunnel would only be considered as an interface. Or i could run BFD on both. Once difference that i can think of is that while you can send multiple frames together on a tunnel (for example if there are ECMP paths within the tunnel), you may not be able to send multiple frames at the same time on a physical link. Anything else? Glen
Heartbleed Bug Found in Cisco Routers, Juniper Gear
http://online.wsj.com/news/articles/SB10001424052702303873604579493963847851346 Glen
Re: Heartbleed Bug Found in Cisco Routers, Juniper Gear
Either way, as I've said before, if you're exposing *any* management interfaces, be is ssh,netconf or https to the internet in general, you've got bigger issues than just heartbleed. Sure, i agree. VPN, on the other hand, is a totally different world of pain for this issue. What about VPNs? Glen /ruairi On 11 April 2014 12:24, Glen Kent glen.k...@gmail.com wrote: http://online.wsj.com/news/articles/SB10001424052702303873604579493963847851346 Glen
Sudan disconnected from the Internet
Hi, The report from renesys states that We initially stated that Sudan’s outage began at 12:47 UTC because that was when virtually all Sudanese routed networks were withdrawn from the global routing table http://www.renesys.com/2013/09/internet-blackout-sudan/ If its a deliberate action to remove Sudan from the Internet then what exactly would the ISPs in Sudan have done? Drop their peering sessions with the three International gateways? How were the Sudanese routed networks withdrawn? Glen
Re: Sudan disconnected from the Internet
Thats disappointing. I was imagining some networking trick with which Sudan was being disconnected (prefix hijacking, etc) - didnt strike me that this was also an option available! :-) On Thu, Sep 26, 2013 at 6:10 AM, Tammy Firefly tammy-li...@wiztech.bizwrote: On 9/25/13 18:38:09, Warren Bailey wrote: http://abcnews.go.com/International/wireStory/sudan-security-clashes-subsid y-protesters-20360418 On 9/25/13 5:34 PM, Tammy Firefly tammy-li...@wiztech.biz wrote: On 9/25/13 18:29:58, Jeff Kell wrote: On 9/25/2013 8:25 PM, Tammy Firefly wrote: with the old fashioned pair of diagonal cutters applied to fiber? Yes, interesting to know if it was cut fiber, pressure on the inside providers (or their feeds), or pressure on the outside providers. Traceroutes lend any clue? Jeff If the government did it, I guarantee it was cut fiber. That makes it difficult to quickly restore. One has to wonder whats going on there right now that they dont want the world to know about? Then its quite likely the government cut the fiber to cover that up :) wouldnt surprise me if they cut it in multiple places as well.
Re: iOS 7 update traffic
Picked this off www.jaluri.com (network and Cisco blog aggregator): http://routingfreak.wordpress.com/2013/09/23/ios7s-impact-on-networks-worldwide/ The consensus seems to be for providers to install CDN servers, if they arent able to cope up with an occasional OS update traffic. While his argument for installing CDNs is not entirely incorrect, you should take it with a pound of salt, as the author works for a CDN vendor! :-) http://blog.streamingmedia.com/2009/07/alcatellucent-acquires-cdn-technology-provider-velocix.html
Re: iOS 7 update traffic
One of the earlier posts seems to suggest that if iOS updates were cached on the ISPs CDN server then the traffic would have been manageable since everybody would only contact the local sever to get the image. Is this assumption correct? Do most big service providers maintain their own content servers? Is this what we're heading to these days? Glen On Mon, Sep 23, 2013 at 4:29 PM, Neil Harris n...@tonal.clara.co.uk wrote: On 23/09/13 10:32, John Smith wrote: Picked this off www.jaluri.com (network and Cisco blog aggregator): http://routingfreak.wordpress.**com/2013/09/23/ios7s-impact-** on-networks-worldwide/http://routingfreak.wordpress.com/2013/09/23/ios7s-impact-on-networks-worldwide/ The consensus seems to be for providers to install CDN servers, if they arent able to cope up with an occasional OS update traffic. http://news.idg.no/cw/art.cfm?**id=391B4B64-F693-41B7-**6BBAC6D7017C3B8Ahttp://news.idg.no/cw/art.cfm?id=391B4B64-F693-41B7-6BBAC6D7017C3B8A John Perhaps Apple, Microsoft etc. should consider using Bittorrent as a way of distributing their updates? If ISPs were to run their own Bittorrent servers (with appropriate restrictions, see below), this would then create an instant CDN, with no need to define any other protocols or pay any third parties. The hard bit would be to create a way for Apple etc. to be able to authoritatively say we are the content owners, and are happy for you to replicate this locally: but perhaps this could be as simple serving the initial seed from an HTTPS server with a valid certificate? It would then be trivial to create a whitelist of the domains of the top 10 or so distributors of patches, and then everything would work automatically from then on. -- N.
Re: iOS 7 update traffic
BTW Linux distributions are available to download via bittorrent, so we dont really need Akamai/Limelight here. Is there a reason why Apple has not adopted bit-torrent for distribution? Are there legal/commercial implications using bit-torrent? Glen On Mon, Sep 23, 2013 at 4:29 PM, Neil Harris n...@tonal.clara.co.uk wrote: On 23/09/13 10:32, John Smith wrote: Picked this off www.jaluri.com (network and Cisco blog aggregator): http://routingfreak.wordpress.**com/2013/09/23/ios7s-impact-** on-networks-worldwide/http://routingfreak.wordpress.com/2013/09/23/ios7s-impact-on-networks-worldwide/ The consensus seems to be for providers to install CDN servers, if they arent able to cope up with an occasional OS update traffic. http://news.idg.no/cw/art.cfm?**id=391B4B64-F693-41B7-**6BBAC6D7017C3B8Ahttp://news.idg.no/cw/art.cfm?id=391B4B64-F693-41B7-6BBAC6D7017C3B8A John Perhaps Apple, Microsoft etc. should consider using Bittorrent as a way of distributing their updates? If ISPs were to run their own Bittorrent servers (with appropriate restrictions, see below), this would then create an instant CDN, with no need to define any other protocols or pay any third parties. The hard bit would be to create a way for Apple etc. to be able to authoritatively say we are the content owners, and are happy for you to replicate this locally: but perhaps this could be as simple serving the initial seed from an HTTPS server with a valid certificate? It would then be trivial to create a whitelist of the domains of the top 10 or so distributors of patches, and then everything would work automatically from then on. -- N.
Re: OSPF Vulnerability - Owning the Routing Table
I was forwarded a link to a blog post that vividly describes the attack. Sharing it with others in case they're interested .. http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerability-exposed-by-black-hat/ Glen On Fri, Aug 2, 2013 at 10:10 PM, Glen Kent glen.k...@gmail.com wrote: Hi, Does anybody have details on what this vulnerability is? https://www.blackhat.com/us-13/briefings.html#Nakibly Glen
OSPF Vulnerability - Owning the Routing Table
Hi, Does anybody have details on what this vulnerability is? https://www.blackhat.com/us-13/briefings.html#Nakibly Glen
Egress filters dropping traffic
Hi, Under what scenarios do providers install egress ACLs which could say for eg. 1. Allow all IP traffic out on an interface foo if its coming from source IP x.x.x.x/y 2. Drop all other IP traffic out on this interface. Glen
Re: Need help in flushing DNS
Hi, Do we know which DNS server started leaking the poisoned entry? Being new to this, i still dont understand how could a hacker gain access to the DNS server and corrupt the entry there? Wouldnt it require special admin rights, etc. to log in? Glen On Thu, Jun 20, 2013 at 11:32 AM, Paul Ferguson fergdawgs...@gmail.comwrote: Hanlon's razor? Misconfiguration. Perhaps not done in malice, but I have no idea where the poison leaked in, or why. :-) - ferg On Wed, Jun 19, 2013 at 10:49 PM, Alex Buie alex.b...@frozenfeline.net wrote: Anyone have news/explanation about what's happening/happened? On Wed, Jun 19, 2013 at 10:34 PM, Paul Ferguson fergdawgs...@gmail.com wrote: Sure enough: ; DiG 9.7.3 @localhost yelp.com A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53267 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;yelp.com. IN A ;; ANSWER SECTION: yelp.com. 300 IN A 204.11.56.20 ;; Query time: 143 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 20 07:33:13 2013 ;; MSG SIZE rcvd: 42 NetRange: 204.11.56.0 - 204.11.59.255 CIDR: 204.11.56.0/22 OriginAS: AS40034 NetName: CONFLUENCE-NETWORKS--TX3 NetHandle: NET-204-11-56-0-1 Parent: NET-204-0-0-0-0 NetType: Direct Allocation Comment: Hosted in Austin TX. Comment: Abuse : Comment: ab...@confluence-networks.com Comment: +1-917-386-6118 RegDate: 2012-09-24 Updated: 2012-09-24 Ref: http://whois.arin.net/rest/net/NET-204-11-56-0-1 OrgName: Confluence Networks Inc OrgId: CN Address: 3rd Floor, Omar Hodge Building, Wickhams Address: Cay I, P.O. Box 362 City: Road Town StateProv: Tortola PostalCode: VG1110 Country: VG RegDate: 2011-04-07 Updated: 2011-07-05 Ref: http://whois.arin.net/rest/org/CN OrgAbuseHandle: ABUSE3065-ARIN OrgAbuseName: Abuse Admin OrgAbusePhone: +1-917-386-6118 OrgAbuseEmail: ab...@confluence-networks.com OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3065-ARIN OrgNOCHandle: NOCAD51-ARIN OrgNOCName: NOC Admin OrgNOCPhone: +1-415-462-7734 OrgNOCEmail: n...@confluence-networks.com OrgNOCRef: http://whois.arin.net/rest/poc/NOCAD51-ARIN OrgTechHandle: TECHA29-ARIN OrgTechName: Tech Admin OrgTechPhone: +1-415-358-0858 OrgTechEmail: ipad...@confluence-networks.com OrgTechRef: http://whois.arin.net/rest/poc/TECHA29-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # - ferg On Wed, Jun 19, 2013 at 10:30 PM, Grant Ridder shortdudey...@gmail.com wrote: Yelp is evidently also affected On Wed, Jun 19, 2013 at 10:19 PM, John Levine jo...@iecc.com wrote: Reaching out to DNS operators around the globe. Linkedin.com has had some issues with DNS and would like DNS operators to flush their DNS. If you see www.linkedin.com resolving NS to ns1617.ztomy.com or ns2617.ztomy.com then please flush your DNS. Any other info please reach out to me off-list. While you're at it, www.usps.com, www.fidelity.com, and other well known sites have had DNS poisoning problems. When I restarted my cache, they look OK. -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.com
ISIS and OSPF together
Hi, I would like to understand the scenarios wherein the service provider/network admin might run both ISIS and OSPF together inside their network. Is this something that really happens out there? One scenario that i can think of when somebody might run the 2 protocols ISIS and OSPF together for a brief period is when the admin is migrating from one IGP to the other. This, i understand never happens in steady state. The only time this can happen is if an AS gets merged into another AS (due to mergers and acquisitions) and the two ASes happen to run ISIS and OSPF respectively. In such instances, there is a brief period when two protocols might run together before one gets turned off and there is only one left. The other instance would be when say OSPF is used to manage the OOB network and the ISIS is used for network reachability. Is there any other scenario? Glen
Re: ISIS and OSPF together
Victor, Folks could, at least theoretically, use ISIS or OSPF multi instance/multi topology extensions to support IPv4 and IPv6 topologies. This way they would only need to run a single protocol and thereby requiring expertise in handling only one protocol. With whatever i remember, OSPFv3 can be used to support IPv4 as well - so folks could also use OSPFv3 when they want to support both IPv4 and IPv6. Glen On Sun, May 12, 2013 at 6:17 PM, Victor Kuarsingh vic...@jvknet.com wrote: Glen, One transition scenario you noted below is often a use case. I have seen networks move from OSPF to IS-IS (more cases then the reverse). In those cases, the overlap period may not be very short (years vs. weeks/months). I have also seen some use one protocol (which I think was mentioned in another response) used for IPv4 and another used for IPv6. The cases I am familiar, tended to be IPv6 with IS-IS and IPv4 with OSPFv2. I guess the reasoning here was that if you are running dual stack, with OSPF you will need to run two protocols anyway, so running OSPFv2(IPv3) and OSPFv3(IPv6) may not be that different then running OSPFv2(IPv4) with IS-IS(IPv6). This dual stack option has run longer or is semi-permanent at times. A sub-case to the above may also be that one (operator) may want to leverage some of capabilities of IS-IS and may not be willing to get off OSPF for some reason. The Multi-topology option in IS-IS may be quite useful if you have some functions which are non-congruent in your network and you want to maintain topology variations (multicast being one, or in-band management which I believe was alluded to in your OOB use case) Regards, Victor K On 2013-05-12 4:41 AM, Glen Kent glen.k...@gmail.com wrote: Hi, I would like to understand the scenarios wherein the service provider/network admin might run both ISIS and OSPF together inside their network. Is this something that really happens out there? One scenario that i can think of when somebody might run the 2 protocols ISIS and OSPF together for a brief period is when the admin is migrating from one IGP to the other. This, i understand never happens in steady state. The only time this can happen is if an AS gets merged into another AS (due to mergers and acquisitions) and the two ASes happen to run ISIS and OSPF respectively. In such instances, there is a brief period when two protocols might run together before one gets turned off and there is only one left. The other instance would be when say OSPF is used to manage the OOB network and the ISIS is used for network reachability. Is there any other scenario? Glen
SDN - Killer Apps
Hi, I am trying to understand how SDNs can dramatically change the networking paradigm and this is my understanding. Yahoo, Google, etc applications are running on one server and each application could be theoretically associated with a unique VXLAN tag. This way service providers will be able to provide QoS per application (by effectively providing QoS to the VXLAN carried in the pkts). So now Youtube for example, can get unique QoS treatment from our desktops to the edge of the network. Form there on core routing will pick up - which remains largely unaffected by VXLANs. OpenFlow is useful because it provides a common CLI/SNMP with which all routers from all vendors can be provisioned and monitored. As an example, VPLS configuration in Juniper, CIsco and AlaLu routers will be very different. So, provisioning a VPLS service in a network that comprises of these 3 vendors would require the admins to know the CLIs of all these routers. If these routers support OpenFlow, then theoretically, one configuration would work on all routers. OpenFlow would like say Provision a LSP and each router will internally provision an LSP. The admin remains oblivious to the internal CLIs of these boxes. The SDN controller is a SW that can again theoretically be made aware of the entire network. It can look at SNMP traps, etc and can figure out the exact topology of the network. Based on the SNMP traps, messages it can determine all failures in the network. It can run routing protocol simulations and figure out the best topology in the network. This can, using OpenFlow, be programmed on all routers. So, all heavy CPU processing task is taken over by the SDN controller. The controller can also take in requests on what network aware applications require and feed that to the routers/switches in the network and thus you have an application aware network provisioned. I understand that this is just some bit of what we can do with SDN. The amount of what all can be done is limitless. So, a question to all out there - Is my understanding of what can be achieved with SDN, is correct? Glen
25Mbps vs 4 Mbps
Hi, The service provider(s) pipe that takes all web traffic from my laptop to the central servers (assume youtube) remain same whether i take a 4Mbps or a 25Mbps connection from my service provider. This means that the internet connection that i take from my service provider only affects the last mile -- from my home network to my service providers first access router. Given this, would one really see a 6 times improvement in a 25Mbps connection over a 4Mbps connection? I assume that the service providers rate limit the traffic much more aggressively in a 4Mbps connection. But this would only matter if the traffic from my youtube server is greater than 4Mbps, which i suspect would be the case. The question then is that how does going for a higher BW connection from the service provider help? Glen
Re: Optimal IPv6 router
On Mon, Feb 6, 2012 at 1:04 PM, Daniel Roesen d...@cluenet.de wrote: On Sun, Feb 05, 2012 at 09:07:57PM -0500, valdis.kletni...@vt.edu wrote: OK, I'll bite. What would qualify as a native IPv6 router? Perhaps those which were designed with IPv4+IPv6 in mind from day 1, both in hardware and software - like Juniper/JUNOS. In contrast to other Not just that. I had meant that the HW is optimized for IPv6 and also as a side effect does IPv4. This router could be designed assuming that you'll have more IPv6 traffic to forward than IPv4. the gear where IPv6 was always an aftermath, which shows in both hardware (limits of performance, functionality and scaling) as well as software (every feature gets implemented twice, even if the feature itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment on XR]). Yes, thats what i had in mind. One example that comes to my mind is that a few existing routers cant do line rate routing for IPv6 traffic as long as the netmask is 65. Also routers have a limited TCAM size for storing routes with masks 64. These routers were primarily designed for IPv4 and also support IPv6. I was wondering what we could optimize on if we only design an IPv6 router (assume an extreme case where it does not even support IPv4). Glen Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Optimal IPv6 router
Hi, Most routers today are basically IPv4 routers, with IPv6 thrown in. They are however designed keeping IPv4 in mind. With IPv6 growing, if we were to design a native IPv6 router, with IPv4 functionality thrown in, then is it possible to design a more optimal IPv6 router, than what exists today? Glen
Re: Does anybody out there use Authentication Header (AH)?
(Sigh) Here we go again. AH is a liability and a baggage that we're carrying over our weary shoulders. IMO we should have gotten rid of it long time back. There have been enough emails on multiple forums over this and google is probably your friend here. The only reason(s) we have AH is because (i) circa early 1990s, US had export restrictions on encryption keys 40 bits and ESP thus had restrictions on how it could be used. AH otoh, only did authentication, for which the rules were much more relaxed AND (ii) people earlier naively believed that AH protected the IP header and ESP couldnt. AH is a mess if you have NATs deployed, as AH breaks NAT. IPv6 proponents thus saw AH as a tool to push IPv6, since they hated NATs (till someone discovered IPv6 NAT-PT, but thats a different story). Most people think ESP as encryption - they forget that it can be used for data integrity verification without encryption as well. Glen On Mon, Jan 2, 2012 at 5:42 AM, John Smith jsmith4112...@yahoo.co.uk wrote: Hi, I am trying to see if there are people who use AH specially since RFC 4301 has a MAY for AH and a MUST for ESP-NULL. While operators may not care about a MAY or a MUST in an RFC, but the IETF protocols and vendors do. So all protocols that require IPsec for authentication implicitly have a MAY for AH and a MUST for ESP-NULL. Given that there is hardly a difference between the two, I am trying to understand the scenarios where people might want to use AH? OR is it that people dont care and just use what their vendors provide them? Regards, John
Re: Does anybody out there use Authentication Header (AH)?
On Mon, Jan 2, 2012 at 6:27 AM, Chuck Anderson c...@wpi.edu wrote: I'm using AH for OSPFv2 and OSPFv3 authentication. For OSPFv3, there is no other option than some kind of IPsec for authentication. I'm also using it for OSPFv2 so I don't have to maintain multiple authentication methods and keys for the different protocols. OSPF WG has come out with a mechanism that can be used to secure OSPFv3 without IPsec - http://tools.ietf.org/html/draft-ietf-ospf-auth-trailer-ospfv3-11 It should get published as an RFC any time now. BTW, there isnt any standard for using IPsec with OSPFv2, so youre probably using a proprietary solution. I think a better solution is to move to OSPFv3-AT, as its very similar to OSPFv2 authentication. Glen
Re: subnet prefix length 64 breaks IPv6?
Most vendors have a TCAM that by default does IPv6 routing for netmasks =64. They have a separate TCAM (which is usually limited in size) that does routing for masks 64 and =128. TCAMs are expensive and increase the BOM cost of routers. Storing routes with masks 64 takes up twice the number of TCAM entries as the routes with masks = 64. Since IPv6 is *supposed* to work with /64 masks, most vendors (usually the not-so-expensive-routers) provide a smaller TCAM for /64 masks. Glen On Wed, Dec 28, 2011 at 6:40 PM, sth...@nethelp.no wrote: On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on /64 is somewhat less efficient. Can you please name names for the somewhat less efficient part? I've seen this and similar claims several times, but the lack of specific information is rather astounding. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: subnet prefix length 64 breaks IPv6?
So a typical forwarding step is already a two step process: Look up variable length prefix to get next hop. Look up 128 bit next hop to get forwarding information. Wrong. You only do a lookup once. You look up a TCAM or a hash table that gives you the next hop for a route. You DONT need to do another TCAM lookup to get the egress encapsulation information. You get the egress encapsulation after your TCAM lookup. It typically gives you an index that stores this information. All routes pointing to one nexthop will typically point to the same index. Once the vendor has built a 128-bit TCAM for step #2, there's no reason not to use it for step #1 as well. AFAIK, in all recent products this is how all vendors handle the problem (at a high level). You only use the TCAM for #1, not for #2. Glen
Re: IPTV and ASM
SSM is also used since we *know* the IP addresses of the content servers that are the sources - You dont need ASM. I dont think maintaining RP infrastructure is trivial. Who wants to deal with register packets, etc. Small routers punt all registers to CPU and them forward them in SW. In fact there was a draft which proposed using MPLS encapsulation in networks that support MPLS to replace the existing RP mechanism. http://tools.ietf.org/html/draft-bhatia-pim-mpls-register-packets-00 From the draft: Encapsulation and Decapsulation are expensive operations for routers and the latter, especially, as it entails a double lookup that many routers cannot do in hardware. It is for this reason that several off the shelf chips do not support decapsulating the PIM Register packets. Any router that cannot decapsulate the PIM Register packet in hardware must send all this traffic to CPU, where its decapsulated, and forwarded based on the multicast forwarding table. This increases the load on the CPU and also makes the router susceptible for DoS attacks. Also, since Register packets are unicast, then can be easily spoofed and an attacker can use this to attack the router and thus the network. This document attempts to solve the above problems by doing away with the PIM Register packets. It instead proposes using an MPLS tunnel to send all multicast data traffic till an SPT is formed. This eliminates the complexity of decapsulating PIM register packets on the RP as it now only needs to pop off the MPLS labels before forwarding the native packet down the RPT. Looks like the draft died some time back .. Glen On Thu, Dec 29, 2011 at 5:02 AM, Jeff Tantsura jeff.tants...@ericsson.com wrote: Mike, To my knowledge in most today's networks even if legacy equipment don't support IGMPv3 most likely 1st hop router does static translation and SSM upstream. The reason not to migrate to SSM is usually - ASM is already there and works just fine :) Cost to support RP infrastructure is usually the main non-technical factor to not to use ASM. Would be interested to hear from the SPs on the list. Regards, Jeff On Dec 28, 2011, at 2:19 PM, Mike McBride mmcbri...@gmail.com wrote: Marshall, On Wed, Dec 28, 2011 at 1:50 PM, Marshall Eubanks marshall.euba...@gmail.com wrote: Dear Mike; On Wed, Dec 28, 2011 at 4:48 PM, Mike McBride mmcbri...@gmail.com wrote: Anyone using ASM (versus SSM) for IPTV? If so why? From what I understand, the answer is likely to be yes and the reason is likely to be deployed equipment only supports IGMP v2. Agreed. I'm seeking confirmation, from IPTV implementers, that non igmpv3 support is the reason for using ASM with IPTV. Versus other reasons such as reducing state. Or is this a non issue and everyone is using SSM with IPTV? thanks, mike Regards Marshall thanks, mike
Re: subnet prefix length 64 breaks IPv6?
It seems ISIS and OSPFv3 use the link local next-hop in their route advertisements. We discussed that SLAAC doesnt work with prefixes 64 on the ethernet medium (which i believe is quite, if not most, prevalent). If thats the case then how are operators who assign netmasks 64 use ISIS and OSPF, since these protocols will use the link local address? I had assumed that nodes derive their link local address from the Route Advertisements. They derive their least significant 64 bytes from their MACs and the most significant 64 from the prefix announced in the RAs. Glen On Tue, Dec 27, 2011 at 6:25 AM, Glen Kent glen.k...@gmail.com wrote: Sven, also various bgp implementations will send the autoconfigure crap ip as the next-hop instead of the session ip, resulting in all kinds of crap in your route table (if not fixed with nasty hacks on your end ;) which doesn't exactly make it easy to figure out which one belongs to which peer all the more reason not to use that autoconfigure crap ;) As per RFC 2545 BGP announces a global address as the next-hop. Its only in one particular case that it advertises both global and link local addresses. So, i guess, BGP is not broken. Its only RIPng afaik that mandates using a link local address. Glen
Re: subnet prefix length 64 breaks IPv6?
Sven, also various bgp implementations will send the autoconfigure crap ip as the next-hop instead of the session ip, resulting in all kinds of crap in your route table (if not fixed with nasty hacks on your end ;) which doesn't exactly make it easy to figure out which one belongs to which peer all the more reason not to use that autoconfigure crap ;) As per RFC 2545 BGP announces a global address as the next-hop. Its only in one particular case that it advertises both global and link local addresses. So, i guess, BGP is not broken. Its only RIPng afaik that mandates using a link local address. Glen
Re: subnet prefix length 64 breaks IPv6?
Hi Ray, prefixes on the same link. Choosing to make use of a 120-bit prefix (for example) will do nothing to protect against a rogue RA announcing its own 64-bit prefix with the A flag set. I could not find any A flag in the RA. Am i missing something? From http://www.iana.org/assignments/icmpv6-parameters: Registry: RA Option Bit Description Reference - --- - 0 M - Managed Address Configuration Flag [RFC2461] 1 O - Other Configuration Flag [RFC2461] 2 H - Mobile IPv6 Home Agent Flag [RFC3775] 3 Prf - Router Selection Preferences [RFC4191] 4 Prf - Router Selection Preferences [RFC4191] 5 P - Neighbor Discovery Proxy Flag[RFC4389] 6-53 R - Reserved; Available for assignment [RFC5175] 54-55 Private Experimentation [RFC5175] Glen
Re: subnet prefix length 64 breaks IPv6?
Ok. So does SLAAC break with masks 64? Glen On Sat, Dec 24, 2011 at 12:38 PM, sth...@nethelp.no wrote: I am not sure if this is the reason as this only applies to the link local IP address. One could still assign a global IPv6 address. So, why does basic IPv6 (ND process, etc) break if i use a netmask of say /120? As long as you assign addresses statically, IPv6 works just fine with a netmask 64. We've been using this for several years now. No problem. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: subnet prefix length 64 breaks IPv6?
SLAAC only works with /64 - yes - but only if it runs on Ethernet-like Interface ID's of 64bit length (RFC2464). Ok, the last 64 bits of the 128 bit address identifies an Interface ID which is uniquely derived from the 48bit MAC address (which exists only in ethernet). SLAAC could work ok with /65 on non-Ethernet media, like a point-to-point link whose Interface ID's length be negotiated during the setup phase. If we can do this for a p2p link, then why cant the same be done for an ethernet link? Glen Other non-64 Interface IDs could be constructed for 802.15.4 links, for example a 16bit MAC address could be converted into a 32bit Interface ID. SLAAC would thus use a /96 prefix in the RA and a 32bit IID. IP-over-USB misses an Interface ID altogether, so one is free to define its length. Alex Regards, K.
Re: IPv6 RA vs DHCPv6 - The chosen one?
If you get DNS servers from RA and from DHCP, throw them all in the candidate DNS server list. Unless something is broken, any one of them should work and provide the same answers as the others. You can't get NTP from SLAAC/RA, so, no conflict there. If the router and dhcp server administrators can't agree on the DNS search list, then, you're going to have some problems no matter what protocol you use, so, I really think this is a tempest in a teacup. You can get NTP from RA http://tools.ietf.org/html/draft-bcd-6man-ntp-server-ra-opt-00
subnet prefix length 64 breaks IPv6?
Hi, I am trying to understand why standards say that using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], .. [reference RFC 5375] Or A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes. Is it because the 128 bits are divided into two 64 bit halves, where the latter identifies an Interface ID which is uniquely derived from the 48bit MAC address. I am not sure if this is the reason as this only applies to the link local IP address. One could still assign a global IPv6 address. So, why does basic IPv6 (ND process, etc) break if i use a netmask of say /120? I know that several operators use /120 as a /64 can be quite risky in terms of ND attacks. So, how does that work? I tried googling but couldnt find any references that explain how IPv6 breaks with using a netmask other than 64. Glen
Re: IPv6 RA vs DHCPv6 - The chosen one?
In many environments RA is a catastrophic disaster. Some operators need to be able to do everything with RA turned off on routers, disabled on hosts and filtered on switches. While in some environments, typically with small number of devices, its indispensable. Small businesses may not want the complexity of setting up a central server (for DHCP) - SLAAC works very well in such environments. Today, we can get NTP server information only with DHCP (DNS info is supported by both DHCP and RAs). DHCP only works after RAs have been processed. In some environments (mobile IPv6) delays in acquiring NTP and other servers information is critical and waiting for DHCP to come up may not be acceptable. Glen
Re: IPv6 RA vs DHCPv6 - The chosen one?
When a router needs to learn information from another router it will *usually* use the RA messages and not DHCPv6, as the latter is *usually* meant for Router - Host communication. However, it is NOT uncommon to see hosts also learning the information using RA messages. Router's afaik dont usually act as DHCP clients and thus information that can only be passed in DHCPv6 may not be available to the routers, and you may need an alternate mechanism. Glen On Tue, Dec 20, 2011 at 11:57 AM, Ravi Duggal raviduggal2...@gmail.com wrote: Hi, IPv6 devices (routers and hosts) can obtain configuration information about default routers, on-link prefixes and addresses from Router Advertisements as defined in Neighbor Discovery. I have been told that in some deployments, there is a strong desire not to use Router Advertisements at all and to perform all configuration via DHCPv6. There are thus similar IETF standards to get everything that you can get from RAs, by using DHCPv6 instead. As a result of this we see new proposals in IETF that try to do similar things by either extending RA mechanisms or by introducing new options in DHCPv6. We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends DHCPv6 to do what RA does. And now, we have draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise the NTP information that is currently done via DHCPv6. My question is, that which then is the more preferred option for the operators? Do they prefer extending RA so that the new information loaded on top of the RA messages gets known in the single shot when routers do neighbor discovery. Or do they prefer all the extra information to be learnt via DHCPv6? What are the pros and cons in each approach and when would people favor one over the other? I can see some advantages with the loading information to RA since then one is not dependent on the DHCPv6 server. However, the latter provides its own benefits. Regards, Ravi D.
/128 IPv6 prefixs in the wild?
Hi, In the service provider networks, would we usually see a large number of /128 prefixs in the v6 FIB tables? In an IP/MPLS world, core routers in the service provider network learn the /32 loopback IPv4 addresses so that they can establish BGP/Targetted LDP sessions with those. They then establish LSPs and VPN tunnels. Since we dont have RSVP for IPv6 and LDP for IPv6 (not yet RFC) we cannot form MPLS tunnels in a pure IPv6 only network. GIven this, would v6 routers have large number of /128 prefixes? What are the scenarios when IPv6 routers would learn a large number of /128 prefixes? I would presume that most IPv6 prefixes that the routers have to install are less than /64, since the latter 64 is the host part. Is this correct? Glen
facebook spying on us?
Hi, I see that i have multiple TCP sessions established with facebook. They come up even after i reboot my laptop and dont login to facebook! D:\Documents and Settings\gkentnetstat -a | more Active Connections Proto Local Address Foreign AddressState TCPgkent:3974www-10-02-snc5.facebook.com:http ESTABLISHED TCPgkent:3977www-11-05-prn1.facebook.com:http ESTABLISHED TCPgkent:3665 a184-84-111-139.deploy.akamaitechnologies.com:http ESTABLISHED [clipped] Any idea why these connections are established (with facebook and akamaitechnologies) and how i can kill them? Since my laptop has several connections open with facebook, what kind of information is flowing there? I also wonder about the kind of servers facebook must be having to be able to manage millions of TCP connections that must be terminating there. Glen
Strange static route
Hi, I have seen a few operators adding static routes like: 0.0.0.0/1 some next-hop and 128.0.0.0/1 some next-hop. Why would anyone want to add such static routes? What does 0.0.0.0/1 mean. Note that the netmask is 1 and not 0. Thanks, Glen
EPC backhaul networks
Hi, I would like to understand why there is a preference for L3 VPNs over L2 VPNs for the EPC backhaul networks? We can use both layer 2 and layer 3 VPNs for communication between the eNodeB and the MME or S-GW, so why is it that most providers prefer L3 over L2. Glen
Impact of Attacks and Outages
Hi, Is there any paper/link that discusses the financial repercussions when an ISP's network goes down because of an attack/outage? What i am looking at is something that i can explain to a lay person, about why the networks need to remain secure so that they cant be hacked into, as once it comes down, not only does it impact the ISP but also the enterprises inside that service provider's domain. I tried googling but couldnt really come up with something. Any help in this regard would be really appreciated. Glen
Re: RIP Justification
RIP cannot also be used for traffic engineering; so if you want MPLS then you MUST use either OSPF or ISIS. RIP, like any other distance vector protocol, converges extremely slowly - so if you want faster convergence then you have to use one of ISIS or OSPF. Glen
IGMP and PIM protection
Hi, Any idea if folks use AH or ESP to protect IGMP/PIM packets? Wondering that if they do, then how would snooping switches work? Affably, Kent
Re: IGMP and PIM protection
Would encrypting multicast not fundamentally break the concept of multicast itself, unless you're encrypting multicast traffic over a backbone? No, i wasnt alluding to encrypting the multicast traffic. I was thinking of using ESP-NULL (AH is optional) for the IGMP/PIM packets. Affably, Kent
Re: IGMP and PIM protection
On Wed, Dec 23, 2009 at 7:46 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Dec 23, 2009, at 6:41 PM, Glen Kent wrote: Any idea if folks use AH or ESP to protect IGMP/PIM packets What are you trying to 'protect' them against? Just integrity protection to ensure that my reports, etc. are not mangled when i recv them. OR to make sure that i only receive reports/leaves from the folks who are supposed to send them. Please note that i am NOT interested in encrypting the control traffic. Kent --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: IGMP and PIM protection
Musing on the idea for a moment, it would surely be 'nice' to somehow know that PIM v2 joins from some other network were, in fact, 'good' or somehow well-formed, rate-limited, and/or somehow 'safe' to accept hold state for. However, it seems as if the OP isn't interested in inter-domain rp protection -- and probably more interested in authenticating more local igmp v2/3 joins for STB's and the like. Yup, i was currently looking at the IGMP v2/v3 joins only. Kent Glen, clarify? -Tk
Re: IGMP and PIM protection
I think OP meant that he only wants an integrity check of the control traffic, not confidentiality, hence the statement that he does not want to encrypt the control traffic. Yes, thats correct. Kent Stefan Fouant www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
Re: OSPF vs IS-IS vs PrivateAS eBGP
I seem to get the impression that isis is preferred in the core. Any reasons why folks dont prefer to go with ospf? Glen On Thu, Aug 20, 2009 at 3:36 PM, Randy Bush ra...@psg.com wrote: Unless you want your customers to have very substantial control over your internal network, don't use an SPF IGP like ospf or is-is. with your customer ^ i know that's what you meant, but i thought it worth making it very explicit. practice safe routing, do not share blood with customer. is-is in core with ibgp, and well-filtered ebgp (and packet filters a la bcp 38) to customers. randy
Re: AH or ESP
Just a quick question: Why do we need AH when we have ESP-NULL? Is AH now being supported only for legacy reasons? The only negative with ESP-NULL afaik was that it could not be filtered (since packets could not be inspected), however, this changes with the wesp proposal. Also, the fact that AH is NAT unfriendly should be the final nail in its coffin. Any reasons why we still see it around? Thanks, Glen On Tue, May 26, 2009 at 5:44 AM, Jack Kohn kohn.j...@gmail.com wrote: Not really. Currently, you cant even look at the ESP trailer to determine if its an encrypted or an integrity protected packet, because the trailer itself could be encrypted. A router, by reading the next-header field from the ESP trailer can never be sure that its an OSPFv3 packet inside since it wouldnt know whether the packet is encrypted or not. One could have an encrypted packet inside, for which the next-header field turns out to be 89, but that may not necessarily mean that its an OSPFv3 packet. It could be a VoIP packet that just happens to look like OSPFv3 once encrypted. There is no indication sent on the wire that says that the packet is encrypted. So, there is no way to identify/deep inspect/filter ESP packets unless you're the recipient, which imo is the root cause of all heart burn in the intermediate devices like firewalls, transit routers, etc. A couple of solutions were thrown at the WG and the current one (wesp) was selected as the best. I agree that we should just throw out AH and stick to one protocol which has been extensively tested. A quick scan through some of vendors data sheets quickly reveals that most of them dont even provide support for AH. Jack On Tue, May 26, 2009 at 2:33 AM, Merike Kaeo k...@merike.com wrote: Yeah - the main issue with using ESP is that there's a trailer at end of packet that tells you more info to determine whether you can inspect the packet. So you have to look at the end of the packet to see whether ESP is using encryption or null-encryption (i.e. just integrity protection). Some vendors do have proprietary mechanisms in software for now which doesn't scale. The work below will hopefully lock into a solution where hw can be built to quickly determine if ESP is used for integrity only. AH is not really widely used (except for OSPFv3 since early implementations locked in on AH when the standard said to use IPsec for integrity protection). Note that a subsequent standard now exists which explicitly states that ESP-Null MUST be supported and AH MAY be supported. But how many folks are actually running OSPF for a v6 environment and using IPsec to protect the communicating peers? Some but not many (yet). Personally, I'd stick with ESP. AH complicates matters (configuration, nested environments when you do decide to also use ESP for encryption maybe later, NAT) and while is isn't officially deprecated vendors don't test it as much as ESP - at interoperability tests it's not stressed, at least the ones I've been to. Ask your vendor(s) what they think of the work below and see where they stand with implementing it. Be happy to answer any more questions offline. - merike On May 25, 2009, at 6:24 AM, Jack Kohn wrote: Glen, IPSECME WG http://www.ietf.org/html.charters/ipsecme-charter.html at IETF is actually working on the exact issue that you have described (unable to deep inspect ESP-NULL packets). You can look at draft-ietf-ipsecme-traffic-visibility-02http://tools.ietf.org/html/ draft-ietf-ipsecme-traffic-visibility-02for more details. Jack On Sat, May 23, 2009 at 5:06 AM, Glen Kent glen.k...@gmail.com wrote: Yes, thats what i had meant ! On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, May 22, 2009 at 1:04 PM, Glen Kent glen.k...@gmail.com wrote: Hi, It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT 'the content of the esp packet can't be filtered in transit' I think you mean... right? interested in encrypting the data, but i do want origination authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given that both have some issues? Thanks, Glen
AH or ESP
Hi, It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT interested in encrypting the data, but i do want origination authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given that both have some issues? Thanks, Glen
Re: AH or ESP
Yes, thats what i had meant ! On Fri, May 22, 2009 at 10:46 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, May 22, 2009 at 1:04 PM, Glen Kent glen.k...@gmail.com wrote: Hi, It is well known in the community that AH is NAT unfriendly while ESP cannot be filtered, and most firewalls would not let such packets pass. I am NOT 'the content of the esp packet can't be filtered in transit' I think you mean... right? interested in encrypting the data, but i do want origination authentication (Integrity Protection). Do folks in such cases use AH or ESP-NULL, given that both have some issues? Thanks, Glen
Re: IPv6: IS-IS or OSPFv3
There is no fundamental difference between ISIS and OSPF; it's all in details and style. You might want to look at: http://www.nada.kth.se/kurser/kth/2D1490/06/hemuppgifter/bhatia-manral-diff-isis-ospf-01.txt.html Glen. On Sat, Dec 27, 2008 at 8:17 AM, devang patel devan...@gmail.com wrote: Hello, I do have some confusion about which one is better for IPv6 in Service Provider networks as far as IP routing and MPLS application is concern! 1. Which protocol should i use to support the IPv6 in network: ISIS or OSPFv3? As ISIS has multi-topology feature that can give us capability to run IPv4 network separate from IPv6 right! and same thing with OSPF: OSPFv2 will be used for IPv4 routing and OSPFv3 will be used for IPv6 routing! again Its look like resourceutilization for both the protocol will be same as they are going to use separate database for storing the routing or topology information. ISIS still has advantage over OSPF as it does use the TLV structure which can help in expanding network to support the new feature! 2. MPLS is not distributing label for IPv6 protocol so again there will not be any IGP best path calcuated for any MPLS related application for IPv6! 3. what if i have already running OSPFv2 for IPv4 in the network then should i think for migrating to ISIS? if yes then what are the advantages that I can look at for migrating my network to IS-IS? regards Devang Patel
Ixia, Juniper going green?
http://www.lightreading.com/document.asp?doc_id=166871 I wonder what impact this would put on other vendors to turn down their power consumptions and turn, as Juniper and Ixia like to put it - Green! BTW, the specs are a little skewed because they're only measuring power consumption when the router is only forwarding traffic, i.e., there is no traffic going to CPU. Also any idea about the genesis of this ECR initiative (http://www.ecrinitiative.org/) and what their eventual goal is ? Glen
Re: Ixia, Juniper going green?
Just saw www.vnl.in Agreed that they're not making routers, but if a base station can be made, then am sure some inroads can be made in data comm too .. ! Glen On Thu, Nov 6, 2008 at 6:22 AM, Justin M. Streiner [EMAIL PROTECTED] wrote: On Wed, 5 Nov 2008, Glen Kent wrote: http://www.lightreading.com/document.asp?doc_id=166871 I wonder what impact this would put on other vendors to turn down their power consumptions and turn, as Juniper and Ixia like to put it - Green! I do recall some people bashing Cisco products for their power consumption at a recent tech event I attended. Granted, that event was Juniper-centric :) Given the economic (rising power and cooling costs) and sometimes logistical (lack of power available in a facility) realities of operating networks and data centers, I'm sure everyone would love for their gear to draw less power. How many watts could actually be saved remains to be seen... jms
Re: NTP Md5 or AutoKey?
I dont think this is correct. I have seen routing protocol adjacencies going down because of some perturbations in NTP. I understand, any router implementation worth its salt would not use the NTP clock internally, but i have seen some real life issues where OSPF went down because the time moved ahead and it thought that it hadnt heard from the neighbor since a long time. All such bugs were eventually fixed, but this is just one example. There is an emerging need to distribute highly accurate time information over IP and over MPLS packet switched networks (PSNs). A variety of applications require time information to a precision which existing protocols cannot supply. TICTOC is an IETF WG created to develop solutions that meet the requirements of such protocols and applications. Glen On Tue, Nov 4, 2008 at 12:22 PM, [EMAIL PROTECTED] wrote: On Mon, 03 Nov 2008 22:23:07 PST, Paul Ferguson said: I'm just wondering -- in globak scheme of security issue, is NTP security a major issue? The biggest problem is that you pretty much have to spoof a server that the client is already configured to be accepting NTP packets from. And *then* you have to remember that your packets can only lie about the time by a very small number of milliseconds or they get tossed out by the NTP packet filter that measures the apparent jitter. Remember, the *real* clock is also sending correct updates. At *best*, you lie like hell, and get the clock thrown out as an insane timesource. But at that point, a properly configured clock will go on autopilot till a quorum of sane clocks reappears, so you don't have much chance of wedging in a huge time slew (unless you *really* hit the jackpot, and the client reboots and does an ntpdate and you manage to cram in enough false packets to mis-set the clock then). So in most cases, you can only push the clock around by milliseconds - and that doesn't buy you very much room for a replay attack or similar, because that's under the retransmit timeout for a lost packet. It isn't like you can get away with replaying something from 5 minutes ago. Now, if you wanted to be *dastardly*, you'd figure out where a site's Stratum-1 server(s) have their GPS antennas, and you'd read the recent research on spoofing GPS signals - at *that* point you'd have a good chance of controlling the horizontal and vertical
Re: NTP Md5 or AutoKey?
So, can i safely assume that nobody deployes Autokey security for NTP and the best that one does right now is by using the cryptographic authentication provided in the base spec of NTPv4. Cheers, Glen On Tue, Nov 4, 2008 at 11:59 AM, Kevin Oberman [EMAIL PROTECTED] wrote: Date: Mon, 3 Nov 2008 22:23:07 -0800 From: Paul Ferguson [EMAIL PROTECTED] On Mon, Nov 3, 2008 at 10:15 PM, Glen Kent [EMAIL PROTECTED] wrote: Hi, I was wondering what most folks use for NTP security? Do they use the low cost, light weight symmetric key cryptographic protection method using MD5 or do folks go in for full digital signatures and X.509 certificates (AutoKey Security)? I'm just wondering -- in globak scheme of security issue, is NTP security a major issue? Just curious. It's probably not a major issue, but forged NTP data can, in theory, be used to allow the implementation of replay attacks. I'll admit I have never heard of a real-world case. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: NTP Md5 or AutoKey?
My original question got drowned amidst all this vibrant discussions! Do folks already use or plan to use Autokey for NTP? Glen On Tue, Nov 4, 2008 at 4:00 PM, [EMAIL PROTECTED] wrote: On Mon, Nov 03, 2008 at 10:23:07PM -0800, Paul Ferguson wrote: On Mon, Nov 3, 2008 at 10:15 PM, Glen Kent [EMAIL PROTECTED] wrote: Hi, I was wondering what most folks use for NTP security? Do they use the low cost, light weight symmetric key cryptographic protection method using MD5 or do folks go in for full digital signatures and X.509 certificates (AutoKey Security)? I'm just wondering -- in globak scheme of security issue, is NTP security a major issue? Just curious. - ferg depends on your POV... in a dns context, TSIG and DNSSEC validation depend on accurate time - failure to resolve data because of a time slip might be considered a significantissue. --bill
Re: SMS Standards
Message delivery is best effort, so there are no guarantees that a message will actually be delivered to its recipient and delay or complete loss of a message is not uncommon, particularly when sending between networks. Users may choose to request delivery reports (simply add *0# or *N# to the beginning of your text message), which can provide positive confirmation that the message has reached the intended recipient. I tried adding a *0# to my SMS and i didnt receive any confirmation .. I particularly interested in knowing the frame encoding thats done to send a SMS. What are the control words that are sent along with an SMS, etc. What does one need to do if a standard is to be proposed. Is it like IETF where a draft is submitted, or is it something else. Any pointers to the appropriate mailing list? Regards, Glen
SMS Standards
Hi, Apologies in advance since this is off-topic. However, posting in on nanog since i am confident that we will have some experts who would be able to guide me here. I want to study the standards (RFC equivalent) for sending and receiving SMSs. Any ideas on what kind of protocol runs between a mobile phone and a SMS center (SMSC)? Thanks, Glen
Re: IP Fragmentation
I'm not sure how to address the above points since there appear to be some incorrect assumptions at play. It all depends on whether the Don't Fragment (DF) bit is set in IPv4 and how the source application responds to any resulting ICMP error responses (if the DF is set and one of the routes requires fragmentation). OK, so what happens if a transit router does not support IP fragmentation and it receives a packet which is bigger than the outgoing link's MTU. Should it simply drop the packet or proactively send an ICMP Dest Unreachable error (Frag required) to the peer? I understand that routers usually must send this error only when a fragmentation is required and they recieve a packet with DF bit set. However, in this case this router would drop the packet (for it doesnt support fragmentation) and sending an ICMP error back to the host, warning it that its packets will get dropped seems to be a better option. OTOH, what do most of the implementations do if they send a regular IP packet and receive an ICMP dest unreachable - Fragmentation reqd message back? Do they fragment this packet and then send it out, or this message is silently ignored? Glen
IP Fragmentation
Hi, Do transit routers in the wild actually get to do IP fragmentation these days? I was wondering if routers actually do it or not, because the source usually discovers the path MTU and sends its data with the least supported MTU. Is this true? Even if this is, then this would break for multicast IP. The source cannot determine which receivers would get interested in the traffic and what capacities the links connecting them would support. So, a source would send IP packets with some size, and theres a chance that one of the routers *may* have to fragment those IP packets before passing it on to the next router. I would wager that the vendors and operators would want to avoid IP fragmentation since thats usually done in SW (unless you've got a very powerful ASIC or your box is NP based). Thanks, Glen
Traceroute and random UDP ports
Hi, The outgoing packets from traceroute are sent towards the destination using UDP and very high port numbers, typically in the range of 32,768 and higher. This is because no one is gernally expected to run UDP services up there, so when the packet finally reaches the destination, traceroute can tell that it got to the end (because the ICMP changes from TTL exceeded to port unreachable). My question is: What if the receiver is actually listening on one of the random UDP ports? What would happen in such cases? Also, why do we increase the UDP port number with each subsequent traceroute packet that is sent? Thanks, Glen
