[9218] in North American Network Operators' Group
Re: set community no-export
daemon@ATHENA.MIT.EDU (Frye Kendall Lee)
Thu May 8 13:08:36 1997
Date: Thu, 8 May 1997 10:47:32 -0600 (MDT)
From: Frye Kendall Lee <fryek@rintintin.Colorado.EDU>
To: Ryan Wiegner <rmw@iagnet.net>
cc: nanog@merit.edu
In-Reply-To: <3.0.32.19970504230615.00722a04@iagnet.net>
I would like to know the classification of a backbone network? Or how
does the Internet community classify networks? Is it by some sort of
transit or access establishment with major providers or what? Is
identifing the _major_ backbones related to the _major_ transit carriers?
A more extensive list, as Ryan begins to propose below, would be helpful,
if there is a list.
Regards - Kendall
On Sun, 4 May 1997, Ryan Wiegner wrote:
> 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.
>