[AusNOG] Issue getting routes from Telstra to 49.156.16.0/22

[Shaun Dwyer]

+1

After the last Telstra/Dodo colossal screwup, I can't believe neither of them have put filters in place. No arses kicked hard enough perhaps?

All it would take is for ONE of them to filter appropriately and the problem would be solved permanently.

I've always written filters on the assumption that:
1: you can't trust your peers/upstreams to not make mistakes
2: you can trust yourself (or others making changes to your network) to not make mistakes.

Cheers!
-Shaun


On 02/05/2012, at 8:11 AM, Sean K. Finn wrote:

> It sounds like they are blocking a host on your network, by dropping a null route into their routing table for something as little as a /32
>  
> That null route is then leaking into BGP, and being aggregated, as they are seeing your /22 from somewhere else, they are then re-announcing this.
>  
> DODO likely DO have route-filters setup. (But Telstra, why have you not learnt ?)
>  
> What I suggest is happening is that DODO Trust their own local routing tables (i.e. router to router subnets), and anything that they are originating locally (Like a null route) is then considered trusted, and allowed through BGP.
>  
> DODO, instead of trusting your local originating routing table, you should create a manual list of what you consider ‘LOCAL’ or originating prefixes from the inside of your network itself (i.e. not learnt routes), and then filter your local routing table against this list, too,  before advertising your BGP Null routes.
>  
> S.
>  
> PS.
> A question for any peering guru’s on this list, are ALL of the major Aussie IX’s performing route-filtering on the route reflectors to guard against routes like this leaking into the IX?
> (i.e. PIPE, EQUINIX, and WAIA’s various peering IX’s?)
> 
> 
> From: ausnog-bounces at lists.ausnog.net [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Sheng Yeo
> Sent: Wednesday, May 02, 2012 10:04 AM
> To: Craig Askings
> Cc: ausnog at lists.ausnog.net
> Subject: Re: [AusNOG] Issue getting routes from Telstra to 49.156.16.0/22
>  
> Thanks for all the replies everyone. We advertise everything as /24 subnets as well. 
>  
> Also, just as a quick note, we are not a customer of either Dodo or Telstra directly so we have no SLA with either of them. 
>  
> We advertise to Vocus, Equinix and AAPT who then advertise upstream to Telstra. This made it even more difficult to find the right person to speak to as we kept hitting walls as we were not customers of theirs. 
>  
> Thanks again for all the help. I will give them a call to discuss why this occurred (as I am still waiting for a reply). 
> 
> Cheers,
>  
> Sheng Yeo
> Managing Director
> OrionVM Cloud Platform
>  
> Mobile: +61 402 098 008
> Phone: +61 2 8004 6408
> Email: sheng.yeo at orionvm.com.au
> Web: www.orionvm.com.au
>  
> This e-mail message and any attachments contain information that is confidential and may be subject to legal privilege.If you are not the intended recipient, you must not peruse, use, pass on or copy this message or any attachments. If you have received this e-mail in error, please notify us by return e-mail and erase all copies of this message including any attachments.
> 
> 
> 
> On 2 May 2012 10:00, Craig Askings <craig at askings.com.au> wrote:
> On 2/05/2012 9:53 AM, Paul Wilkins wrote:
> You'd expect that after recent events, that Dodo would have had a complete review of their BGP done by a third party expert. Seems strange this hasn't happened.
> 
> Paul Wilkins
>  
> I doubt dodo have many if any clients on a SLA, what would their financial incentive to fix this?
> 
> Craig.
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>  
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20120502/e3ddb8f6/attachment.html>