Re: IPv6 BGP table size comparisons
Jared Mauch wrote: Maybe this is a good place to start.. http://www.sixxs.net/tools/grh/compare/ - Jared On Dec 21, 2010, at 11:32 AM, Frank Bulk wrote: A week or more ago someone posted in NANOG or elsewhere a site that had made a comparison of the IPv6 BGP table sizes of different operators (i.e. HE, Cogent, Sprint, etc), making the point that a full view might take multiple feeds. I think that website also had text files with the comparisons. But I can't find that e-mail or website anywhere! Does anyone know where that listserv posting or website is? Also route-views6.routeviews.org has several feeds. - Kevin
Re: Where to go for connectivity in VA / DC
bas wrote: Hi, We've recently opened a POP in northern Virginia. The DC does not have a lot of connectivity options to choose from. So we've ordered dark fiber to Equinix Ashburn DC2, we will light it up with our own DWDM, and pick up connectivity there. We do however need a second point to pick up connectivity for redundancy purposes. (that runway from IAD is pretty scary) Initially we had thought to pick up that connectivity at Coresite K-street. However many of the carriers we use are not available at K-street. 8100 Boone Blvd. - Kevin
Re: ISP support for use of 4-byte ASNs in peering
John Curran wrote: Folks - Is there a public list somewhere of service providers that do not support 4-byte autonomous system numbers when peering? (if not, should there be one?) At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. This is obviously a less than desirable situation, and it appears that it is not trending towards resolution at this time. Perhaps you meant to send this to c-nsp and re-worded it slightly? - Kevin
Re: Aqua Conduit for 10G multi-mode?
Michael J McCafferty wrote: All, Orange innerduct/split-loom tubing for multi-mode, yellow for single-mode... Where's the aqua for the aqua OM3 fiber? I feel like the Ethernet fashion police, but it's a horrible color clash for aqua fiber dressed in yellow or orange. Where is my aqua innerduct and/or tubing? Does anyone make it? I'm guessing that there isn't much of a market for that since 10Gbase-LR is rated from 2m-10km and most people don't use conduit for runs less than 2 meters :) - Kevin
Re: Advice on BGP traffic engineering for classified traffic
Jack Bates wrote: I'm curious if anyone has a pointer on traffic manipulation for classified traffic. Basics, I have a really cheap transit connection that some customers are paying reduced rates to only use that connection (and not my other transits). Though I've considered support for cases where NSP peering disputes break out. While I can advertise their networks out the correct transit for return traffic, I still have to figure out how to handle egress traffic. I'm guessing the crux of it is policy routing based on source address, but I'm interested in ways to engineer it to easy management and scalability. I've considered the possibility of an l3vpn to interconnect customers that are not requiring full routes, and possibly some type of vpls tunnel terminated at the necessary router for customers who need full routes. Thoughts, pointers, suggestions? One simple way to do this is with two routers each with a different table. One for your expensive transit and one for your cheap transit. Each customer's vlan is on both routers with vrrp preference set to the desired router for non-bgp customers. expensive transit customers have the ability to failover to the cheap router. you may or not want to allow the reverse to occur. - Kevin
Re: Colocation providers and ACL requests
Christopher Pilkington wrote: Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as: deny udp any a.b.c.d/24 eq 80 …to refuse and tell us we must subscribe to their managed DDOS product? We have always accommodated temporary ACL's for active DDOS attacks. I think that is fairly standard across the ISP/hosting industry. I do feel it is bad practice to regularly implement customer specific ACL's on routers. If a customer wants a managed firewall we have a full range of those services available. - Kevin
Re: economic value of low AS numbers
Dave Hart wrote: AS path geeks: At the risk of invoking ire and eliciting comparisons to the widely-reviled and growing practice of selling IPv4 addresses, I'm wondering if anyone has sold legacy AS numbers for quick cash. I have heard first hand stories of folks being offered 5 figures for four digit ASN's in the past (and they did not sell btw). That was before ARIN started recycling unused short ASN's two years ago. There was a three month period in 2009 where almost every ASN assigned by ARIN was < 1 as they burned through the backlog. - Kevin
Re: IPv6 RA vs DHCPv6 - The chosen one?
Ravi Duggal wrote: We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends DHCPv6 to do what RA does. And now, we have draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise the NTP information that is currently done via DHCPv6. My question is, that which then is the more preferred option for the operators? In many environments RA is a catastrophic disaster. Some operators need to be able to do everything with RA turned off on routers, disabled on hosts and filtered on switches. - Kevin
Re: subnet prefix length > 64 breaks IPv6?
Iljitsch van Beijnum wrote: On 24 Dec 2011, at 6:32 , Glen Kent wrote: I am trying to understand why standards say that "using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], .. " [reference RFC 5375] For stateless autoconfig the issue is that it uses 64-bit "interface identifiers" (~ MAC addresses) that are supposed to be globally unique. You can't shave off bits and remain globally unique. With SEND a cryptographic hash that can be used to determine address ownership is stored in the interface identifier. Here shaving off addresses reduces security. Also somehow the rule that all normal address space must use 64-bit interface identifiers found its way into the specs for no reason that I have ever been able to uncover. On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on > /64 is somewhat less efficient. The 64 bit "mattress tag" is one of the cute historical quirks of IPv6. Of course in practice we use all sorts of longer prefixes for the same reasons we do in IPv4: Loopback ips, Limiting the scope of infrastructure links and server subnets, the many uses of more specific static routes, null routes (including the very important /128 ddos blackhole). The good news is that vendors recognized the need to efficiently route all 128 bits. Is there any known platform that does not? I'm starting to think this is an ancient myth that keeps resurfacing. - Kevin
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
Steven Bellovin wrote: VRRP? The Router Discovery Protocol (RFC 1256). But given how much more reliable routers are today than in 1984, I'm not convinced it's that necessary these days. VRRP is an absolutely essential protocol in today's Internet. We use it on every non-bgp customer port. Routers still have routing and performance issues, hardware failures and routine software upgrades. The layer2 infrastructure between the routers and the customer is also susceptible to various hardware/software/maintenance problems and fiber cuts and VRRP can help work around some of those. A nice side benefit is the virtual mac addresses that allow for migration to new routers without the mac address of the default gateway changing. One key advantage of VRRP over RA's is that you can have multiple instances on the same layer2 network (vlan) with different functions. It is very common to have different "routers" (routers, firewalls or load balancers) on the same vlan with different functions in hosting environments. It is also sometimes necessary to have multiple default gateways on the same vlan for load balancing or traffic engineering. RA/auto configuration is incompatible with all but the most trivial configurations. - Kevin
Re: NANOG 40 agenda posted
Jared Mauch wrote: Some providers (eg: www.us.ntt.net) have their sales/marketing path ipv6 enabled. Perhaps this will help self-select customers that are clued? ;) Most European/Asian based providers/peers don't even blink when I mention turning up IPv6. Not so with most US based networks. The upcoming nanog meeting I think will have native IPv6 connectivity (not a tunnel). It's a good time for folks to play around with it. Visit the ipv6 enabled websites from the lan. Submit a nice 10 min talk saying what you loved and what you hated about the ipv6 network. Better yet, nanog would be a good place for folks to arrange IPv6 peering. - Kevin
Re: IPv6 Deployment (Was: Re: NANOG 40 agenda posted)
Donald Stahl wrote: If ARIN is going to assign /48's, and people are blocking anything longer than /32- well then that's a problem :) To be specific, ARIN is currently assigning up to /48 out of 2620::/23. I noticed that http://www.space.net/~gert/RIPE/ipv6-filters.html has the following entry in the "strict" list: ipv6 prefix-list ipv6-ebgp-strict permit 2620::/23 ge 24 le 32 which is not particularly useful. It should be 'le 48' if the intent is to track RIR assignment policies. - Kevin
Re: Router for Metro Ethernet
Jeffrey Negro wrote: In our case I believe we would be dealing with just static routes and a lines of ACL. In that case a linux/FreeBSD router would work great. - Kevin
Re: Rate of growth on IPv6 not fast enough?
sth...@nethelp.no wrote: *If* the whole IPv6 config can be driven from the same database. For the time being, DHCPv6 cannot deliver a default gateway to customers (and there is a religious faction within the IPv6 community which seem to want to prevent this at all costs). s/IPv6/IETF/ I don't know of anyone outside of the IETF promoting the insanity of a DHCP server not having the option of giving out a gateway address. - Kevin
Re: Lightly used IP addresses
Randy Bush wrote: (and to answer Randy - the only control over the administration is based on the policies adopted. Reduce the corpus of applicable policy if that is your desire.) we created careers for junior policiy weenies. arin and other rirs have become well-funded playgrounds for the semi-clued who think they can and should tell others how to run their businesses, operate the internet, .. Yet most of the bad ideas in the past 15 years have actually come from the IETF (TLA's, no end site multihoming, RA religion), some of which have actually been "fixed" by the RIR's. The RIR's provide uniqueness and have done a good job at that. Who cares how they make the sausage? - Kevin
Re: Phoenix Area Network Issues?
Something is definately happening, 50% drop in inbound traffic to our PHX datacenter across all transit providers. - Kevin Ray Sanders wrote: Are there any fiber cuts or other routing issues anyone in the Phoenix area is aware of? Thanks.
Re: Phoenix Area Network Issues?
Kevin Loch wrote: Something is definately happening, 50% drop in inbound traffic to our PHX datacenter across all transit providers. - Kevin Ray Sanders wrote: Are there any fiber cuts or other routing issues anyone in the Phoenix Update: Qwest did not appear to be affected by this, Highwinds traffic has just returned to normal, Level3 and GBLX still affected. - Kevin
Re: Eye protection in DWDM systems -- what threshold?
On Tue, Jun 09, 2009 at 04:06:58PM -0400, Deepak Jain wrote: This conversation has gone places I didn't expect. Leo, that card is pretty cool, but for a few hundred $$ more, you can get a light meter (if someone is smart enough to use the card...) In a pinch the camera on a MacBook pro can be used to detect presence of IR light. Here's light from a 10Gbase-LR xenpak: http://www.majhost.com/gallery/kl/Macbook/macbook-laser-camera.jpg It's easier to see when previewing in real time than in the static picture but it does require careful aim. - Kevin
Re: Repeated Blacklisting / IP reputation
Benjamin Billon wrote: Why don't we just blacklist everything and only whitelist those we know are good? Note we all could start using IPv6 and avoid this problem altogether. Yeah. When ISP will start receiving SMTP traffic in IPv6, they could start to accept whitelisted senders only. "IPv6 emails == clean" Utopian thought? Are you not receiving SMTP traffic via IPv6 yet? Received: from s0.nanog.org ([IPv6:2001:48a8:6880:95::20]) - Kevin
Re: Wireless STM-1 link
Brian Reichert wrote: On Thu, Sep 10, 2009 at 11:55:40AM +0200, Rens wrote: All the interfaces are forced to 1Gbps and full duplex. I thought that with 1000T, you need to keep autonegotiation in place: http://etherealmind.com/2008/07/15/ethernet-autonegotiation-works-why-how-standard-should-be-set/ "A major problem is that many people are also hard setting Gigabit Ethernet , and this is causing major problems. Gigabit Ethernet must have auto-negotiation ENABLED to allow negotiation of master / slave PHY relationship for clocking at the physical layer. Without negotiation the line clock will not establish correctly and physical layers problems can result." Further: http://en.wikipedia.org/wiki/Autonegotiation "The debatable portions of the autonegotiation specifications were eliminated by the 1998 version of IEEE 802.3. In 1999, the negotiation protocol was significantly extended by IEEE 802.3ab, which specified the protocol for gigabit Ethernet, making autonegotiation mandatory for 1000BASE-T gigabit Ethernet over copper." Note the 'mandatory'... I'm in the "it's not 1996 anymore, let autonegotiation do it's job" camp. I occasionally see folks who religiously "lock down" all ports only to create the very duplex mismatches they are trying to avoid. Engineers, equipment, port positions and operating systems can change over time defeating even the best laid plans for total port control. - Kevin
Re: Multi-homed implementation and BGP convergence time
Seth Mattinen wrote: Jay Hennigan wrote: "Tier 1", "tier 2" etc. are terms used primarily by salespeople, and don't have a lot to do with technical matters. Sure it does. If you're multihoming it will increase your AS path length. There is no general correlation between AS path length and whether or not a network pays to exchange traffic. There is a noticeable correlation between cost and local-preference, as-path prepending, metric setting and other ways networks control how they send you traffic. This is affected by peering selectivity as well as transit prices. - Kevin
Re: ISP customer assignments
Owen DeLong wrote: Part of the reason that 128 bits was chosen (64 bits is FAR more than enough) was that it allowed for 64 bits of stateless auto-configuration (IEEE was already pushing EUI-64) within each network and still provided more than enough network numbers. I'm sure the Really Smart People over at the IETF could have figured out a way to do auto configuration with "just" 16 bits of /112 (or a /48 of 64 bit space). It will be interesting to see if things evolve to using /112's anyway just to escape auto configuration. I use them for router links and server subnets because it's a convenient boundary for notation. - Kevin
Re: Practical numbers for IPv6 allocations
David Conrad wrote: On Oct 6, 2009, at 6:13 PM, Nathan Ward wrote: My understanding is that the RIRs are doing sparse allocation, as opposed to reserving a few bits. I could be wrong. Last I heard, with the exception of APNIC and contrary to what they indicated they'd do prior to IANA allocating the /12s, you are indeed wrong. I'd be happy to hear things have changed. Only APNIC is doing "bisection" style assignments today: 20091001|apnic|AU|ipv6|2402:c00::|32|allocated 20091001|apnic|SG|ipv6|2402:400::|32|allocated 20091005|apnic|JP|ipv6|2402:1400::|32|allocated 20091006|apnic|NZ|ipv6|2402:1c00::|32|allocated 20090930|arin|US|ipv6|2607:fd70::|32|allocated 20090930|arin|CA|ipv6|2607:fd78::|32|allocated 20091001|arin|US|ipv6|2607:fd80::|32|allocated 20091006|arin|US|ipv6|2607:fd88::|32|allocated 20091005|ripencc|RU|ipv6|2a00:1440::|32|allocated 20091005|ripencc|SI|ipv6|2a00:1448::|32|allocated 20091005|ripencc|IE|ipv6|2a00:1450::|32|allocated 20091005|ripencc|BE|ipv6|2a00:1458::|32|allocated 20090709|lacnic|PY|ipv6|2800:3a0::|32|allocated 20090714|lacnic|CL|ipv6|2800:3b0::|32|allocated 20090807|lacnic|GY|ipv6|2800:3c0::|32|allocated 20090903|lacnic|AR|ipv6|2800:3d0::|32|allocated 20090708|afrinic|GH|ipv6|2001:43c0::|32|allocated 20090729|afrinic|EG|ipv6|2001:43c8::|32|allocated 20090813|afrinic|KE|ipv6|2001:43d0::|32|allocated 20090909|afrinic|ZA|ipv6|2001:43d8::|32|allocated - Kevin
Re: 32-bit AS numbers
Greg Hankins wrote: We also started a Wiki with content based on the presentation that has more updated information, including a current list of vendor support. If you see a vendor missing, let us know and we can update the list. Or better yet, create an account and add some content yourself :-). http://as4.cluepon.net/index.php/Main_Page While it's good to see support _finally_ in 2.2SX, I still don't see it in 12.2SR (for rsp720). It's almost like Cisco has no idea how many of these things are actually used on the Internet. - Kevin
Re: IPv6 internet broken, Verizon route prefix length policy
Adrian Chadd wrote: On Tue, Oct 13, 2009, valdis.kletni...@vt.edu wrote: You get some substantial wins for the non-TE case by being able to fix the legacy cruft. For instance, AS1312 advertises 4 prefixes: 63.164.28.0/22, 128.173.0.0/16, 192.70.187.0/24, 198.82.0.0/16 but on the IPv6 side we've just got 2001:468:c80::/48. And we're currently advertising *more* address space in one /48 than we are in the 4 IPv4 prefixes - we have a large chunk of wireless network that is currently NAT'ed into the 172.31 space because we simply ran out of room in our 2 /16s - but we give those users globally routed IPv6 addresses. I suggest you're not yet doing enough IPv6 traffic to have to care about IPv6 TE. I think he was pointing out that extra routes due to "slow start" policies should not be a factor in v6. My guess is that is about half of the "extra" routes announced today, the other half being TE routes. Speaking of TE, it's going to be interesting to see how we deal with that. We can't expect everyone to accept any /48 that gets announced. I'm still waiting for the first time someone blows up the Internet by announcing all 65536 /48's in their /32. I'm amazed it hasn't happened yet. Stricter use of the IRR might help if there wasn't rampant auto proxy registering going on. RPKI may be the answer since that can't be proxy-registered. That would at least mitigate router bugs and carelessness. The issue of what intentional TE routes are seen as "acceptable" is another issue. - Kevin
Re: ISP customer assignments
Chris Adams wrote: I guess I'm missing something; what in section 3 is this referring to? I can understand /64 or /126 (or maybe /124 if you were going to delegate reverse DNS?), but why /112 and "16 bits for node identifiers" on a point-to-point link? The only thing special about /112 is that it is on a ":" boundary so it makes for some nice numbering plans: Let's say you set aside 2001::0:1::/64 for /112's link 1: 2001::0:1::1:1 2001::0:1::1:2 link 2: 2001::0:1::2:1 2001::0:1::2:2 This :1, :2 arrangement seems to be common but for internal links you could make the last hextet be a unique id for the specific router. That could use more than a few bits in a large network. - Kevin
Re: IPv6 Deployment for the LAN
Nathan Ward wrote: On 19/10/2009, at 1:10 AM, Owen DeLong wrote: On Oct 18, 2009, at 3:05 AM, Nathan Ward wrote: On 18/10/2009, at 11:02 PM, Andy Davidson wrote: On 18 Oct 2009, at 09:29, Nathan Ward wrote: RA is needed to tell a host to use DHCPv6 This is not ideal. Why? Remember RA does not mean SLAAC, it just means RA. Because RA assumes that all routers are created equal. RFC4191 In some cases different devices on a segment need a different default router (for default). This is the fundamental problem with RA's, they shotgun the entire segment. Because RA is harder to filter. DHCP in IPv4 was hard to filter before vendors implemented it, too. Because the bifercated approach to giving a host router/mask information and address information creates a number of unnecessary new security concerns. Security concerns would be useful to explore. Can you expand on this? What would be useful would be having the option to give a default router to a dhcpv6 client, and having vrrpv6 work without RA's. Why can't we have those options in our toolbox in addition to this continuously evolving RA+hacks? - Kevin
Re: IPv6 Deployment for the LAN
TJ wrote: In some cases different devices on a segment need a different default router (for default). This is the fundamental This capability is also defined, "more specific routes" - but no one encouraged any vendors that I know of to support it - so they don't. Big demand? by "Default" I meant 0.0.0.0/0, not more specifics. problem with RA's, they shotgun the entire segment. As opposed to a standard deployment, where the DHCP server provides the same information to every host on that link ... ??? Not always. The DHCP server can be aware of specific clients by mac address and give different options (and even pseudo-static IPs). DHCP server is not always running on a router so adding this functionality to routers won't help. - Kevin
Re: IPv6 Deployment for the LAN
Iljitsch van Beijnum wrote: On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. And DHCPv6 is just a case of very bad design, don't expect it to work well without bending over backwards even farther than you're used to with DHCPv4. It's time for this DHC stuff to reach its final resting place. Then don't use it. That's why it's called an Option :) However some of us actually need to use this stuff and sometimes in ways not imagined by the IETF. - Kevin
Re: IPv6 Deployment for the LAN
Iljitsch van Beijnum wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see. There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways. Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility. Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap. Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated. Stop trying to break the internet and I'll treat you like an adult. At conferences I keep hearing "It would be great if the IETF had more operator input." Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work. How do we fix that? - Kevin
Re: about interdomain multipath routing.
Bin Dai wrote: Hi: These days, in the research, the interdomain multipath routing is pretty hot but i doubt its actually use in reality. Does anyone tell me any use of interdomain multipath routing like multipath BGP in the real world? "BGP multipath" is extremely common and used to load balance multiple links to the same neighbor ASN. As implemented by popular vendors it requires most attributes (like as-path) to be identical. Did you really mean this or something that uses different as-paths in parallel? - Kevin
Re: Internet partitioning event regulations
William Herrin wrote: On Wed, Nov 5, 2008 at 12:12 PM, Larry Sheldon <[EMAIL PROTECTED]> wrote: Lamar Owen wrote: There are three ways that I know of (feel free to add to this list) to limit the events: 1.) As you mentioned, regulation (or a government run and regulated backbone); Which government? First, let me say that I think peering regulation is a terrible idea. No matter how cleverly you plan it, the result will be that fewer small companies can participate. That's the character of regulation: compliance creates more barriers to entry than it removes. The problem isn't that which networks don't peer with each other it is that some networks don't buy transit from anyone. That is what causes partition related outages and distortions in peering policies. If regulation could be part of the 'solution' then that would be the place to start. But despite the flaws with the current environment it really isn't that bad and any regulation would likely be a disaster for the industry. - Kevin
Re: Catalyst 6500 High Switch Proc
Jon Lewis wrote: On Sat, 15 Nov 2008, Philip L. wrote: This is on a Sup720-3BXL by the way: 'sh mls netflow table-con detailed:' Earl in Module 5 Detailed Netflow CAM (TCAM and ICAM) Utilization TCAM Utilization : 100% ICAM Utilization : 6% Netflow TCAM count : 262024 Netflow ICAM count : 8 Netflow Creation Failures : 2085847 Netflow CAM aliases : 0 This looks like the same issue I ran into not long ago. Switch your netflow over from full to sampled...you lose lots of data, but your hardware can't handle full netflow for your traffic level. AFAIK, your only other options are to mess with the mls aging timers (shorten them) or buy cards with DFC and hope that gets you enough additional netflow capacity for the interfaces your collecting. http://www.gossamer-threads.com/lists/cisco/nsp/94953 Hopefully he is not trying to use netflow for accounting/billing. I use: mls sampling packet-based 1024 8192 As it is a convenient factor of ~1000 from the real numbers. 1Gbit/s of traffic shows up as 1Mbit/s. This has been accurate enough for anything I have wanted to look at like per-AS traffic. - Kevin
Re: IPv6 routing /48s
Christopher Morrow wrote: GRH is too slow to get me an answer on what it thinks the v6 table size should be :( Geoff says though: 1627 routes (http://bgp.potaroo.net/v6/as2.0/index.html) route-views6 is another good place to look. 1481 is the max seen there. Perhaps there are some internal/customer routes in the feed Geoff is using? route-views6.routeviews.org> sh bgp sum (output snipped for brevity) - Kevin
Re: Level 3 issues
marco wrote: From what I heard, it was some some malfunction with a router in Washington D.C. which terminated a 100GB bundle from Paris. It was carring about 50GB at the time of the failure. Not sure why routes within the US would be effected. We connect to level3 in Ashburn/DC and saw traffic drop 50% in both directions on that port. Testing showed 100% loss on 50% of the flows. We shut that port down and now it won't come back up. I have link but no arp for their IP. This is a new link that was turned up in the past few weeks. - Kevin
Re: IPv6 Confusion
David Conrad wrote: Yeah. Rants about the IETF should probably be directed elsewhere. Just how DO we get the message to the IETF that we need all the tools we have in v4 (DHCP, VRRP, etc) to work with RA turned off? - Kevin
Re: IPv6 Confusion
Leo Bicknell wrote: It wouldn't be so bad if we could just turn it off. Indeed, in part you can. On a static LAN there is no need for RA's. Static IP the box, static default route, done and done. VRRPv6 however is relevant to static environments and also needs to (optionally) work with RA turned off. - Kevin
Re: options for full routing table in 1 year?
Jo Rhett wrote: Cisco 6500/7600 with SUP720-3BXL handles 1mil routes Sounds great on paper but a sup720 can barely handle full tables today. Depending on how many full tables you take and what else you are doing with it, cpu resources are unreasonably tight. Having many vlans with vrrp and snmp polling also adds significant cpu load. Also, beware the memory consequences of 'maximum-paths' in bgp context. 8 full tables from a transit provider with maximum-paths=8 will exceed available ram on a sup720. With 6 you will have ~128m free. Fortunately this is not a common configuration. The rsp720 is substantially better at both of these issues. However the rsp720 is only supported in 76xx chassis (officially) so chassis selection is important for future upgrades. - Kevin
Re: Important New Requirement for IPv4 Requests [re "impacting revenue"]
Shane Ronan wrote: C) Are ARIN's books open for public inspection? If so, it might be interesting for the group to see where all our money is going, since it's obviously not going to outreach and solution planning. Perhaps it is being spent in a reasonable manner, and the fees are where they need to be to sustain the organizations reasonable operations, but perhaps not. A quick search of the website found this: https://www.arin.net/about_us/corp_docs/annual_rprt.html - Kevin
Re: IPv4 Anycast?
Patrick W. Gilmore wrote: On Apr 22, 2009, at 4:35 PM, Jack Bates wrote: Zhenkai Zhu wrote: I just want to make sure if I understand correctly. You mean that the anycasted address space can be announced in different places yet with the same origin AS? Yes, and it is commonly done. I was under the impression anycast services with homogeneous origin AS was far more common than the heterogeneous. Almost all the instances I know of use homogeneous origin AS. I'd be interested in statistics either way. 192.88.99.0/24, 2002::/16, and 2001::/32 are some notable examples of heterogeneous origin AS. - Kevin
Re: dotted AS numbers in asn.txt
Andreas Ott wrote: Hi, since when does ftp://ftp.arin.net/info/asn.txt contain dotted AS numbers? Where is the new formatting documented, asn.h ? http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-04.txt 6.0 B6WM110-ARIN (Tech) 6.1 ASN4-TELUSAAT-ARIN (Abuse), FTS1-ARIN (Tech), TBOTP-ARIN (Tech) 6.3 H6KML9-ARIN (Tech) 6.5 ISC-32AS ISCAT-ARIN (Abuse), JDA87-ARIN (Tech) 6.6 BLUEFIN-TRADING HOSTM912-ARIN (Abuse) "Your search - AS number 6.5 ISC32-AS - did not match any documents. " Fwiw, the ARIN website search function does understand asdot notation. -Kevin
Re: Geographic map of IPv6 availability
Nathan Ward wrote: On 6/10/2007, at 3:18 AM, Stephen Wilcox wrote: Given the above, I think there is no myth.. ! That's because the 'v6 network' is broken enough that putting records on sites that need to be well reachable is a bad idea. For example, due mainly to Vista's 6to4 tunnelling stuff (based on researching a random sample of users), I'd lose about 4% of visitors to my web-sites if I were to turn on records. Has anyone who was using records for a site turned them off due to reachability problems? - Kevin
Re: Geographic map of IPv6 availability
Tony Hain wrote: Nathan Ward wrote: That's because the 'v6 network' is broken enough that putting records on sites that need to be well reachable is a bad idea. So why didn't you put up a 6to4 router and put records in that pointed to the 6to4 prefix for those servers? That would not help situations where a client has 6to4 enabled (and a non rfc1918 address) and is behind a firewall that doesn't support or filters proto 41. At least Teredo detects whether or not it will work before enabling the interface. In a perfect world people would fix the routing or filtering issue. In reality if it only affects a few sites the typical end user won't think it's their problem. - Kevin
Re: Repotting report
Leo Bicknell wrote: I have been using queries like these to test: dig any . @f.root-servers.net | egrep "(DiG 9|)" dig +bufsize=1400 any . @f.root-servers.net | egrep "(DiG 9|)" The first offers up a standard DNS query, the second an EDNS0 query of 1400 bytes. In a standard query you're only going to get 3 records, EDNS0 should allow for all of them. There are currently 6 servers with records: % dig any . @f.root-servers.net | egrep "(DiG 9|)" ; <<>> DiG 9.5.0b2 <<>> any . @f.root-servers.net A.ROOT-SERVERS.NET. 360 IN 2001:503:ba3e::2:30 F.ROOT-SERVERS.NET. 360 IN 2001:500:2f::f H.ROOT-SERVERS.NET. 360 IN 2001:500:1::803f:235 There is an interesting variation in what records are returned for a standard 512 byte request (dig ns . @[x].root-servers.net): A,C,D,E,F,G,I,J: return the same 10 A records and 4 records in the same order every time. They never return A records for K,L,M and never get records for K,M. B: returns all 13 A records in random order and then two records in random order. This allows all records to be returned with equal weight within each record type. H,K,L,M: return all 13 A records in static order and then A and F records so H,J,K,M records are never returned. Tested with dig 9.4.1-p1 on a v6 enabled system. - Kevin
Re: Is it time to abandon bogon prefix filters?
Jared Mauch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. - Kevin
Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
Randy Bush wrote: In practice, many routers require the packet to go twice in the hardware if the prefix length is > 64 bits, so even though it is a total waste of space, it is not stupid to use /64 for point-to-point links and even for loopbacks! some of us remember when we thought similarly for /24s for p2p links, especially when using rip. and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the prudent operational advice today is to use a /127. I thought there was an issue with duplicate address detection with /127 (RFC3627)? /126 should work and lots of folks use /112 which is a more human-friendly bit boundary. /112 is also good for multiple access vlans and just about anything that isn't using autoconfig. - Kevin
Re: Is it time to abandon bogon prefix filters?
Pekka Savola wrote: On Tue, 19 Aug 2008, Kevin Loch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. Strict uRPF (feasible paths variant, RFC3704) works just fine with multihomed customers here. But we don't allow TE more specifics either from the customer or from peers, so the longest prefix matching doesn't get messed up. And with certain kind of p2p link numbering, you may need to add a dummy static route. But it works. It doesn't look like the feasible paths rpf handles the situation where your bgp customer is not announcing all or any of their prefixes to you. This can be done for TE or debugging an inbound routing issue. Announcing prefixes to me and then blackholing the traffic is not something I would appreciate as a customer. If you do this (or strict rpf) on BGP customers at least warn them up front that if they ever stop announcing prefixes to you then traffic they send you will get dropped. - Kevin
Re: Cogent Outage?
Ketan Mangal wrote: Yes there is a Newyork to Philadelphia fiber cut is there It might not be an outage it might be high latency due to multiple routes going out via there buffalo POP. That fiber cut was at 9:30EST this morning, the major Cogent internal routing problems started around 12:10 and lasted about 30 mins. - Kevin
Re: How polluted is 1/8?
Mirjam Kuehne wrote: Hello, After 1/8 was allocated to APNIC last week, the RIPE NCC did some measurements to find out how "polluted" this block really is. See some surprising results on RIPE Labs: http://labs.ripe.net/content/pollution-18 Please also note the call for feedback at the bottom of the article. The most surprising thing in that report was that someone has an AMS-IX port at just 10 megs. It would be nice to see an actual measurement of the traffic and daily/weekly changes. A breakdown of the flow data by source ASN and source prefix (for the top 50-100 sources) would also be interesting. - Kevin
Re: Blocking private AS
Thomas Magill wrote: I am thinking about implementing a filter to block all traffic with private AS numbers in the path. I see quite a few in my table though so I am concerned I might block some legitimate traffic. In some cases, these are just prefixes with the private appended to the end but a few have the private as a transit. Is this a good idea or would I likely be blocking too much legitimate traffic? The filter I am using currently shows the following: I filter private asn's and have not had any reachability problems related to that. I suspect most of the routes you see with a private ASN in the path are covered by a less specific route without any private ASN in the path. Someone used a private ASN with their customer and forgot to filter it to their upstreams/peers. - Kevin
Re: Competition for Internap's FCP product.
Drew Weaver wrote: Hi, As my Avaya CNA/Route Science box begins to seriously age, and without the support of Avaya for 'Service Provider' uses of the product, I have been looking for alternatives to the product. The value we get from this product is mainly in the ability to easily manage our bandwidth commitments in a hands off way without having to manually manipulate anything. I have no real illusions that the 'performance' side of things is 'arguable' at best with these sorts of products due to the nature of the Internet. Internap to me stands out as essentially the only alternative to this product, but they have been tremendously difficult to work with, they won't allow us to demo a unit to see if it offers the same functionality as our current solution. The reason they won't allow us to a demo a unit is because they 'don't stock them'. So basically they have 0 units until someone orders one, that is fine if that is their policy but that hasn't really been our experience with other hardware vendors that want close to 100K for a piece of niche equipment. My questions are: -What are other people doing who currently use or used the Avaya/RS product in the past? -Does anyone know of any competition in this space (aside from hiring a guy that sits there and does this for us manually)? -Has Cisco's OER/PFR made any progress in the last few years (is anyone using it?) We use the Avaya CNA in one data center and it does an excellent job at both commit management and rerouting around problems. I almost never see tickets regarding latency/packet loss at that data center except when it involves inbound issues that the CNA can't fix. Other data centers have a more typical occurrence of routing issues that require manual intervention. Most of the parts to replace this exist in open source software today: bird/quagga for bgp to import routes and inject re-routes. net-snmp-utils for importing interface stats/state and bgp session state various performance testing tools [tcp]traceroute/mtr etc. netflow tools (like ehnt) to receive netflow data The parts that are missing: api for bird/quagga to import and assert routes code to use netflow to generate list of targets for performance testing and to determine bandwidth/route for commit management code to decide which routes to assert to which next-hop based on configured performance and commit levels. reporting None of that seems very tricky, especially the commit management which does not need a sophisticated performance evaluation, just "does it work at all via that link." - Kevin
Re: YouTube AS36561 began announcing 1.0.0.0/8
Axel Morawietz wrote: Am 12.03.2010 17:03, schrieb Nathan: [...] Its amazing how prolific 1.x traffic is. one reason might also be, that at least T-Mobile Germany uses 1.2.3.* for their proxies that deliver the content to mobile phones. And I'm not sure what they are doing when they are going to receive this route from external. ;) If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, perhaps it is time to update rfc1918 to reflect this? - Kevin
Re: .io registrar
Jeremy Kister wrote: Does anyone know of a competent .io registrar who charges in the <= $75/yr area ? I've been using tierra.net (domaindiscover.com) but they continually break my domains. this year, although their website says my domain expires 4/2012, my domain stopped working today. the .io servers aren't serving records, and nic.io says the domain expired 4/8/2011. i got a hold of them this morning got a ticket -- but after 4 hours still no response. also, although nic.io lists a bunch of .io registrars, when I called them they almost all say "we don't register .io" :D I have a .io domain with Moniker and have not had any problems. - Kevin
Broken Teredo relay AS1101?
This path for 2001::/32 leads to a broken teredo relay: 3257 1103 1101 http://ip6.me was using this path and not working from my client. When I routing to prefer 6939's relays it started working. - Kevin
Re: Cogent & HE
Richard A Steenbergen wrote: On Wed, Jun 08, 2011 at 06:39:02PM -0400, Patrick W. Gilmore wrote: Yes, both refuse to buy transit, yes. But HE is able, willing, and even begging to peer; Cogent is not. These are not "the same thing". I'm ready, willing, and lets say for the purposes of this discussion begging to peer with every Tier 1, but some of them aren't willing to peer with me. Does that mean I should stop buying transit and blame them for my resulting lack of global reachability? Do you have half the routing table as your customer base? - Kevin
Re: The stupidity of trying to "fix" DHCPv6
Leo Bicknell wrote: In a message written on Fri, Jun 10, 2011 at 05:13:09PM +0200, Iljitsch van Beijnum wrote: Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues: 1. No longer the fait sharing that comes from RA-learned gateway addresses I proport that VRRPv6 is a superior solution to have redundant gateways than using RA's to broadcast both and let the host choose. VRRP is definitely superior to RA's in that you can have many different redundant gateway groups for different purposes. Things like alternate default gateways, gateways to other back-end networks and VPN routers. In all but the most trivial hosting environments RA's will have to be disabled, filtered, and protected against at all cost. VRRPv3 (http://tools.ietf.org/html/rfc5798) is still a bit broken in that it makes mention of "MUST advertise RA's" and inexplicably limits VRRP addresses to link local only (?!)*. But at least we have something, it took years for the RA police at the IETF to allow even this limited solution. * In many cases it may be desirable to have VRRP addresses routed via IGP, especially static routes to VRRP next-hops. - Kevin
