AT&T routing issue
Hi all, We have recently brought up some BGP sessions with a new provider, and have found that we can get end to end connectivity through the new provider to pretty much everywhere except networks behind AT&T (AS7018). We are able to see our routes in AT&T's route server, but all traceroutes from our network to hosts behind 7018 stop at AT&T's border. We are multihomed, so I've local-prefed up our secondary ISP and the problem resolves immediately. Our upstream (AS9443) and their upstream (AS11867) have been chasing this up with AT&T for a couple of days, but don't seem to have had made much progress. Does anyone have any suggestions as to what could be causing this, or a contact at AT&T who might be able to assist? Thanks, Alex
On Tue, Nov 4, 2008 at 6:20 PM, Campbell, Alex <Alex.Campbell@ogilvy.com.au> wrote:
Hi all,
We have recently brought up some BGP sessions with a new provider, and have found that we can get end to end connectivity through the new provider to pretty much everywhere except networks behind AT&T (AS7018).
We are able to see our routes in AT&T's route server, but all traceroutes from our network to hosts behind 7018 stop at AT&T's border. We are multihomed, so I've local-prefed up our secondary ISP and the problem resolves immediately.
Our upstream (AS9443) and their upstream (AS11867) have been chasing this up with AT&T for a couple of days, but don't seem to have had made much progress.
In short yes. AT&T uses a customer specific access list to perform a uRPF like function. That is, if your provider did not request for their provider to have AT&T update their filter.
Does anyone have any suggestions as to what could be causing this, or a contact at AT&T who might be able to assist?
Since you are experiencing this issue only when you send your traffic out (eventually though AT&T) it points to the inbound ACL on AT&T's border. I have been bitten by this too many times, especially when customers, or customers of customers don't properly inform the other of the new netblock. I would be curious to find out if the issue you are facing is specific with every network you are announcing or just one or two networks. As for who would assist, this request is suppose to go through: AT&T MIS Maintenance 888-613-6330 Prompt-3, 2 rm-awmis@ems.att.com charles
:In short yes. AT&T uses a customer specific access list to perform a :uRPF like function. That is, if your provider did not request for :their provider to have AT&T update their filter. Indeed. We've used ATT MIS for many years and have been happy with their policies (which have blunted quite a few DDOS attacks), and their response to acl mod requests. They do tend to take longer than I'd like (on the order of several business days) for standard requests, though if you request expedition, response time is impressive. Overall, thumbs up. :AT&T MIS Maintenance :888-613-6330 Prompt-3, 2 :rm-awmis@ems.att.com Yep. Always quite responsive. As with any other vendor, if you feel the person handling the call isn't qualified, escalate.
Many thanks to all those who replied. It did turn out to be a filter that needed updating at 7018, which was very quickly fixed by their team. -----Original Message----- From: Brian Wallingford [mailto:brian@meganet.net] Sent: Wednesday, 5 November 2008 2:06 PM To: Charles Gucker Cc: Campbell, Alex; nanog@nanog.org Subject: Re: AT&T routing issue :In short yes. AT&T uses a customer specific access list to perform a :uRPF like function. That is, if your provider did not request for :their provider to have AT&T update their filter. Indeed. We've used ATT MIS for many years and have been happy with their policies (which have blunted quite a few DDOS attacks), and their response to acl mod requests. They do tend to take longer than I'd like (on the order of several business days) for standard requests, though if you request expedition, response time is impressive. Overall, thumbs up. :AT&T MIS Maintenance :888-613-6330 Prompt-3, 2 :rm-awmis@ems.att.com Yep. Always quite responsive. As with any other vendor, if you feel the person handling the call isn't qualified, escalate.
participants (3)
-
Brian Wallingford -
Campbell, Alex -
Charles Gucker