[6bone] peering

[John Fraizer]

On Thu, 8 Aug 2002, Michel Py wrote:

> About the config itself:
> 
> >> - There is overlap in the following two lines:
> >> neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in neighbor 
> >> 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY in The prefix-list is
> useless 
> >> as the route-map uses it IMHO.
>  
> > Michel, actually, if you look at our config for your peering
> > session, the prefix-list actually does do something.  Since I
> > use a "canned" route-map for all peers, I have to use the
> > neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in on your
> > peering session.
> 
> Now I understand why you do it this way. I'm curious about one thing,
> though. Can't you use a peer-group for transit? You could probably have
> a common route-map for transit (just match the STRICT) and reserve the
> canned route-map with people that require special handling.
> 
> Michel.

Well, yes.  I could use a peer-group and use the route-map [blah] in
statement as part of the peer-group.  I choose to use a seperate route-map
for each peer so we can do traffic engineering.  Some peers are weighted
differently than others.  I'll also pref some as-paths (up/downstream of a
peer) differently.  For example, you can reach C via both A and B but, the
actual goodput is much better via B.  I use the peer specific route-maps
to pref B_C over(or under as the case may be - I generally depref bad
routes vs adding to the localpref value of good ones) A_C.  Do you see the
reasoning behind the individual route-maps?

I know it's a pain in the behind in some ways to do things like this.  I
have learned though:

Right Way
Easy Way
Best way for the long run

Pick any two...

---
John Fraizer              | High-Security Datacenter Services |
EnterZone, Inc            | Dedicated circuits 64k - 155M OC3 |
http://www.enterzone.net/ | Virtual, Dedicated, Colocation    |