[9093] in North American Network Operators' Group
Re: set community no-export
daemon@ATHENA.MIT.EDU (Ryan Wiegner)
Mon May 5 00:15:56 1997
Date: Sun, 04 May 1997 23:06:21 -0500
To: nanog@merit.edu
From: Ryan Wiegner <rmw@iagnet.net>
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.