IAGnet has a number of connections to the major backbones: Sprint, UUNET, MCI, ANS, etc. Many of our transit connections including those to Sprint and UUNET are configured for a sort of "peer" policy. We have found that a combination of as-path prepending (I can hear the groans now), static configuration, and communities it is possible to have traffic from a certain backbone (multi & single homed customers or just single homed customers) return on the appropriate connection. Of course no routing policy is prefect but I think we are fairly close. If anyone is interested in our technical specifics as opposed to the administrative possibility as it relates to UUNET's & Sprint's announcement, feel free to drop us a email off the list. We are always happy to exchange ideas. MW At 10:19 PM 5/4/97 -0500, you wrote:
No that doesn't work very well, unless you make the rash assumption that all of Sprint's customers are in the same Autonomous System. We saw all sorts of goofy problems when I*STAR did this with MCI. The problems went away when the customer switched from I*STAR to UUNET/Canada :-)
You need a community that will be announced to "customer" BGP sessions, but not to "peer" BGP sessions. Its not hard to do, but it does seem to be hard to explain to your standard order taker/sales staff.
It also seems to confuse the heck out of the support folks when they need to troubleshoot things. It would really be nice if cisco's had a "show ip bgp neigh xxx out" command that showed what you are telling your neighbor. Essentially the inverse of the "show ip bgp neigh xxx route" command.
Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
Ryan Matthew Wiegner Internet Access Group, Cleveland Ohio.