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.

No comments: