Comcast Bulk/Metro Ethernet
Is there anyone from the Comcast Bulk or Metro Ethernet departments that can contact me off list? Thanks -=Tom
Re: Interested in input on tunnels as an IPv6 transition technology
would be interested to know what people think is good about tunnels as an IPv6 transition technology, and what people think is bad about tunnels. The good thing about tunnels is people can build them where there's no proper network The bad thing about tunnels is people build them instead of a proper network brandon
Re: IPv6 foot-dragging
On 13 mei 2011, at 2:39, Jimmy Hess wrote: if the user starts obtaining multiple non-aggregable /48s from different sources, or obtains an additional PI allocation later, but keeps using the original /48. Simple: make a rule that you don't get more than one PI block, and if you want a bigger one you have to return the old one. Oh wait, people use PI because they want to avoid renumbering? It was never meant for that. Maybe a good incentive to ask for the right size block in the first place. The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless. And that all in case a /48 isn't big enough (which is ridiculously rare in and of itself) to save ONE entry in the global routing table. So by trying to conserve the table we make it impossible to protect our routing tables. It is a heck of a lot better for network stability that any multi-homed user get a /32 PI, No, that's completely ridiculous. It's like saying all flights should be flown with 747s just in case 10 football teams show up unexpectedly. That is, if a 747 could carry a million people (64k more than a small 16-seat plane). Yes, the IPv6 address space is big but by giving people who need more than 65000 subnets a /32 so they can have 40 subnets is unbelievably wasteful for no other reason than laziness.
Re: Interested in input on tunnels as an IPv6 transition technology
On 13 mei 2011, at 7:52, Karl Auer wrote: I'm working on a talk, and would be interested to know what people think is good about tunnels as an IPv6 transition technology, and what people think is bad about tunnels. Without tunnels we'd have no IPv6 today. Even today many people, especially home users, depend on them. But it would have been impossible to get IPv6 started by running it native-only. Tunnels can work very well and if they're direct they can be almost as good as native connectivity. However, in the past we saw Europeans get tunneled IPv6 connectivity from Japan. That kind of thing is very bad because it inflates RTTs and thus slows everything down. Enabling automatic tunneling by default is also a mistake because then you think you have IPv6 even if the automatic tunnel doesn't work because relays are unreachable or stuff is firewalled. A downside of tunneling is the reduced MTU, but hopefully the fact that tunnels are common makes people fix PMTUD problems rather than blindly send 1500-byte packets and let the chips fall where they may that way too many people do with IPv4. So... tunnels can be good or can be bad, but native is still better than a good tunnel.
Need the perspective of a Level3 customer.
Can anyone peering with Level3 directly tell me if they are seeing 63.210.162.0/24 coming from the Level3 peer? Thanks for the help. Cheers, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward?
Re: Need the perspective of a Level3 customer.
Le vendredi 13 mai 2011 à 01:39 -0700, Joe Renwick a écrit : Can anyone peering with Level3 directly tell me if they are seeing 63.210.162.0/24 coming from the Level3 peer? Yes, I do. mh Thanks for the help. Cheers,
Re: Need the perspective of a Level3 customer.
On Fri, 2011-05-13 at 01:39 -0700, Joe Renwick wrote: Can anyone peering with Level3 directly tell me if they are seeing 63.210.162.0/24 coming from the Level3 peer? Thanks for the help. Cheers, Hi Joe, #show bgp ipv4 unicast 63.210.162.0/24 BGP routing table entry for 63.210.162.0/24, version 26824780 Paths: (2 available, best #2, table default) Advertised to update-groups: 1 3356 16582 195.50.113.161 from 195.50.113.161 (4.68.0.179) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2002 6461 3356 16582 79.141.38.194 from 79.141.38.194 (64.125.0.165) Origin IGP, metric 28, localpref 150, valid, external, best Community: 6461:5997 Hope this helps. :) Tom
Re: Need the perspective of a Level3 customer.
Thanks again to all who replied... looks like other Level3 customer are seeing the /24. Looks like the issue is specific to San Diego. Any routing information from other SD Level3 customer would be appreciated. Cheers, Joe On Fri, May 13, 2011 at 1:39 AM, Joe Renwick j...@gonetforward.com wrote: Can anyone peering with Level3 directly tell me if they are seeing 63.210.162.0/24 coming from the Level3 peer? Thanks for the help. Cheers, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward?
dot xxx live or not?
About a month ago it was announced that the xxx sTLD had gone live i.e. been added to the IANA root zone http://www.domainnamenews.com/registries/xxx-live-root-servers/9191 I recall checking at the time that http://icmregistry.xxx worked Now it doesn't. Anyone know what's going on? j -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: Interested in input on tunnels as an IPv6 transition technology
The good thing about tunnels is people can build them where there's no proper network and the result is a network that is broken differently
Re: dot xxx live or not?
On Fri, May 13, 2011 at 05:03:11AM -0400, Joly MacFie j...@punkcast.com wrote a message of 19 lines which said: I recall checking at the time that http://icmregistry.xxx worked Now it doesn't. Anyone know what's going on? The TLD .xxx works. Names like sex.xxx or icmregistry.xxx have apparently been deleted. nic.xxx or about.xxx are still there in the DNS and the Web site http://about.xxx/ works.
Re: Interested in input on tunnels as an IPv6 transition technology
would be interested to know what people think is good about tunnels as an IPv6 transition technology, and what people think is bad about tunnels. The good thing about tunnels is people can build them where there's no proper network The bad thing about tunnels is people build them instead of a proper network brandon We've used an HE tunnel with BGP for about a year and it has not been reliable enough for my tastes. However, I think it's great for testing - I just wouldn't want to rely on it for production. One, it's not ideal to force traffic over a tunnel that incurs additional processing, latency, and reliability problems. Second, in the case of a free HE tunnel, it might be viewed as impolite to send the tunnel provider lots of data (I don't remember seeing a bandwidth usage policy). Only in the case where local peers refuse to provide reliable IP6 transit would I consider using a tunnel full time for IP6 traffic. And even then, probably only if I was paying and had some sort of service guarantees and support from the tunnel provider. I would look at switching local peers for transit before relying on a tunnel. --Blake
Re: coprorations using BGP for advertising prefixes in mid-1990s
From: Tony Li tony...@tony.li Date: Thu, 12 May 2011 16:47:54 -0700 On May 12, 2011, at 2:37 PM, Kevin Oberman wrote: Does no one remember EGP? ASNs are MUCH older than BGP. And we were using BGPv3 prior to the existence of V4. We used BGPv4 back in the days when Tony Li would chastise us for reporting a bug in a 10 day old Cisco build saying that we could not expect BGPv4 code over a week old to work. He felt that we should deploy new code daily. To be fair, that was for folks on the isp-geeks mailing list, who were effectively doing alpha test with me. I was fixing about 1 significant bug per day and doing at least one release per day. 10 day old code was missing at least 10 fixes... ;-) And that was BGP3. BGP4 was the next developer. Regards, Tony Yes, Tony. It was absolutely fair. It was certainly not your (or Cisco's) fault. It was a huge effort on the part of a small number of Cisco engineers (I assume that you and Paul wrote most of the code) to get a complex protocol stable and ready for implementation in far too little time. It was utter insanity and it all worked! (Just in time for the death of the PRDB). In no way was I criticizing your efforts. I just remember that message and thinking how much testing and planning we do today before rolling new code onto production systems. The idea of reloading production routers with code we absolutely knew would prove buggy on a weekly (or more than weekly) basis seems so unimaginable today. I'm looking forward to seeing Milo at NANOG 52 next month in Denver! I'm sure that he remembers all of this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Network Equipment Discussion (HP and L2/10G)
Go figure, an actual thread about networking equipment on NANOG. :) So reading Cisco's announcement, I go look at HP's higher end switching/routing line and I see some pretty beefy looking gear. A12500 and others. Does anyone have any experience with this thing -- is it white labeled from someone else? Second question -- Does anyone know of a Cascade-style box (old days) for 10G aggregation? What I mean is I need about a number of ports of 10G (pluggable *colored* optics) with just normal L2 stuff (VLANs/dot1q) and I'd like to LACP/Port-channel that back to a pair of 10G ports on a router. The wrinkle here is that I can't use a normal enterprise 10G switch because of the need for DWDM optics (ideally 80km style). For this application, buffers and such are not an issue. Any suggestions? Thanks in advance, DJ
Re: Network Equipment Discussion (HP and L2/10G)
On 5/13/11 8:14 AM, Deepak Jain wrote: Go figure, an actual thread about networking equipment on NANOG. :) So reading Cisco's announcement, I go look at HP's higher end switching/routing line and I see some pretty beefy looking gear. A12500 and others. Does anyone have any experience with this thing -- is it white labeled from someone else? 3com aquisition/ Huawei joint venture I took a look at the h3c s58xx sometime last year, I can report that it's an ethernet siwtch. Second question -- Does anyone know of a Cascade-style box (old days) for 10G aggregation? What I mean is I need about a number of ports of 10G (pluggable *colored* optics) with just normal L2 stuff (VLANs/dot1q) and I'd like to LACP/Port-channel that back to a pair of 10G ports on a router. The wrinkle here is that I can't use a normal enterprise 10G switch because of the need for DWDM optics (ideally 80km style). For this application, buffers and such are not an issue. Any suggestions? Thanks in advance, DJ
Re: Need the perspective of a Level3 customer.
On 5/13/11 2:55 AM, Joe Renwick wrote: Thanks again to all who replied... looks like other Level3 customer are seeing the /24. Looks like the issue is specific to San Diego. Any routing information from other SD Level3 customer would be appreciated. Through Level3 (AS3356) Seattle-SJ-LA-SD-nextlevelinternet (AS1658) I can see that announcement. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: Need the perspective of a Level3 customer.
Here is what I am seeing from both of my Level 3 links, hope it helps: show ip bgp 63.210.162.0 BGP routing table entry for 63.210.162.0/24, version 139413425 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 3356 16582 4.53.6.25 from 4.53.6.25 (4.68.185.104) Origin IGP, metric 25753, localpref 100, valid, external, best Community: 3833:601 3356 16582, (received-only) 4.53.6.25 from 4.53.6.25 (4.68.185.104) Origin IGP, metric 25753, localpref 100, valid, external Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2002 show ip bgp 63.210.162.0 BGP routing table entry for 63.210.162.0/24, version 148858770 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 3356 16582 4.53.6.29 from 4.53.6.29 (4.68.185.104) Origin IGP, metric 25753, localpref 100, valid, external, best Community: 3833:600 3356 16582, (received-only) 4.53.6.29 from 4.53.6.29 (4.68.185.104) Origin IGP, metric 25753, localpref 100, valid, external Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2002 Thanks Eric Nowland Engineering Manager Wyoming.com On 5/13/2011 2:39 AM, Joe Renwick wrote: Can anyone peering with Level3 directly tell me if they are seeing 63.210.162.0/24 coming from the Level3 peer? Thanks for the help. Cheers,
IPv6 day in NYC?
The Internet Society is organizing IPv6 Day for June 6 2011. http://isoc.org/wp/worldipv6day/ There isn't currently a NYC event scheduled. If anyone's interested in making a presentation or just getting together for a discussion ISOC-NY would be happy to host at NYU. Feel free to respond off list. j...@punkcast.com j -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: IPv6 day in NYC?
On Fri, May 13, 2011 at 9:52 AM, Joly MacFie j...@punkcast.com wrote: The Internet Society is organizing IPv6 Day for June 6 2011. http://isoc.org/wp/worldipv6day/ Uh...unless there's been a sudden change of plans, I believe the date is still set for June *8th*, 2011. ^_^;; Matt
Re: IPv6 day in NYC?
Oops. Jun 8th 2011. I had D-Day on the brain. j On Fri, May 13, 2011 at 12:58 PM, Matthew Petach mpet...@netflight.comwrote: On Fri, May 13, 2011 at 9:52 AM, Joly MacFie j...@punkcast.com wrote: The Internet Society is organizing IPv6 Day for June 6 2011. http://isoc.org/wp/worldipv6day/ Uh...unless there's been a sudden change of plans, I believe the date is still set for June *8th*, 2011. ^_^;; Matt -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: IPv6 foot-dragging
On 13 mei 2011, at 18:42, Matthew Petach wrote: The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless. If they announce a million /48s, they're actively hijacking space from 64,000 other people, and should be dealt with in an appropriate manner as a hijacker. :/ It would be mostly unused space. But that doesn't matter much, the point is that your prefix length filters can't stop this. If, on the other hand, the RIRs only give out /48s from one limited set of address space swaths and /44s from another, /32s from yet another and so on, then if there are 64k /48s that comes from say two /32s and three /33s for a total deaggregation risk of 224k prefixes. This is something your router may be able to handle. The *only* thing that will prevent that, in real-time are techniques like PGBGP or so-BGP. Not RIR policies. See above. All this BGP security stuff is still vaporware as of today. Hopefully that will change in the future but I'm not holding my breath for the benefits to kick in. (as a side note--in order to have your million /48s table explosion happen through *legitimate* holders of space deaggregating, it would require 64K individual choices to deaggregate in order to have that happen; we don't even have that many ASNs out there yet. I'm not losing sleep over that at this point.) If you boil it slowly enough the frog will sleep just fine. I participated in the IETF multi6/shim6 and IRTF RRG efforts for years but I have since come to the conclusion that routing table growth is not a real problem, because if it were people would be more willing to accept the downsides that come with the proposed solutions.
Re: Interested in input on tunnels as an IPv6 transition technology
On Thu, May 12, 2011 at 10:52 PM, Karl Auer ka...@biplane.com.au wrote: Hullo all. I'm working on a talk, and would be interested to know what people think is good about tunnels as an IPv6 transition technology, and what people think is bad about tunnels. It would probably be best to let me know off-list :-) but I'm happy to summarise back to the list. Any references you have to useful papers, articles, discussions etc would also be appreciated. I'm looking for both general problems and advantages, but also advantages and disadvantages specific to particular tunnel types. It would also be helpful to know from what perspective particular things are good or bad, in so far as it isn't obvious. A carrier has a different perspective than, say, a home user, who will have a different perspective again to an enterprise user. Many thanks in advance for your input. http://labs.ripe.net/Members/emileaben/6to4-why-is-it-so-bad http://labs.ripe.net/Members/gih/testing-teredo
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, 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 p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 14 May, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 356656 Prefixes after maximum aggregation: 161598 Deaggregation factor: 2.21 Unique aggregates announced to Internet: 176105 Total ASes present in the Internet Routing Table: 37552 Prefixes per ASN: 9.50 Origin-only ASes present in the Internet Routing Table: 31389 Origin ASes announcing only one prefix: 15082 Transit ASes present in the Internet Routing Table:5092 Transit-only ASes present in the Internet Routing Table:136 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 36 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 626 Unregistered ASNs in the Routing Table: 320 Number of 32-bit ASNs allocated by the RIRs: 1348 Number of 32-bit ASNs visible in the Routing Table:1071 Prefixes from 32-bit ASNs in the Routing Table:2417 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:156 Number of addresses announced to Internet: 2425507776 Equivalent to 144 /8s, 146 /16s and 79 /24s Percentage of available address space announced: 65.4 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 90.7 Total number of prefixes smaller than registry allocations: 148116 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:89380 Total APNIC prefixes after maximum aggregation: 29933 APNIC Deaggregation factor:2.99 Prefixes being announced from the APNIC address blocks: 85747 Unique aggregates announced from the APNIC address blocks:36599 APNIC Region origin ASes present in the Internet Routing Table:4441 APNIC Prefixes per ASN: 19.31 APNIC Region origin ASes announcing only one prefix: 1232 APNIC Region transit ASes present in the Internet Routing Table:705 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 47 Number of APNIC addresses announced to Internet: 614205216 Equivalent to 36 /8s, 156 /16s and 7 /24s Percentage of available APNIC address space announced: 77.9 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 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, 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:140013 Total ARIN prefixes after maximum aggregation:71448 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 112260 Unique aggregates announced from the ARIN address blocks: 45485 ARIN Region origin ASes present in the Internet Routing Table:14368 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix:5485 ARIN Region transit ASes
IPv6 gateway, was: Re: IPv6 foot-dragging
Thanks all for the helpful suggestions. It looks like I solved the problem by adjusting my forward chain. I have a the local network on eth0 and the external network on eth1 and my forward chain looked like: -I FORWARD -i eth0 -o eth1 -s 2001:db8::/64 -j ACCEPT -I FORWARD -i eth1 -o eth0 -d 2001:db8::/64 -j ACCEPT Changing it to the following made it work: -I FORWARD -s 2001:470:85cd::/64 -j ACCEPT -I FORWARD -d 2001:470:85cd::/64 -j ACCEPT I am not sure if it'd be less secure to not make it specific to the interfaces. How would I change the first set of rules, using the -i parameter and still make it work? I also have a 6in4 interface for the IPv6 tunnel. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: IPv6 foot-dragging
Joe Loiacono wrote: Jeroen Massar jer...@unfix.org wrote on 05/12/2011 09:19:21 AM: On 2011-May-12 15:14, Joe Loiacono wrote: Anyone know roughly the current default-free routing table size for IPv6? http://www.sixxs.net/tools/grh/status/ Awesome web-site. The world of IPv6 routing on one page. That is a great overview. And really, if a conservative institution such as the *catholic church* jumped on the IPv6 bandwagon there is really NO excuse for other companies to drag their heels, for crying out loud. ;-) http://www.sixxs.net/tools/whois/?AS8978 Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: Interested in input on tunnels as an IPv6 transition technology
On Thu, May 12, 2011 at 10:52 PM, Karl Auer ka...@biplane.com.au wrote: Hullo all. I'm working on a talk, and would be interested to know what people think is good about tunnels as an IPv6 transition technology, and what people think is bad about tunnels. It would probably be best to let me know off-list :-) but I'm happy to summarise back to the list. Any references you have to useful papers, articles, discussions etc would also be appreciated. I'm looking for both general problems and advantages, but also advantages and disadvantages specific to particular tunnel types. It would also be helpful to know from what perspective particular things are good or bad, in so far as it isn't obvious. A carrier has a different perspective than, say, a home user, who will have a different perspective again to an enterprise user. Many thanks in advance for your input. All I can say is that if it wasn't for HE tunnels I would be SOL. No provider here in east central Florida can even speak IPv6. Brighthouse is clueless. ATT told me maybe 2012 or 2013! So I tunnel to HE's POP in Miami. With this I can test and become dual stack operational. Yes, it is not as good as a native connection but in my position its the only game in town. Tom
Re: IPv6 gateway, was: Re: IPv6 foot-dragging
Jeroen van Aart wrote: Thanks all for the helpful suggestions. Obviously I need to do a better job using documentation IPv6 consistently, so ignore any inconsistencies in that regard. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: coprorations using BGP for advertising prefixes in mid-1990s
The Smarties in this part of the world don't come in boxes. :-) CJ On Thu, May 12, 2011 at 10:10 PM, bobby...@gmail.com wrote: And if you had a great question or response, would you get a box of Smarties? Robert -- Sent from my Palm Pre -- On May 12, 2011 10:54 PM, c...@daydream.com packetg...@gmail.com wrote: Yes images had names in them and in 1989 you could call cisco if your box was broken and Eileen would just send parts. Cathy On Thu, May 12, 2011 at 9:44 PM, Adrian Chadd adr...@creative.net.auwrote: On Fri, May 13, 2011, Hank Nussbacher wrote: I always liked seeing the string tli in the IOS bundle in those days. Whoa, you mean Cisco IOS images have built by names other than prod rel team ? (heh.) Adrian
Re: Routing study
their use agreement ended in 2008. telling the nanog world they are going to reuse it three years later is not exactly what most would consider prior notice to the registered holder that they would like to do a research project wiht resources that are not registered to them. /bill On Thu, May 12, 2011 at 12:02:55PM -0400, Greg Whynott wrote: On May 12, 2011, at 6:30 AM, bmann...@vacation.karoshi.com bmann...@vacation.karoshi.com wrote: erbt least notify me ahead of time if they want to futz around with prefixes that are not registered to them. erb . isn't that exactly what they just did, notified you ahead of time? the test starts on the 18th. helps to read before you jump! -g -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
Re: IPv6 gateway, was: Re: IPv6 foot-dragging
Jeroen van Aart wrote: -I FORWARD -i eth0 -s 2001:db8::/64 -j ACCEPT -I FORWARD -i eth1 -d 2001:db8::/64 -j ACCEPT Just in case if anyone'd be using it as an example. It's a good idea to make your rules more restrictive. Something like: -I FORWARD -j DROP -I FORWARD -s 2001:db8::/64 -j ACCEPT -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: coprorations using BGP for advertising prefixes in mid-1990s
Does no one remember EGP? Yes, I remember EGP every well. When we built the NSFNET T1 backbone in 1987, EGP was the only available routing protocol for exterior routing. We deployed it and used EGP to exchange routing information with the connected regional networks. Initially, it worked fine but then when the routing table and traffic grew, we observed that every 3 minutes, the network performance got a hit. After some investigation, we discovered that it was due to the fact that EGP did routing updates every 3 minutes by flooding the whole routing table to the peer and the process overwhelmed router processor. At that time, the processor on the router did both routing and forwarding. Fortunately, Yakov of IBM, Kirk from Cisco and we Merit were working on the development and testing of BGP, which was intended to replace EGP. BGP does incremental routing updates i.e. it sends its peer the delta whenever routing topology changes rather than flooding its peer with the whole routing table every 3 minutes. It saved a lot of processing power. In addition, it reduces routing convergence time since BGP sends its neighbors the updates whenever changes occurs. In the case of EGP, it may take as long as close to 3 minutes after a route change before the routing table got updated. In addition, BGP has loop detection capability due to its inclusion of AS path information. These were the technical reasons to replace EGP with BGP at the time. We worked with regional network reps and started to convert NSFNET to regional peers from EGP to BGP in early 1990s. I also created the BGP Deployment Work Group at IETF to push the deployment of BGP in the whole Internet. cheers! --Jessica From: Kevin Oberman ober...@es.net To: Dorn Hetzel d...@hetzel.org Cc: nanog@nanog.org Sent: Thursday, May 12, 2011 2:37 PM Subject: Re: coprorations using BGP for advertising prefixes in mid-1990s Date: Thu, 12 May 2011 17:15:17 -0400 From: Dorn Hetzel d...@hetzel.org The actual number would be considerably smaller as there were large (for some definition of large) block assignments of ASNs ~1000 or so to various academic networking entities such as NSFNet and regional networks as well as other Federal/Military networking organisations. -dorian Well, for one data point, I was issued 3492 around Spring of 1994. Does no one remember EGP? ASNs are MUCH older than BGP. And we were using BGPv3 prior to the existence of V4. We used BGPv4 back in the days when Tony Li would chastise us for reporting a bug in a 10 day old Cisco build saying that we could not expect BGPv4 code over a week old to work. He felt that we should deploy new code daily. The big push was to have v4 available before the old PRDB was frozen by Merit/NSFnet. (And, who remembers the PRDB?) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Routing study
the loan was for a short term project, at least as was explained to me. continuing to use it three years later ... not so good. esp since I have other use earmarked for it. please remove the swip and stop using the address space. /bill On Thu, May 12, 2011 at 02:00:45PM -0400, Vytautas Valancius wrote: I think he might be referring to the fact that the prefix supposedly used to conduct the test is his, not Georgia Tech's. Yes, it's indeed part of Bill's space, but on temporary loan (SWIP) for GENI/GaTech: --- whois -h rr.arin.net 168.62.16.0/24 [...] route: 168.62.16.0/21 descr: gtnoise.net (research group at GaTech) origin: AS47065 mnt-by: MNT-GIT source: ARIN # Filtered --- Sorry if it caused confusion! I should have synced this with Bill before announcement. Regards, Vytautas Valancius http://valas.gtnoise.net Georgia Tech
Re: IPv6 gateway, was: Re: IPv6 foot-dragging
On May 13, 2011, at 2:32 PM, Jeroen van Aart wrote: Jeroen van Aart wrote: -I FORWARD -i eth0 -s 2001:db8::/64 -j ACCEPT -I FORWARD -i eth1 -d 2001:db8::/64 -j ACCEPT Just in case if anyone'd be using it as an example. It's a good idea to make your rules more restrictive. Something like: -I FORWARD -j DROP -I FORWARD -s 2001:db8::/64 -j ACCEPT -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT I thought iptables processed rules in order until it found a match. In such a case, wouldn't you want those in the reverse order? Owen
Re: Routing study
My guess would be that someone didn't get the memo about the use agreement ending since they apparently still were listed in whois. Just a thought. Might have been a legitimate mistake from a position of ignorance, not knowing that they weren't still the registered resource holder. Owen On May 13, 2011, at 2:22 PM, bmann...@vacation.karoshi.com wrote: their use agreement ended in 2008. telling the nanog world they are going to reuse it three years later is not exactly what most would consider prior notice to the registered holder that they would like to do a research project wiht resources that are not registered to them. /bill On Thu, May 12, 2011 at 12:02:55PM -0400, Greg Whynott wrote: On May 12, 2011, at 6:30 AM, bmann...@vacation.karoshi.com bmann...@vacation.karoshi.com wrote: erb d I would appreciate it if they would at least notify me ahead of time if they want to futz around with prefixes that are not registered to them. erb helps to read before you jump! -g -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
BGP Update Report
BGP Update Report Interval: 05-May-11 -to- 12-May-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS19743 33082 2.1%4726.0 -- 2 - AS982924797 1.6% 26.1 -- BSNL-NIB National Internet Backbone 3 - AS11492 18070 1.1% 14.1 -- CABLEONE - CABLE ONE, INC. 4 - AS32528 17052 1.1%2131.5 -- ABBOTT Abbot Labs 5 - AS17974 16821 1.1% 12.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 6 - AS24560 15194 1.0% 13.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - AS427413652 0.9% 168.5 -- ERX-AU-NET Assumption University 8 - AS35931 13508 0.9%2251.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - AS44609 13326 0.8%4442.0 -- FNA Fars News Agency Cultural Arts Institute 10 - AS929913112 0.8% 11.9 -- IPG-AS-AP Philippine Long Distance Telephone Company 11 - AS840210875 0.7% 22.3 -- CORBINA-AS Corbina Telecom 12 - AS45595 10421 0.7% 28.8 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 13 - AS144209295 0.6% 13.9 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 14 - AS277389262 0.6% 27.3 -- Ecuadortelecom S.A. 15 - AS3454 8641 0.6%1080.1 -- Universidad Autonoma de Nuevo Leon 16 - AS9498 8524 0.5% 10.6 -- BBIL-AP BHARTI Airtel Ltd. 17 - AS9808 8204 0.5% 23.4 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 18 - AS8151 8169 0.5% 6.2 -- Uninet S.A. de C.V. 19 - AS358198021 0.5% 19.3 -- MOBILY-AS Etihad Etisalat Company (Mobily) 20 - AS7491 8016 0.5% 81.8 -- PI-PH-AS-AP PI-PHILIPINES TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS19743 33082 2.1%4726.0 -- 2 - AS44609 13326 0.8%4442.0 -- FNA Fars News Agency Cultural Arts Institute 3 - AS35931 13508 0.9%2251.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS32528 17052 1.1%2131.5 -- ABBOTT Abbot Labs 5 - AS496001284 0.1%1284.0 -- LASEDA La Seda de Barcelona, S.A 6 - AS245344928 0.3%1232.0 -- TRANSHYBRID-AS-ID PT. Transhybrid Communication 7 - AS277712189 0.1%1094.5 -- Instituto Venezolano de Investigaciones Cientificas 8 - AS3454 8641 0.6%1080.1 -- Universidad Autonoma de Nuevo Leon 9 - AS25170 891 0.1% 891.0 -- PRIVILIS PRIVILIS is an Internet Service Provider in Bordeaux, France 10 - AS13610 584 0.0% 584.0 -- PROVOCRAFT-NOVELTY - Provo Craft Novelty, Inc. 11 - AS276671108 0.1% 554.0 -- Universidad Autonoma de la Laguna 12 - AS3 551 0.0% 735.0 -- NET-CONNECT Net-Connect s.r.o. 13 - AS9476 456 0.0% 456.0 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 14 - AS445841768 0.1% 442.0 -- PTLINE-AS Progress Tehnologiya LLC 15 - AS50759 371 0.0% 371.0 -- DANONEPL-AS Danone Sp. z o.o. 16 - AS5868 368 0.0% 368.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 17 - AS38757 706 0.1% 353.0 -- ICONPLN-ID-AP PT. Indonesia Comnets Plus 18 - AS25516 325 0.0% 325.0 -- INIT-AS init AG fuer digitale Kommunikation 19 - AS187043154 0.2% 315.4 -- T-SYSTEMS-NA - T-Systems North America, Inc. 20 - AS35772 287 0.0% 287.0 -- SWAP-AS Swap Technologies SRL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 200.23.202.0/248617 0.5% AS3454 -- Universidad Autonoma de Nuevo Leon 2 - 130.36.34.0/24 8518 0.5% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.35.0/24 8518 0.5% AS32528 -- ABBOTT Abbot Labs 4 - 63.211.68.0/22 7234 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 202.92.235.0/247075 0.4% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 6 - 178.22.72.0/21 0.4% AS44609 -- FNA Fars News Agency Cultural Arts Institute 7 - 178.22.79.0/24 6654 0.4% AS44609 -- FNA Fars News Agency Cultural Arts Institute 8 - 65.122.196.0/246432 0.4% AS19743 -- 9 - 221.121.96.0/196290 0.4% AS7491 -- PI-PH-AS-AP PI-PHILIPINES 10 - 198.140.43.0/246126 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 11 - 72.164.144.0/245337 0.3% AS19743 -- 12 - 65.163.182.0/245329 0.3% AS19743 -- 13 - 65.162.204.0/245328 0.3% AS19743 -- 14 - 66.238.91.0/24 5328 0.3% AS19743 -- 15 - 66.89.98.0/24 5327 0.3% AS19743 -- 16 - 2.92.85.0/24 5196 0.3% AS8402 -- CORBINA-AS Corbina Telecom 17 - 202.153.174.0/24 3480 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications
The Cidr Report
This report has been generated at Fri May 13 21:12:09 2011 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
06-05-11359540 210993
07-05-11360101 211009
08-05-11359995 211087
09-05-11360076 211487
10-05-11360091 211606
11-05-11360431 211602
12-05-11360672 211886
13-05-11360084 211906
AS Summary
37650 Number of ASes in routing system
15845 Number of ASes announcing only one prefix
3646 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
110450944 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').
--- 13May11 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 359750 211854 14789641.1% All ASes
AS6389 3646 260 338692.9% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 1980 398 158279.9% TWTC - tw telecom holdings,
inc.
AS4766 2452 927 152562.2% KIXS-AS-KR Korea Telecom
AS6478 1678 320 135880.9% ATT-INTERNET3 - ATT Services,
Inc.
AS22773 1329 96 123392.8% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS19262 1498 298 120080.1% VZGNI-TRANSIT - Verizon Online
LLC
AS18566 1822 672 115063.1% COVAD - Covad Communications
Co.
AS4755 1462 373 108974.5% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS1785 1779 761 101857.2% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS7552 1105 124 98188.8% VIETEL-AS-AP Vietel
Corporation
AS10620 1477 513 96465.3% Telmex Colombia S.A.
AS28573 1313 418 89568.2% NET Servicos de Comunicao S.A.
AS18101 934 145 78984.5% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS7545 1549 769 78050.4% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS24560 1151 391 76066.0% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS4808 1067 337 73068.4% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS8151 1372 642 73053.2% Uninet S.A. de C.V.
AS3356 1118 454 66459.4% LEVEL3 Level 3 Communications
AS7303 931 272 65970.8% Telecom Argentina S.A.
AS11492 1279 625 65451.1% CABLEONE - CABLE ONE, INC.
AS17488 935 314 62166.4% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS17676 665 70 59589.5% GIGAINFRA Softbank BB Corp.
AS855634 56 57891.2% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS14420 667 92 57586.2% CORPORACION NACIONAL DE
TELECOMUNICACIONES - CNT EP
AS22561 913 355 55861.1% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS3549 950 395 55558.4% GBLX Global Crossing Ltd.
AS4780 747 195 55273.9% SEEDNET Digital United Inc.
AS22047 555 30 52594.6% VTR BANDA ANCHA S.A.
AS17974 1834 1316 51828.2% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS4804 578 83 49585.6% MPX-AS Microplex PTY LTD
Total 39420117012771970.3% Top
Re. EGP Remembered
Does no one remember EGP? To add to what Jessica already said about EGP, I can add that there were basically 3 metric values: 0 - directly connected 1-254 - not directly connected 255 unavailable So there was no concept of hop counts or quality of the route other than directly connected. I don't recall why the metric of 255 would ever be used as apposed to just not advertising a route. Walt
Re: IPv6 gateway, was: Re: IPv6 foot-dragging
Owen DeLong wrote: On May 13, 2011, at 2:32 PM, Jeroen van Aart wrote: -I FORWARD -j DROP -I FORWARD -s 2001:db8::/64 -j ACCEPT -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT I thought iptables processed rules in order until it found a match. In such a case, wouldn't you want those in the reverse order? I think hat's the case with -A, but with -I the above is the right order. Or at least it works here. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: IPv6 gateway, was: Re: IPv6 foot-dragging
On May 13, 2011, at 3:33 PM, Jeroen van Aart wrote: Owen DeLong wrote: On May 13, 2011, at 2:32 PM, Jeroen van Aart wrote: -I FORWARD -j DROP -I FORWARD -s 2001:db8::/64 -j ACCEPT -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT I thought iptables processed rules in order until it found a match. In such a case, wouldn't you want those in the reverse order? I think hat's the case with -A, but with -I the above is the right order. Or at least it works here. DOH! Arcane syntax failure on the part of my brain's parser. Of course if you are Inserting rather than Appending. Owen
Re: dot xxx live or not?
;; ANSWER SECTION: xxx.300 IN NS a0.xxx.afilias-nst.info. xxx.300 IN NS c0.xxx.afilias-nst.info. xxx.300 IN NS a2.xxx.afilias-nst.info. xxx.300 IN NS b0.xxx.afilias-nst.org. xxx.300 IN NS b2.xxx.afilias-nst.org. xxx.300 IN NS d0.xxx.afilias-nst.org. ;; Query time: 100 msec ;; SERVER: 10.0.2.24#53(10.0.2.24) ;; WHEN: Fri May 13 12:10:59 2011 ;; MSG SIZE rcvd: 162 Anyway, I'd recommend them to read RFC2182 ... You might be interested in this cool new technology called multicast. R's, John
Re: dot xxx live or not?
You might be interested in this cool new technology called multicast. in this context you may be probably talking about anycast. there are few details but without digging in too much, there are at least two name servers for which the packets are flowing through the same exact route and end point as12041.xe-6-0-4.ar2.iad1.us.nlayer.net , -J
Clearing DF bits...
Hi there all, Years ago it used to be a somewhat common practice to clear the DF bit on packets, either on all packets, or just on those that that you were going to shove through a tunnel (I think the netscreen command was something like set vpn foo df-bit clear, cisco had something funky with policy routing IIRC,etc). This was done both to deal with multiple encapsulations and for the folk that block all ICMP for security reasons. Is this practice still common / do you know of anyone still doing it? W
Re: Clearing DF bits...
On May 13, 2011, at 6:02 PM, Warren Kumari war...@kumari.net wrote: Years This was done both to deal with multiple encapsulations and for the folk that block all ICMP for security reasons. I did it as recently as last month, for the same reasons.
Re: Yahoo and IPv6
On Tue, May 10, 2011 at 11:22 AM, Owen DeLong o...@delong.com wrote: In other words, Igor can't turn on records generally until there are 182,001 IPv6-only users that are broken from his lack of records. There will be no IPv6-only users. There will only be users with better IPv6 connectivity than IPv4 connectivity. This will be interesting. Personally, I think it will be more along the lines of when there are more IPv6 only eye-balls with broken IPv4 than there are IPv4 eye-balls with broken IPv6, will become the obvious solution. Agreed. The problem is how to get there. Given that 0.2% of Google users has IPv6 today, my money is still on this taking a while.
Re: Yahoo and IPv6
On May 14, 2011, at 2:12 AM, Lorenzo Colitti wrote: On Tue, May 10, 2011 at 11:22 AM, Owen DeLong o...@delong.com wrote: In other words, Igor can't turn on records generally until there are 182,001 IPv6-only users that are broken from his lack of records. There will be no IPv6-only users. There will only be users with better IPv6 connectivity than IPv4 connectivity. My Desktop is not able to make any IPv4 socket connections anymore. I get Protocol not supported. So there are IPv6-only users, already bitten by no . So that's -1 from me. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.
RE: Yahoo and IPv6
My Desktop is not able to make any IPv4 socket connections anymore. I get Protocol not supported. So there are IPv6-only users, already bitten by no . So that's -1 from me. Sounds like a job for NAT64/DNS64
Re: Yahoo and IPv6
My Desktop is not able to make any IPv4 socket connections anymore. I get Protocol not supported. So there are IPv6-only users, already bitten by no . So that's -1 from me. i choose to only run decnet ii, and the world should fix my connectivity problem. randy
Re: Yahoo and IPv6
On Fri, May 13, 2011 at 10:27 PM, Randy Bush ra...@psg.com wrote: My Desktop is not able to make any IPv4 socket connections anymore. I get Protocol not supported. So there are IPv6-only users, already bitten by no . So that's -1 from me. i choose to only run decnet ii, and the world should fix my connectivity problem. randy Your search for DecNet Phase II to IPv6 gateway returned 0 results.
