It would seem that the routes that leaked into the routing system with an AS path: origin 3561 286 209... are mostly withdrawn and now under control. There may be a number of routes that persist and we feel that the best way to clear them out is to concentrate on them on a case-by-case basis. The (Cisco suggested) workaround to quickly remove these routes even though they have been withdrawn from BGP at their insertion point is to announce more specifics from the origin AS. Rather than burden the routing system with additional, unnecessary more specific routes from AS 3561, we would like to hear from other providers or from the owners of these routes. If you're seeing routes with the above AS path or if your network is currently routing through this path please contact us. You can send mail to trouble@cw.net to coordinate. If you choose to copy nanog that's ok. Now, that said. This particular problem has plagued the Internet, hitting us as a community a number of times this calendar year. On the nanog list we've discussed filtering, we've pointed out how particular providers are unaffected, but as yet we are all still vulnerable. The Cable & Wireless network filters routes from customers based on routing registry entries. We believe that this is the best defense against unintentional routing leaks, it protects us and our peers from our customers. We realize that not everyone in the industry agrees with us :-). We realize that many that agree with us would find it nearly impossible to implement such a system. I'd like to propose a simple solution to the class of route leak we've recently seen. I'd like to encourage our peers to put a simple filter in place. If you peer with AS 3561, please do not accept any route with AS 3561 in the path from either your customers or your other peers. We already do this for a number of networks, without commenting on the size or importance of any of them, they are just networks that we only expect to hear on specific peering links. I still believe that the way to a more stable routing system is through route registries and filtering. I don't believe that any of us can rest easy (whether or not our networks were affected by the current leak) until we fix the system. For my own selfish interests, please, filter on my AS number.
I'd like to propose a simple solution to the class of route leak we've recently seen. I'd like to encourage our peers to put a simple filter in place. If you peer with AS 3561, please do not accept any route with AS 3561 in the path from either your customers or your other peers.
I feel almost silly to point out a simple solution, an extension of the above, to the smart crowd here. But doesn't every one at the very least filter routes from peers/customers to reject ASes 701, 3561, 1, 1239 et al. (unless of course the peer is one of them). Minimizes the damage right away. Of course, not as tight as using routing registries. Has saved us a few times. Now that is a positive side to the industry with a handful few huge, transit-free, players. Just watch the mergers and acquisitions news to stay current :-) -- Regards, Sanjay. --------------------------------------------------------------- Web Professionals, Inc. Direct: +1 408-863-4850 20111 Stevens Creek Blvd, Suite 145 Biz/NOC: +1 408-863-4848 Cupertino CA 95014 USA http://serverhosting.net --------------------------------------------------------------- -=- Data Center Server Hosting Inside an Internet Exchange -=-
participants (2)
-
Jeffrey S. Young
-
Sanjay Dani