<snip> Site BGP Advertisement to ISP Amsterdam 169.61.201.0/24 AMSISP Austin 169.61.111.0/24 Genuity & Internap SanFran 169.61.119.0/24 Genuity & Internap Tokyo 169.61.202.0/24 TOKISP Sydney 169.61.156.0/24 SYDISP

1. Since Verio says they would not accept /24 nets drawn from Class B space, I assume this means that they don't insert a /16 into their tables so that the /24 nets appear to Verio customers as unreachable. In this case, a design that wants to extend connectivity to verio customers (and any other ISP with similar policies) must include a /16 advertisement from at least one of the sites.

2. Suppose a customer of a Verio-like ISP, wishes to go to ftp. foo.org. DNS returns 169.61.201.155 (in amsterdam, see above). Verio passes the traffic to the neighbor it received the /16 advertisement from. At this point, the best thing that could happen is if that neighbor has the /16 and /24 networks in its route table, right? That means, a path exists for that user to the amsterdam server and the only problem with routing to Amsterdam is that Verio possibly handed the traffic to a sub-optimal neighbor. Am I understanding this issue correctly?

Yes the logic seems clean , also another situation which might happen is that Verio peers with ISP x and ISP x doesnt have a specific /24 route they will follow a static to somewhere. You want to be careful that the somewhere knows about the /24. This could easily happen if Verio peers with the ISP that is nearer and an ISP that also peers with this ISP. So verio might decide hey the "longer" path is better and the packet gets into the "longer" ISP and it wont have a /24 so it will follow the /16. Maybe if you could tell use who owns the addresses and how big the original block is ? A whois points to a swiss bank is this correct ?

I'm new to BGP. I've tried to get a handle on this issue on my own and by working with Genuity, Internap and Cisco. No disrespect to those companies but each of them had this vague memory of Verio's policy but couldnt really tell me in plain language how it might affect the above scenario. Obviously, I wasn't talking to chief engineers. Someone from the CCIE mailing list suggested I browse the archives of this list, which I did. But I didnt find a clear enough answer to my questions--perhaps because they are too basic to be discussed here or I'm not good at using this lists archive search engine. Either way, any guidance on the above scenario is greatly appreciated.

-BM

*********************************IMPORTANT NOTICE****************************** All e-mails for technical support must be cc'd to support@lancomms.ie. This ensures that the call is logged with the support desk and the case is actively tracked which speeds up the response you will receive. If you have an urgent problem you _must_ contact the support desk directly on 01-4093030. *****************************************************************************************