Wednesday, October 27, 2010

Cogent (AS174) does not have a full ipv6 table yet

As of date Cogent (AS174) still has not entered into a peering agreement with Hurricane Electric (AS6939), resulting in significantly less prefixes than most IPv6 transit providers will give you. I've compiled a list of prefixes that are missing in Cogent's table.

Most IPv6 transit providers will give you roughly 3500 prefixes, but Cogent only carries around 2500 prefixes.

If you want to be reachable from all over the world over IPv6, it's best to get a second and third IPv6 transit provider that give you a full IPv6 routing table. In other words, avoid having a Cogent-only network.

txt file: ipv6-prefixes-that-cogent-misses-as-of-27-Oct-2010.txt

Saturday, October 9, 2010

compilation of internet exchange memberlists

I'm compiling a list of internet exchange member lists. Please help expand the compilation by contributing urls to public CSV, TSV or files in other formats!

You can find it here: Internet Exchange memberlists

Wednesday, October 6, 2010

DTAG (AS3320) seems to not prefer customer routes by default

I noticed that DTAG's best path selection differs from most transit suppliers I know. Most transit providers will prefer routes received from their customers above routes they receive from peers. This type of policy ensures that traffic will flow over the most profitable links. It seems that DTAG on the other hand, by default, assigns a local preference value of 100 to every route they receive through eBGP.

It could mean that DTAG is actively turning down money by not filling up links that are sold on a 'per mbit' basis. Also, it could lead to confusion, which I'll try to explain with the following example:

You are AS65001, you buy transit from AS65555. You have a sister company (AS65002) with which you swap your full routing table. That sister company buys transit from DTAG (AS3320). DTAG and AS65555 peer with each other. AS65002 will announce the routes originated by AS65001 to DTAG.

DTAG now has to choose between two paths: a 'peering' path 65555_65001$ and a 'customer' path 65002_65001$. Both paths by default will have a local preference value of 100. So if for some reason the 'peering' path is chosen (because it's older, or the router-id of that peer is lower, or whatever) DTAG will not announce the AS65001 prefixes to its peers, because it has a 'better' path through peering. Obviously this can have impact on latency.

Fortunately, this behaviour is not set in stone. DTAG's local preference values can be influenced with communities or you can use prepending trickery.

Friday, October 1, 2010

Location / Separation Protocol Checklist

This list can be useful when assessing LISP, ILNP, RANGI, Ivip, hIPv4, NOL, CRM, LMS, GLI-Split, TIDR, EEMDP or IRON-RANGER. :-) Location / Identifier Separation Checklist:

Your post advocates a

( ) technical ( ) legislative ( ) market-based ( ) vigilante ( ) political

approach to reducing the growth of the internet routing table (e.g. the DFZ). Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws.)

( ) Requires immediate total cooperation from everybody at once
( ) There is no centralized authority that will force people to carry out your plan
( ) Requires every host to be upgraded to a newer version of their netstack
( ) Nobody wants to rewrite all applications to support your plan
( ) your mapping system consumes more memory then available on planet earth
( ) New complicated IP allocation policies must be set by the RIRs
( ) People won't give up their current allocations
( ) Your plan is incomplete or contains too much "needs to be further discussed." phrases
( ) No one can agree on the definition of an EID

Specifically, your plan fails to account for

( ) IPv4
( ) IPv6
( ) Layer-2 multi-pathing
( ) Vendor Lock-in
( ) Running code within the next 12 months
( ) Vendor bickering
( ) Jurisdictional problems
( ) Scalability
( ) Public reluctance to accept weird new forms of routing
( ) Huge existing investment in hardware, software or licences
( ) The trouble associated with changing gazillion hosts to understand your plan
( ) Willingness of users to renumber to new IP space
( ) No universal guaranteed MTU and the monster that PMTUD is
( ) Extreme profitability when abused
( ) Technically illiterate politicians
( ) The vendors have too many bugs
( ) Extreme stupidity on the part of people who do business over the Internet

and the following philosophical objections may also apply:

( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any proposal that requires all routers connected to the Internet to be upgraded on the same day is unacceptable
( ) Why should we have to trust you and your claim about the locations of nodes
( ) There is no money to be made
( ) Tunnels are evil but dynamic encapsulation is okay
( ) You suffer from the "Not Invented Here"-syndrome
( ) Must have a MIB designed first

Furthermore, this is what I think about you:

( ) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!