Re: What routers do folks use these days?
Am 29.11.2013 06:37, schrieb Jawaid Desktop: We're a service provider, and we have a network full of Cat6509's. We are finding that we are outgrowing them from the standpoint of their ability to handle lots of large routing tables. Obviously their switching capability is still superb but one of them with 20 peers is starting to groan a bit and RAM is going to be an issue soon. What do people use these days? Our backbone needs in the next 2-3 years are going to be sub-100Gbps. Check the Brocade MLXe series. We (Init7 / AS13030) are using them and the previous XMR series for years and are happy with it. CLI is Cisco-look-and-feel, the software tree has a clear structure (unlike Cisco with hundreds of versions) and the TAC is willing to ssh into your gear to assist. -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Twitter: @init7 / @kuenzler http://www.init7.net/ signature.asc Description: OpenPGP digital signature
Re: ATT UVERSE Native IPv6, a HOWTO
On Nov 28, 2013, at 1:07 PM, Leo Vegoda leo.veg...@icann.org wrote: Andrew D Kirch wrote: Was I the only one who thought that everything about this was great apart from this comment: In reality additional poking leads me to believe ATT gives you a rather generous /60 Is a /60 what is considered generous these days? I thought a /48 was considered normal and a /56 was considered a bit tight. What prefix lengths are residential access providers handing out by default these days? Regards, Leo Agreed… Unforutnately, the big guys (Comcast, ATT) in America seem to like victimizing their customers with undersized assignments, limiting choice of proper prefix sizes to only their business class customers. I’m not sure why they are doing this. I know when I’ve had conversations with them, they haven’t exactly given a reason so much as just said that they thought a /48 was ridiculous. Of course, if ATT is blocking protocol 41, that’s even worse, because at least so long as that isn’t blocked, you can still get an HE tunnel and get a /48 if you need it anyway. Owen
Re: ATT UVERSE Native IPv6, a HOWTO
I'd like to call everyone's attention to ARIN's policy on IPv6 transition space https://www.arin.net/policy/nrpm.html#six531 which was created specifically in response to the standardization of 6rd. The discussion at the time that this policy was under consideration was that encoding the [m,n] in a non-overlapping fashion when one has a bajillion allocations due to slow start was a pain in the butt and that, in practice, everyone would just encode 32 bits of IPv4 into 6rd. Note that it's possible to get a /24 of IPv6 space (huge!). Yes, it's from space that is tainted as being marked as transition space. Yes, you have to recertify that you're using it for the intended purpose every three years. Of course, 24 + 32 = 56. This is not an accident. It was our sense at the time that /56 was bad enough and that there was no reason to codify giving people an even more parsimonious slice of IPv6 space. So there really is no excuse on ATT's part for the /60s on uverse 6rd... -r
Re: ATT UVERSE Native IPv6, a HOWTO
De : Mikael Abrahamsson swm...@swm.pp.se A : Mark Andrews ma...@isc.org, You can hand out /48 as easily with 6rd as you can natively. As easily. It's easier to either hand out /64 by means of 1:1 mapping IPv4 and IPv6, or (if ability exists) hand out /48 or /56 using PD, than to get into the whole backend mess of having multiple 6RD domains with multiple configs per IPv4 subnet etc. I agree with you theoretically, but in practice I disagree. Some hard data points here, coming from one of the rare operator who actually deployed 6RD sub-domains to all its customers (to my knowledge). In practice, most 6RD implementations that support option 212 do support IPv4MaskLen properly these days. It wasn't the case 3 years ago, but we worked a lot with vendors to make it right. Seems ok now, we mostly have a 6RD population of D-Link and Cisco/Linksys. On the backend side, it's really not that bad. A one-page TCL handles around 15-16 sub-domains for us without noticeable impact on the DHCP servers CPU. Configuring the relays with all the tunnels can be a bit of fun playing with hex maths, but it's not too bad either. So I agree with Mark, it's not that complex. I can't agree with him on the prefix size though. We hand out /60s because we feel it's enough from a transition point of view (these are short-lived anyway) and offering a bigger size would really use too much space. Offering /48s out of a single /16 block, to take a simple example, would use a whole /32. This space wouldn't be used much anyway, given that most 6RD routers use only one /64, sometimes two. I argue that a /60 is actually the best compromise here, from a space and usage point of view. /JF Videotron, AS5769
Re: ATT UVERSE Native IPv6, a HOWTO
They are all the same, ATT, Bell Canada, Cogeco.. On 11/29/13, jean-francois.tremblay...@videotron.com jean-francois.tremblay...@videotron.com wrote: De : Mikael Abrahamsson swm...@swm.pp.se A : Mark Andrews ma...@isc.org, You can hand out /48 as easily with 6rd as you can natively. As easily. It's easier to either hand out /64 by means of 1:1 mapping IPv4 and IPv6, or (if ability exists) hand out /48 or /56 using PD, than to get into the whole backend mess of having multiple 6RD domains with multiple configs per IPv4 subnet etc. I agree with you theoretically, but in practice I disagree. Some hard data points here, coming from one of the rare operator who actually deployed 6RD sub-domains to all its customers (to my knowledge). In practice, most 6RD implementations that support option 212 do support IPv4MaskLen properly these days. It wasn't the case 3 years ago, but we worked a lot with vendors to make it right. Seems ok now, we mostly have a 6RD population of D-Link and Cisco/Linksys. On the backend side, it's really not that bad. A one-page TCL handles around 15-16 sub-domains for us without noticeable impact on the DHCP servers CPU. Configuring the relays with all the tunnels can be a bit of fun playing with hex maths, but it's not too bad either. So I agree with Mark, it's not that complex. I can't agree with him on the prefix size though. We hand out /60s because we feel it's enough from a transition point of view (these are short-lived anyway) and offering a bigger size would really use too much space. Offering /48s out of a single /16 block, to take a simple example, would use a whole /32. This space wouldn't be used much anyway, given that most 6RD routers use only one /64, sometimes two. I argue that a /60 is actually the best compromise here, from a space and usage point of view. /JF Videotron, AS5769
DOCSIS 3.0 and Multicast
To Those Who Do DOCSIS3.0, I can't seem to find a simple answer to this, possibly because it is self evident to those actually using Multicast over DOCSIS. Which we are not currently. Multicast over DOCSIS 3.0, to 3.0 CM, can the CM share the same media stream on their node? In example, 2 Cable Modems in the same node (no splitting, same US/DS channels/ports, CMTS..), each have a customer watching ESPN. Is there one or two media streams worth of content on the plant, channels, node? We now how this operates in other worlds, GPON, xDSL and AE. Just haven't seen it specifically mentioned out right in DOCSIS literature. Thanks for any direction you have.
Re: DOCSIS 3.0 and Multicast
Keep in mind that in the cable world the node itself is a layer 1 device, basically it converts between fiber and coax signaling, and so it doesn't take part in any IP transactions. Now, if your CMTS supports multicast and the modems on the same node are on the same downstream AND multicast is enabled on the CMTS then the devices behind the modem (which is a bridge) can use the same stream. A device behind the modem could actually be an embedded device on the modem, but in the DOCSIS world the modem itself (usually) has its own MAC address and each integrated device will have its own so a home gateway product (video, MOCA, voice, router, and WIFI) will often have 5+ MAC addresses, one for each of the devices and often each one has its own configuration. This tutorial may help some: http://www.nanog.org/meetings/nanog48/presentations/Sunday/Riddel_VDOC_N48.pdf Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms On Fri, Nov 29, 2013 at 9:32 AM, mr. s sigasec...@gmail.com wrote: To Those Who Do DOCSIS3.0, I can't seem to find a simple answer to this, possibly because it is self evident to those actually using Multicast over DOCSIS. Which we are not currently. Multicast over DOCSIS 3.0, to 3.0 CM, can the CM share the same media stream on their node? In example, 2 Cable Modems in the same node (no splitting, same US/DS channels/ports, CMTS..), each have a customer watching ESPN. Is there one or two media streams worth of content on the plant, channels, node? We now how this operates in other worlds, GPON, xDSL and AE. Just haven't seen it specifically mentioned out right in DOCSIS literature. Thanks for any direction you have.
Re: DOCSIS 3.0 and Multicast
I would take a look at the presentation in the other post, there are multitude of ways it can be accomplished and some of those are spelled out in the DOCSIS 3.0 specs. Like the other poster said, HFC architectures are very centralized and controlled at the head-end and the components in the field such as the fiber node and even the CM are not active in making decisions about where traffic goes, they just receive what has been sent to them and pass it along. Ultimately any multicast streams will go to a set-top box (or some other video device) and in the case of dynamic multicast it would be the STB generating the IGMP joins. But to answer your question, the answer is yes, the same stream can be sent to two different receivers in the same service group. By the time it gets to the fiber node, it's just RF and if the CM is tuned to the right frequencies, either a specific one for video, or a shared one, it can be used. Most providers aren't doing IP video over DOCSIS, they are still using QAM based delivery via dedicated video spectrum. Phil On 11/29/13, 9:32 AM, mr. s sigasec...@gmail.com wrote: To Those Who Do DOCSIS3.0, I can't seem to find a simple answer to this, possibly because it is self evident to those actually using Multicast over DOCSIS. Which we are not currently. Multicast over DOCSIS 3.0, to 3.0 CM, can the CM share the same media stream on their node? In example, 2 Cable Modems in the same node (no splitting, same US/DS channels/ports, CMTS..), each have a customer watching ESPN. Is there one or two media streams worth of content on the plant, channels, node? We now how this operates in other worlds, GPON, xDSL and AE. Just haven't seen it specifically mentioned out right in DOCSIS literature. Thanks for any direction you have.
Re: What routers do folks use these days?
On 11/28/2013 11:37 PM, Jawaid Desktop wrote: We're a service provider, and we have a network full of Cat6509's. We are finding that we are outgrowing them from the standpoint of their ability to handle lots of large routing tables. Obviously their switching capability is still superb but one of them with 20 peers is starting to groan a bit and RAM is going to be an issue soon. What do people use these days? Our backbone needs in the next 2-3 years are going to be sub-100Gbps. Jawaid If you are looking to stay with Cisco, and depending on features you want, you'll be interested in the ASR1ks and ASR9ks. tv
RE: What routers do folks use these days?
We are using Juniper MX and Brocade XMRs for our P and PE routers. Thanks Darren http://www.mellowd.co.uk/ccie Date: Fri, 29 Nov 2013 09:19:33 +0100 From: kuenz...@init7.net To: nanog@nanog.org Subject: Re: What routers do folks use these days? Am 29.11.2013 06:37, schrieb Jawaid Desktop: We're a service provider, and we have a network full of Cat6509's. We are finding that we are outgrowing them from the standpoint of their ability to handle lots of large routing tables. Obviously their switching capability is still superb but one of them with 20 peers is starting to groan a bit and RAM is going to be an issue soon. What do people use these days? Our backbone needs in the next 2-3 years are going to be sub-100Gbps. Check the Brocade MLXe series. We (Init7 / AS13030) are using them and the previous XMR series for years and are happy with it. CLI is Cisco-look-and-feel, the software tree has a clear structure (unlike Cisco with hundreds of versions) and the TAC is willing to ssh into your gear to assist. -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Twitter: @init7 / @kuenzler http://www.init7.net/
Re: What routers do folks use these days?
Juniper throughout on our side now … former Cisco shop. Overall, quite happy …. MX,M,E,EX,SRX etc… Paul On Nov 29, 2013, at 11:18 AM, Darren O'Connor darre...@outlook.com wrote: We are using Juniper MX and Brocade XMRs for our P and PE routers. Thanks Darren http://www.mellowd.co.uk/ccie Date: Fri, 29 Nov 2013 09:19:33 +0100 From: kuenz...@init7.net To: nanog@nanog.org Subject: Re: What routers do folks use these days? Am 29.11.2013 06:37, schrieb Jawaid Desktop: We're a service provider, and we have a network full of Cat6509's. We are finding that we are outgrowing them from the standpoint of their ability to handle lots of large routing tables. Obviously their switching capability is still superb but one of them with 20 peers is starting to groan a bit and RAM is going to be an issue soon. What do people use these days? Our backbone needs in the next 2-3 years are going to be sub-100Gbps. Check the Brocade MLXe series. We (Init7 / AS13030) are using them and the previous XMR series for years and are happy with it. CLI is Cisco-look-and-feel, the software tree has a clear structure (unlike Cisco with hundreds of versions) and the TAC is willing to ssh into your gear to assist. -- Fredy Kuenzler Init7 (Switzerland) Ltd. AS13030 St. Georgen-Strasse 70 CH-8400 Winterthur Twitter: @init7 / @kuenzler http://www.init7.net/ smime.p7s Description: S/MIME cryptographic signature
Re: What routers do folks use these days?
We use Juniper, Cisco, and ALU in different roles. All of them have their quirks and bugs but none have been a big enough issue to seriously look at moving away from them. We use the MX, PTX, EX, SRX on the Junipers and mainly 7600/ASR9K/Nexus for Cisco and 7750 for ALU. What are you doing on your network today with regards to routing protocols and services? Chances are the 9K/MX/7750 could work in your network fine. The 7750 doesn't easily support the notion of a SVI if you make extensive use of those. The 9K didn't at FCS but does now. The OS is completely different for all three so there is some learning curve. The MX and 9K both have new generations that just came out with the MX2010/2020 and ASR99xx boxes, but for your needs the older chassis would work fine. Phil On Nov 29, 2013 12:38 AM, Jawaid Desktop j...@forethought.net wrote: We're a service provider, and we have a network full of Cat6509's. We are finding that we are outgrowing them from the standpoint of their ability to handle lots of large routing tables. Obviously their switching capability is still superb but one of them with 20 peers is starting to groan a bit and RAM is going to be an issue soon. What do people use these days? Our backbone needs in the next 2-3 years are going to be sub-100Gbps. Jawaid
Re: DOCSIS 3.0 and Multicast
Do any cable companies actually use the hardware multicast capability in DOCSIS cable modems? I can think of some potentially neat uses, but it seems highly unlikely that the cable companies would enable their use to compete against their own TV programming services.
RE: DOCSIS 3.0 and Multicast
It's been tried in Iowa (Butler-Bremmer Communications) and elsewhere, but last I heard, there were bugs in the multicast implementation of the CMs and the middleware vendor didn't have a very large marketshare. GoBackTV was more focused on the LATAM market and the company is now owned by Aurora. They used Asian STBs, not the Motorola/Scientific Atlanta/Amino/Entone STBs that you may be familiar with. So the end-product looks somewhat cobbled together. It looks like Cisco is doing something in the IP Video over DOCSIS area, and so if you're serious about this, you could reach out to them. Regards, Frank -Original Message- From: Phil Karn [mailto:k...@philkarn.net] Sent: Friday, November 29, 2013 11:10 AM To: nanog@nanog.org Subject: Re: DOCSIS 3.0 and Multicast Do any cable companies actually use the hardware multicast capability in DOCSIS cable modems? I can think of some potentially neat uses, but it seems highly unlikely that the cable companies would enable their use to compete against their own TV programming services.
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 30 Nov, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 475032 Prefixes after maximum aggregation: 189765 Deaggregation factor: 2.50 Unique aggregates announced to Internet: 234882 Total ASes present in the Internet Routing Table: 45606 Prefixes per ASN: 10.42 Origin-only ASes present in the Internet Routing Table: 35425 Origin ASes announcing only one prefix: 16285 Transit ASes present in the Internet Routing Table:5965 Transit-only ASes present in the Internet Routing Table:172 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 103 Max AS path prepend of ASN ( 50404) 101 Prefixes from unregistered ASNs in the Routing Table: 1026 Unregistered ASNs in the Routing Table: 289 Number of 32-bit ASNs allocated by the RIRs: 5418 Number of 32-bit ASNs visible in the Routing Table:4216 Prefixes from 32-bit ASNs in the Routing Table: 13406 Number of bogon 32-bit ASNs visible in the Routing Table: 2 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space: 1239 Number of addresses announced to Internet: 2657605980 Equivalent to 158 /8s, 103 /16s and 217 /24s Percentage of available address space announced: 71.8 Percentage of allocated address space announced: 71.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.3 Total number of prefixes smaller than registry allocations: 166229 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 112516 Total APNIC prefixes after maximum aggregation: 34078 APNIC Deaggregation factor:3.30 Prefixes being announced from the APNIC address blocks: 114817 Unique aggregates announced from the APNIC address blocks:47954 APNIC Region origin ASes present in the Internet Routing Table:4871 APNIC Prefixes per ASN: 23.57 APNIC Region origin ASes announcing only one prefix: 1214 APNIC Region transit ASes present in the Internet Routing Table:837 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 35 Number of APNIC region 32-bit ASNs visible in the Routing Table:763 Number of APNIC addresses announced to Internet: 729050048 Equivalent to 43 /8s, 116 /16s and 107 /24s Percentage of available APNIC address space announced: 85.2 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:163913 Total ARIN prefixes after maximum aggregation:81702 ARIN Deaggregation factor: 2.01 Prefixes being announced from the ARIN address blocks: 164722 Unique aggregates announced from the ARIN address blocks: 75893 ARIN Region origin ASes present in the Internet Routing Table:15939 ARIN
Re: ATT UVERSE Native IPv6, a HOWTO
jean-francois.tremblay...@videotron.com writes: Offering /48s out of a single /16 block, to take a simple example, would use a whole /32. Sounds as if your organization can justify more than the /32 minimum/default allocation of IPv6 then (I'd imagine you have more than a minimum-assignment /22 of IPv4 space based on my interactions with Videotron back circa 2004 too). Have you tried asking for more IPv6 space, backed up with your network architecture documents? This space wouldn't be used much anyway, given that most 6RD routers use only one /64, sometimes two. I argue that a /60 is actually the best compromise here, from a space and usage point of view. IPv4-thinking. In the fullness of time this line of reasoning will be greeted with the same wry grin and eyeroll that the NANOG community today reserves for academics who teach their students classful networking. -r
Re: ATT UVERSE Native IPv6, a HOWTO
On Thu, Nov 28, 2013 at 9:07 PM, Leo Vegoda leo.veg...@icann.org wrote: Is a /60 what is considered generous these days? I do not think so. I think that is more minimal than generous. I thought a /48 was considered normal and a /56 was considered a bit tight. What prefix lengths are residential access providers handing out by default these days? A /60 appears (by reports from ATT and Comcast customers) seems to be the current behavior for some residential access providers. I am sure one can find counter examples. And while I can rationalize the thinking (I suspect few home users currently use more than 16 internal networks), with solutions that will eventually depend on further prefix sub-delegation downstream (aka HIPNet), /60 feels a bit tight. I would certainly feel more comfortable seeing the providers start offering at least a /56, if not a /48, if requested by the customer. It is conceivable that the residential providers intend to offer more than a /60 at additional costs (as they offer more than one IPv4 address today), or to offer more than a /60 only to those that request it (to minimize some perceived waste of IPv6 numbers). I would expect that Business customers will almost certainly see different offerings (/48s?). It is also conceivable that the residential providers have not (yet) thought it all through. Gary
Re: DOCSIS 3.0 and Multicast
On 11/29/2013 10:03 AM, Frank Bulk wrote: It looks like Cisco is doing something in the IP Video over DOCSIS area, and so if you're serious about this, you could reach out to them. It's not video over IP multicast that interests me so much as the opportunity to thwart NSA-style bulk traffic analysis by multicasting unicast messages with encrypted destination addresses so an eavesdropper can't tell who it's for.
Re: DOCSIS 3.0 and Multicast
Phil, Arbitrarily turning uni-cast traffic into multi-cast won't do much in that regard. If the end points that didn't orginally ask for the data NAK the incoming stream then they'll get kicked out of the IGMP group, further the requesting end point will be confused by the fact that the traffic is coming in as multi-cast. You could put up some fake hosts that will take any multi-cast data, but they'd be pretty easy to spot over time and making all of your home gateways accept multi-cast traffic they didn't ask for would be a bad thing (think trivial DDoS of your system). Scott Helms Vice President of Technology ZCorum (678) 507-5000 http://twitter.com/kscotthelms On Fri, Nov 29, 2013 at 1:47 PM, Phil Karn k...@philkarn.net wrote: On 11/29/2013 10:03 AM, Frank Bulk wrote: It looks like Cisco is doing something in the IP Video over DOCSIS area, and so if you're serious about this, you could reach out to them. It's not video over IP multicast that interests me so much as the opportunity to thwart NSA-style bulk traffic analysis by multicasting unicast messages with encrypted destination addresses so an eavesdropper can't tell who it's for.
Re: DOCSIS 3.0 and Multicast
On 11/29/2013 11:38 AM, Scott Helms wrote: Phil, Arbitrarily turning uni-cast traffic into multi-cast won't do much in that regard. If the end points that didn't orginally ask for the data NAK the incoming stream then they'll get kicked out of the IGMP group, further the requesting end point will be confused by the fact that the traffic is coming in as multi-cast. You could put up some fake hosts that will take any multi-cast data, but they'd be pretty easy to spot over time and making all of your home gateways accept multi-cast traffic they didn't ask for would be a bad thing (think trivial DDoS of your system). Oh, sorry, I meant to explain that this would be part of a new system with user software explicitly written to join a multicast group, passively listen to all incoming traffic, decrypt whatever's addressed to it and ignore the rest. If the destination addresses are hashed or encrypted so that only the recipient can recognize them, then passive eavesdropping would not reveal to whom they were being sent and the system would be no less efficient than an existing cable modem network with the same set of users. I've been trying to think of ways to thwart large scale traffic analysis, and in a unicast network it's really not easy without a lot of extra traffic (think TOR).
Re: DOCSIS 3.0 and Multicast
- Original Message - From: Phil Karn k...@philkarn.net I've been trying to think of ways to thwart large scale traffic analysis, and in a unicast network it's really not easy without a lot of extra traffic (think TOR). Well, in a story in MIT Tech Review this week, it's mentioned that IETF is considering baking TOR into the base level of the Internet, so if (like me) you think that's a pretty unmanageable, inefficient approach, you might want to chime in now... Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: DOCSIS 3.0 and Multicast
On 11/29/2013 01:11 PM, Jay Ashworth wrote: - Original Message - From: Phil Karn k...@philkarn.net I've been trying to think of ways to thwart large scale traffic analysis, and in a unicast network it's really not easy without a lot of extra traffic (think TOR). Well, in a story in MIT Tech Review this week, it's mentioned that IETF is considering baking TOR into the base level of the Internet, so if (like me) you think that's a pretty unmanageable, inefficient approach, you might want to chime in now... Well, it's inefficient compared to direct unicasting but I can't think of a much better way to do it. And if you really want security against dragnet surveillance, and I think we do, we'll find a way to manage it. Hey, it's not like fiber bandwidth and CPU cycles are hard to find these days.
Re: DOCSIS 3.0 and Multicast
Phil, Been watching this conversation and had a few comments. First, one of the concerns is exposure to wire monitoring on the HFC (Hybrid-Fiber Coax) plant while using DOCSIS, then I think folks should be aware that there is encryption applied to the traffic between the CMTS and Cable Modem (CM). This was traditionally BPI (Baseline Privacy Inspection) and DOCSIS 3.0 supports SEC (which then allows use of AES). I may have missed the point along this email train, but folks may not be aware that putting an RF capturing device on the plant, or sitting behind a CM on the does not gain you gratuitous access to neighbouring people's data. So if application/network flows are also encrypted, you would not necessarily be able to know who it's for as all payload traffic should already be encrypted on the [DOCSIS] wire. This however does not change eavesdropping on the outside of the DOCSIS plan (after CM, or before CMTS). If one did come up with a way of sending normal traffic over a DOCSIS Multicast pipe, then there are a number of resource issues which need to be considered (as they have operator and vendor impact). Multicast is managed very differently (signalling and payload) in DOCSIS vs. Unicast traffic, and therefore resources will be an issue (i.e. IDs used to direct traffic for Unicast are not the same as those used for Multicast). To add, forcing a bunch of (or all) traffic down a Multicast pipe would impact an operator's ability to managed QoS for customers (which is already complex enough in the DOCSIS world) and may impact CM operation (which will be keeping track what multicast groups/packets will be forwarded for a given service endpoint). regards, Victor K On Fri, Nov 29, 2013 at 1:47 PM, Phil Karn k...@philkarn.net wrote: On 11/29/2013 10:03 AM, Frank Bulk wrote: It looks like Cisco is doing something in the IP Video over DOCSIS area, and so if you're serious about this, you could reach out to them. It's not video over IP multicast that interests me so much as the opportunity to thwart NSA-style bulk traffic analysis by multicasting unicast messages with encrypted destination addresses so an eavesdropper can't tell who it's for.
The Cidr Report
This report has been generated at Fri Nov 29 21:13:33 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
22-11-13483927 273267
23-11-13484394 273042
24-11-13483904 273160
25-11-13484114 273204
26-11-13484358 273519
27-11-13484806 273511
28-11-13484564 273716
29-11-13485190 274270
AS Summary
45765 Number of ASes in routing system
18790 Number of ASes announcing only one prefix
4530 Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
118901504 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 29Nov13 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 485792 274250 21154243.5% All ASes
AS28573 3406 91 331597.3% NET Serviços de Comunicação
S.A.
AS6389 3042 56 298698.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS17974 2717 188 252993.1% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS7029 4530 2027 250355.3% WINDSTREAM - Windstream
Communications Inc
AS22773 2211 161 205092.7% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4766 2930 949 198167.6% KIXS-AS-KR Korea Telecom
AS18881 1706 31 167598.2% Global Village Telecom
AS36998 1864 375 148979.9% SDN-MOBITEL
AS18566 2052 566 148672.4% MEGAPATH5-US - MegaPath
Corporation
AS4323 2961 1524 143748.5% TWTC - tw telecom holdings,
inc.
AS7303 1729 470 125972.8% Telecom Argentina S.A.
AS1785 2044 823 122159.7% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4755 1793 579 121467.7% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS10620 2673 1468 120545.1% Telmex Colombia S.A.
AS7552 1198 139 105988.4% VIETEL-AS-AP Vietel
Corporation
AS22561 1240 221 101982.2% AS22561 - CenturyTel Internet
Holdings, Inc.
AS9829 1540 660 88057.1% BSNL-NIB National Internet
Backbone
AS35908 919 96 82389.6% VPLSNET - Krypt Technologies
AS7545 2114 1300 81438.5% TPG-INTERNET-AP TPG Telecom
Limited
AS18101 981 180 80181.7% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS24560 1102 354 74867.9% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS4808 1146 399 74765.2% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS8151 1369 642 72753.1% Uninet S.A. de C.V.
AS701 1507 783 72448.0% UUNET - MCI Communications
Services, Inc. d/b/a Verizon
Business
AS6983 1293 578 71555.3% ITCDELTA - ITC^Deltacom
AS13977 855 143 71283.3% CTELCO - FAIRPOINT
COMMUNICATIONS, INC.
AS6147 792 108 68486.4% Telefonica del Peru S.A.A.
AS855730 58 67292.1% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS4780 1019 352 66765.5% SEEDNET Digital United Inc.
AS4788 874
BGP Update Report
BGP Update Report Interval: 21-Nov-13 -to- 28-Nov-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS754563977 2.6% 90.4 -- TPG-INTERNET-AP TPG Telecom Limited 2 - AS840239337 1.6% 29.2 -- CORBINA-AS OJSC Vimpelcom 3 - AS30693 38382 1.6% 69.8 -- SERVERHUB-PHOENIX - Eonix Corporation 4 - AS982935428 1.4% 45.0 -- BSNL-NIB National Internet Backbone 5 - AS453829814 1.2% 53.3 -- ERX-CERNET-BKB China Education and Research Network Center 6 - AS755228006 1.1% 23.4 -- VIETEL-AS-AP Vietel Corporation 7 - AS36753 25914 1.1% 12957.0 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 8 - AS13118 23664 1.0% 537.8 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS29990 22000 0.9% 11000.0 -- ASN-APPNEXUS - AppNexus, Inc 10 - AS17974 21340 0.9% 7.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS702920967 0.8% 4.8 -- WINDSTREAM - Windstream Communications Inc 12 - AS28573 20284 0.8% 9.2 -- NET Serviços de Comunicação S.A. 13 - AS477519241 0.8% 305.4 -- GLOBE-TELECOM-AS Globe Telecoms 14 - AS14287 17367 0.7% 321.6 -- TRIAD-TELECOM - Triad Telecom, Inc. 15 - AS37004 15207 0.6% 608.3 -- SUBURBAN-AS 16 - AS27738 15045 0.6% 26.1 -- Ecuadortelecom S.A. 17 - AS31549 14842 0.6% 86.3 -- RASANA Aria Shatel Company Ltd 18 - AS31148 14602 0.6% 14.5 -- FREENET-AS Freenet Ltd. 19 - AS50710 13903 0.6% 61.5 -- EARTHLINK-AS EarthLink Ltd. CommunicationsInternet Services 20 - AS37453 13746 0.6%1963.7 -- VODACOM-CONGO TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS36753 25914 1.1% 12957.0 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 2 - AS29990 22000 0.9% 11000.0 -- ASN-APPNEXUS - AppNexus, Inc 3 - AS6629 7235 0.3%7235.0 -- NOAA-AS - NOAA 4 - AS544657003 0.3%7003.0 -- QPM-AS-1 - QuickPlay Media Inc. 5 - AS526405352 0.2%5352.0 -- ULTRANET SCM - COMUNICACAO MULTIMIDIA LTDA. 6 - AS373674171 0.2%4171.0 -- CALLKEY 7 - AS225922421 0.1%2421.0 -- HBP - HBP, Inc. 8 - AS212714491 0.2%2245.5 -- SOTELMABGP 9 - AS624312052 0.1%2052.0 -- NCSC-IE-AS National Cyber Security Centre 10 - AS37453 13746 0.6%1963.7 -- VODACOM-CONGO 11 - AS553185406 0.2%1802.0 -- ACB-AS-VN Asia Commercial Bank 12 - AS7202 8787 0.3%1757.4 -- FAMU - Florida A M University 13 - AS382491638 0.1%1638.0 -- EPS-AS-VN Empower Securities Corporation 14 - AS553211598 0.1%1598.0 -- STSC-AS-VN Saigontourist securities corporation 15 - AS5388 1310 0.1%1310.0 -- ENERGIS-AS Energis UK 16 - AS526613839 0.1%1279.7 -- Oliveira e Andrade Informática LTDA 17 - AS6775 6245 0.2%1249.0 -- BACKBONE_EHF_EUROPE Backbone ehf 18 - AS455561015 0.0%1015.0 -- SCANCOM-AS-VN Scancom Vietnam Ltd 19 - AS8011 988 0.0% 988.0 -- AS8011 - CoreComm Internet Services Inc 20 - AS354673784 0.1% 946.0 -- DCF-AS DataCenter Fryslan AS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 23442 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 103.243.220.0/22 21986 0.8% AS29990 -- ASN-APPNEXUS - AppNexus, Inc 3 - 38.87.227.0/2413621 0.5% AS37453 -- VODACOM-CONGO 4 - 12.68.46.0/24 13476 0.5% AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 5 - 64.240.174.0/24 12438 0.5% AS36753 -- SSF-AUTO-PARTS - SSF Imported Autoparts Inc. 6 - 120.28.62.0/24 9640 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 7 - 222.127.0.0/24 9348 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 8 - 192.58.232.0/247235 0.3% AS6629 -- NOAA-AS - NOAA 9 - 14.202.160.0/227229 0.3% AS7545 -- TPG-INTERNET-AP TPG Telecom Limited 10 - 206.152.15.0/247003 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 11 - 220.244.72.0/216954 0.3% AS7545 -- TPG-INTERNET-AP TPG Telecom Limited 12 - 67.210.190.0/236390 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 13 - 79.134.225.0/246237 0.2% AS6775 -- BACKBONE_EHF_EUROPE Backbone ehf 14 - 67.210.188.0/235581 0.2% AS11976 -- FIDN - Fidelity Communication International Inc. 15 - 220.244.0.0/22 5577 0.2% AS7545 -- TPG-INTERNET-AP TPG Telecom Limited 16 - 179.96.208.0/215352 0.2% AS52640 -- ULTRANET SCM - COMUNICACAO MULTIMIDIA LTDA. 17 - 68.143.17.0/24 5274 0.2% AS7029 --
bgp traceroute tool?
Hi there, is there any tools available under linux which can do bgp traceroute? (print bgp AS numbers for each traceroute hop ) , i googled and found nothing. thanks John
Re: bgp traceroute tool?
LFT should do. http://pwhois.org/lft/ Mike On Nov 29, 2013, at 4:03 PM, John Conner bs7...@gmail.com wrote: Hi there, is there any tools available under linux which can do bgp traceroute? (print bgp AS numbers for each traceroute hop ) , i googled and found nothing. thanks John
Re: bgp traceroute tool?
beyond awesome! On Sat, Nov 30, 2013 at 8:11 AM, Michael Smith mksm...@mac.com wrote: LFT should do. http://pwhois.org/lft/ Mike On Nov 29, 2013, at 4:03 PM, John Conner bs7...@gmail.com wrote: Hi there, is there any tools available under linux which can do bgp traceroute? (print bgp AS numbers for each traceroute hop ) , i googled and found nothing. thanks John
list all the domains under a specific nameserver?
Just curious, is there any way for someone to pull all the domains being registered under a given domain register? I have seen websites like http://www.dailychanges.com which does this type of thing and would like to know if that is something easily doable, thanks Regards John
Re: bgp traceroute tool?
even the basic traceroute util with show AS with the -A flag. I actually can't remember any of the tracing tools which don't support it, offhand. On Fri, Nov 29, 2013 at 4:18 PM, John Conner bs7...@gmail.com wrote: beyond awesome! On Sat, Nov 30, 2013 at 8:11 AM, Michael Smith mksm...@mac.com wrote: LFT should do. http://pwhois.org/lft/ Mike On Nov 29, 2013, at 4:03 PM, John Conner bs7...@gmail.com wrote: Hi there, is there any tools available under linux which can do bgp traceroute? (print bgp AS numbers for each traceroute hop ) , i googled and found nothing. thanks John
Re: list all the domains under a specific nameserver?
The only thing comes to my mind is the passive dns method, which collects all the dns requests and replies and then a database can be created to track the changes. But I am hoping there are other better answers. Thanks John On Sat, Nov 30, 2013 at 8:55 AM, bmann...@vacation.karoshi.com wrote: there is no good way to pull all the domains hosted by a nameserver unless the config file is open to transfer. equally, there is no good way to pull all the domains under a given register. _IF_ zone transfers are enabled, you might be able to pull all the children under a given zone delegation. as usual, ymmv bill On Sat, Nov 30, 2013 at 08:34:00AM +0800, John Conner wrote: Just curious, is there any way for someone to pull all the domains being registered under a given domain register? I have seen websites like http://www.dailychanges.com which does this type of thing and would like to know if that is something easily doable, thanks Regards John
Re: bgp traceroute tool?
Yep. Tracepath is a nice tool as well Sent from my iPad On Nov 29, 2013, at 7:41 PM, Ray Wong r...@rayw.net wrote: even the basic traceroute util with show AS with the -A flag. I actually can't remember any of the tracing tools which don't support it, offhand. On Fri, Nov 29, 2013 at 4:18 PM, John Conner bs7...@gmail.com wrote: beyond awesome! On Sat, Nov 30, 2013 at 8:11 AM, Michael Smith mksm...@mac.com wrote: LFT should do. http://pwhois.org/lft/ Mike On Nov 29, 2013, at 4:03 PM, John Conner bs7...@gmail.com wrote: Hi there, is there any tools available under linux which can do bgp traceroute? (print bgp AS numbers for each traceroute hop ) , i googled and found nothing. thanks John
Re: bgp traceroute tool?
On Fri, 29 Nov 2013, Ray Wong wrote: even the basic traceroute util with show AS with the -A flag. I actually can't remember any of the tracing tools which don't support it, offhand. Indeed - while lft is not IPv6 enabled. Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@gmail.com
Re: What routers do folks use these days?
If you're staying Cisco, probably the ASR1000 series, or the ASR9K, depending on needs. You probably don't need CSR routers if you're not going to 100Gbps. On Fri, Nov 29, 2013 at 6:37 PM, Jawaid Desktop j...@forethought.net wrote: We're a service provider, and we have a network full of Cat6509's. We are finding that we are outgrowing them from the standpoint of their ability to handle lots of large routing tables. Obviously their switching capability is still superb but one of them with 20 peers is starting to groan a bit and RAM is going to be an issue soon. What do people use these days? Our backbone needs in the next 2-3 years are going to be sub-100Gbps. Jawaid
CFP: 17th IEEE Global Internet Symposium (GI 2014)
Call for Papers 17th IEEE Global Internet Symposium (GI 2014) In conjunction with IEEE INFOCOM 2014 Toronto, Canada April 27--May 2, 2014 http://www.ieee-infocom.org/2014/Workshops_GI.html The 17th IEEE Global Internet Symposium will be co-located with IEEE Infocom 2014. All relevant dates, location, and travel information are available from the IEEE Infocom 2014 conference site: http://www.ieee-infocom.org/2014/. The IEEE Global Internet Symposium aims to provide a top forum for researchers and practitioners to present and discuss advances in Internet-related technologies. The focus of the symposium is on experimental systems and emerging future Internet technologies, and especially on scaling such systems to a global scale. Research on understanding Internet protocols, services, and applications at global scale is also encouraged. The Program Committee also welcomes position papers (which should be clearly marked as such). The topics of interest include, but are not limited to the following: * Routing, switching, and addressing * Resource management and quality of service * Software defined networks and network programming * Content delivery and management * Energy awareness * Next-generation network architectures * Distributed Internet applications including games, VoIP, and video conferencing * Online social networking * Peer-to-peer networks * Novel applications and new paradigms * Internet measurement, modeling, and visualization * Large-scale network operation and performance monitoring * Privacy and/or security issues on the Internet * Anomaly, intrusion and attack detection * Interface among networking, communications and information theory * Applications of network science in communication networks * Economic aspects of the Internet Important Dates * Paper submission: 15th December 2013, 11:59 PM PST. * Notification of acceptance: 7th February 2014 * Final manuscripts due: TBA * Symposium: TBA Submission Instructions Submitted manuscripts must be formatted in standard IEEE camera-ready format (double-column, 10-pt font) and must be submitted via EDAS as PDF files: http://edas.info/newPaper.php?c=16281. The manuscripts must be no longer than 6 pages. The Program Committee reserves the right to not review papers that violate these formatting rules. Submitted papers must not have been previously published, or be under consideration for publication elsewhere. All submitted papers will be reviewed and judged on originality, technical correctness, relevance, and quality of presentation. All accepted papers must be presented at the symposium by one of the authors. Steering Committee * Xiaoming Fu, Chair (University of Goettingen, DE) * Marcelo Bagnulo Braun (UC3M, Spain) * Tilman Wolf (UMass, USA) * Jorg Ott (Aalto U., Finland) * Colin Perkins (U. Glasgow, UK) Program Committee Chairs * Jun Li (University of Oregon, USA) * Rade Stanojevic (Telefonica Research, Spain) Technical Program Committee * Fred Baker (Cisco) * Fabian Bustamante (Northwestern University) * Kevin Butler (University of Oregon) * Luca Cittadini (Roma Tre University) * Ruben Cuevas (UC3M) * Wu-chang Feng (Portland State University) * Polly Huang (National Taiwan University) * Olaf Maennel (Loughborough University) * David Malone (Hamilton Institute) * Joerg Ott (Aalto University) * Colin Perkins (University of Glasgow) * Radia Perlman (Intel) * Chen Qian (University of Kentucky) * Peter Reiher (UCLA) * Reza Rejaie (University of Oregon) * Michael Sirivianos (Cyprus University of Technology) * Arun Vishwanath (University of Melbourne) * Dan Wang (The Hong Kong Polytechnic University) * Mei Wang (Cisco) * Lenx Tao Wei (UC Berkeley and Peking University) * Tilman Wolf (U Mass Amherst) The Global Internet (GI) Symposium is the flagship event established and organized by the Internet Technical Committee (ITC), a joint committee of the IEEE Communications Society (ComSoc) and the Internet Society (ISOC). === Jun Li, Ph.D. Associate Professor, Computer and Information Science, University of Oregon Director, Network Security Research Laboratory, University of Oregon Email: li...@cs.uoregon.edu http://www.cs.uoregon.edu/~lijun
RE: bgp traceroute tool?
The traceroute variant included with CentOS 6.4 Mint 13 has an -A flag which does ASN lookups. ntraceroute on FreeBSD supports it as well. I believe the Linux port is traceroute-nanog. Lee [user@box ~]# traceroute -V Modern traceroute for Linux, version 2.0.14, Nov 11 2010 Copyright (c) 2008 Dmitry Butskoy, License: GPL v2 or any later [user@box ~]# traceroute -A www.google.ca traceroute to www.google.ca (74.125.226.127), 30 hops max, 60 byte packets snip 6 72.14.197.33 (72.14.197.33) [AS15169] 73.927 ms 69.254 ms 69.305 ms 7 209.85.254.130 (209.85.254.130) [AS15169] 69.436 ms 209.85.254.122 (209.85.254.122) [AS15169] 79.554 ms 64.269 ms 8 72.14.237.130 (72.14.237.130) [AS15169] 64.979 ms 65.975 ms 209.85.254.238 (209.85.254.238) [AS15169] 66.700 ms 9 216.239.46.161 (216.239.46.161) [AS15169] 71.293 ms 72.251 ms 73.521 ms 10 209.85.250.207 (209.85.250.207) [AS15169] 74.454 ms 74.920 ms 75.889 ms 11 yyz08s13-in-f31.1e100.net (74.125.226.127) [AS15169] 76.628 ms 77.105 ms 70.928 ms -Original Message- From: John Conner [mailto:bs7...@gmail.com] Sent: Friday, November 29, 2013 5:04 PM To: nanog@nanog.org Subject: bgp traceroute tool? Hi there, is there any tools available under linux which can do bgp traceroute? (print bgp AS numbers for each traceroute hop ) , i googled and found nothing. thanks John
Re: list all the domains under a specific nameserver?
On Fri, Nov 29, 2013 at 6:34 PM, John Conner bs7...@gmail.com wrote: Just curious, is there any way for someone to pull all the domains being registered under a given domain register? I have seen websites like http://www.dailychanges.com which does this type of thing and would like to know if that is something easily doable, thanks Commercial services such as domaintools name server monitor come to mind. Otherwise; the person to ask the question needs to have the zone file information. nameserver list data feeds from the TLD registry operators, of every TLD they want to gather nameserver information for. For certain TLDs; this may be available -- for example, Verisign .com and .net TLD Zone file access program. These data feeds are likely at substantially high application, approval, and paperwork requirements for acceptance, for each TLD, and substantially high cost for each TLD - therefore, not generally an option, so dailychanges or other commercial services will be your best option.. There is certainly no WHOIS or DNS query that will provide you this; which is essentially a search for database entries based on the IP addresses that NS record right-hand side values resolve to. Regards John -- -JH
Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond
Dear NANOG@,
I'm not exactly sure how else I can get he.net's attention, because I've
been experiencing congestion issues between my dedi and Indiana for a
couple of months now, all due to he.net's poor transit, as it turns out.
The issue was complicated by the fact that the routes are asymmetric,
and it appears as if the traffic loss is going on somewhere where there
is none at all.
I will just provide the data, and people can make their own conclusions,
any insights are welcome.
During all of this, since some late September 2013, all 4 networks
involved have been contacted -- hetzner, init7, he.net, indiana; all
except for he.net have responded and did troubleshooting.
After pressing the lack of any kind of response from he.net, all they
did was ask for a customer number, and that was back in September. I
have not heard from their NOC@ ever since, with requests left
unanswered, sans the we have received your request autoreply.
Interestingly enough, only some of their Europe-to-US routes are
blatantly congested and have very obvious packet loss (often making ssh
unusable), whereas others appear to be doing just fine (at least, not
losing packets and not experiencing jitter, and the increased latency).
E.g. IPv6 routes don't appear affected, for example. IPv4 addresses
in North America that are announced directly from AS6939 (e.g. Linode in
Fremont) don't appear affected, either. But the multi-homed indiana.edu
and wiscnet.net are affected. The single-homed ntp1.yycix.ca is
affected, too. Probably other customers are affected as well.
Where's the end to this?
Or is the ongoing 0.5+% traffic loss, and the 140+ms avg latency on a
114ms route, with random spikes and jitter in certain hours of the day
(generally around midnight ET), every day for several weeks or even
months, an acceptable practice?
From hetzner.de through he.net:
Cns# date ; mtr --report{,-wide,-cycles=600} --interval 0.1 --order SRL
BGAWV -4 c.indiana.edu ; date
Fri Nov 29 21:06:17 PST 2013
HOST: Cns??? Snt Rcv Loss%
Best Gmean Avg Wrst StDev
1.|-- static.??.???.4.46.clients.your-server.de600 600 0.0%
0.5 1.0 1.3 4.9 1.1
2.|-- hos-tr1.juniper1.rz13.hetzner.de 600 600 0.0%
0.1 0.2 1.9 66.0 7.6
3.|-- core21.hetzner.de600 600 0.0%
0.2 0.2 0.2 5.8 0.4
4.|-- core22.hetzner.de600 600 0.0%
0.2 0.2 0.2 19.4 1.2
5.|-- core1.hetzner.de 600 600 0.0%
4.8 4.8 4.8 13.2 0.7
6.|-- juniper1.ffm.hetzner.de 600 600 0.0%
4.8 4.8 4.8 27.4 1.4
7.|-- 30gigabitethernet1-3.core1.ams1.he.net 600 600 0.0%
11.2 14.0 14.6 48.7 4.5
8.|-- 10gigabitethernet1-4.core1.lon1.he.net 600 600 0.0%
18.2 19.6 19.9 53.9 4.1
9.|-- 10gigabitethernet10-4.core1.nyc4.he.net 600 599 0.2%
87.0 116.1 116.7 145.7 12.4
10.|-- 100gigabitethernet7-2.core1.chi1.he.net 600 597 0.5%
106.6 135.4 136.1 192.0 13.3
11.|-- ??? 600 0 100.0
0.0 0.0 0.0 0.0 0.0
12.|-- et-11-0-0.945.rtr.ictc.indiana.gigapop.net 600 594 1.0%
113.3 139.3 139.7 166.1 11.4
13.|-- xe-0-3-0.11.br2.ictc.net.uits.iu.edu 600 596 0.7%
113.2 139.8 140.3 177.3 12.0
14.|-- ae-0.0.br2.bldc.net.uits.iu.edu 600 595 0.8%
114.2 140.1 140.6 183.2 11.8
15.|-- ae-10.0.cr3.bldc.net.uits.iu.edu 600 597 0.5%
114.3 140.3 140.8 165.0 11.5
16.|-- c.indiana.edu600 597 0.5%
114.7 140.7 141.1 161.6 11.4
Fri Nov 29 21:08:52 PST 2013
Cns# unbuffer hping --icmp-ts c.indiana.edu | \
perl -ne 'if (/icmp_seq=(\d+) rtt=(\d+\.\d)/) {($s, $p) = ($1, $2);} \
if (/ate=(\d+) Receive=(\d+) Transmit=(\d+)/) {($o, $r, $t) = ($1, $2,
$3);} \
if (/tsrtt=(\d+)/) { \
print $s, \t, $p, \t, $1, = , $r - $o, + , $o + $1 - $t, \n; }'
0 143.5 144 = 87 + 57
1 125.5 126 = 69 + 57
2 143.6 144 = 87 + 57
3 157.9 158 = 102 + 56
4 122.0 122 = 66 + 56
5 141.6 142 = 85 + 57
6 132.2 133 = 76 + 57
7 146.2 146 = 89 + 57
8 145.1 145 = 88 + 57
9 119.9 119 = 63 + 56
10 132.7 132 = 75 + 57
11 140.1 140 = 83 + 57
12 151.0 151 = 94 + 57
13 152.6 152 = 96 + 56
14 129.1 129 = 72 + 57
15 128.5 128 = 71 + 57
^C
Single-homed at he.net:
Cns# date ; mtr --report{,-cycles=600} --interval 0.1 --order SRL
BGAWV -4 ntp1.yycix.ca ; date
Fri Nov 29 21:16:14 PST 2013
HOST: Cns???Snt Rcv Loss% Best Gmean Avg
Wrst StDev
1.|-- static.??.???.4.46.client 600 600 0.0%0.5 1.0 1.3
10.2 1.2
2.|-- hos-tr4.juniper2.rz13.het 600 600 0.0%0.1 0.2 2.0
153.9 9.8
3.|-- core22.hetzner.de
