Quote:
Originally Posted by Broadbandings
Morning superkey, start of NMC shift? 
You might want to check regarding DTAG being a peer, they don't seem to know that they peer with VM looking at the communities that are set in the routes they hold for you guys, they list you as a transit customer.
Community: 3320:1826 3320:2010 3320:9010
3320:1826 Imported in Great Britain
3320:2010 Imported in Europe
3320:9010 Imported from a customer
As opposed to:
3320:9020 Imported from a peerr
Their mis-spelling not mine 
I checked on 5462 as well - same thing, no sign of a peering with DTAG and as far as DTAG are concerned has been moved behind 5089.
If VM have multiple peerings with OVH they're either down or were broken by the AS migration, which is far from impossible when noting some of VM's internal routing has been broken by the AS migration. Be quite impressive to break a peering to the extent where you prefer a longer AS path but still from what I've seen 5462's external connectivity has also been largely moved behind 5089 even where it's the better paths. |
I couldn't comment :-)
I think DT are probably that lowest of low type of peer - the paid private peer so technically VM are their customer but DT just advertise a partial table consisting of their own directly connected routes.
It may be a private peer policy 'thing' on the routing front which means DT advertised prefixes are being preferred over other sources of that same prefix, even where that source is another 'peer'
Best thing to do if the problem is still persisting would be for OVH to mail
nmc@virginmedia.co.uk saying they are a public peer on 5089 and that it looks like VM are preferring the OVH pre-fixes being advertised by the DTAG paid/private peering session. It would be costing VM money to see the OVH trafic by DTAG so I'm sure they would be keen to see that traffic via the 'free' public peer with OVH.