Andy McConnell wrote:

:-) I tried this already, but the match metric only works with IGRP route-maps, not BGP :-)

Sigh... I'll try again. Given my understanding of the limitations and/or design considerations in Cisco's implementation of BGP confederations that prohibit your configuration from working as discussed so far... a) in a confederation the neighbor sub-ASes aren't considered part of the AS_path, b) the MED can't have it's value adjusted relatively, c) "match metric" doesn't work with BGP route-maps, and d) the MED from neighboring sub-ASes is ignored anyway, ... then, perhaps a solution to the problem is to use two route-maps. One route-map to "increment" the community on updates that are sent within the confederation and another to set the local preference and MED based on the community. The community attribute is used because it can be matched against, the local preference attribute is used because it is considered in the decision process when Cisco's BGP implementation routes inside a confederation, and the MED attribute is used so that the external neighbors of the confederation members choose to send data into the confederation at the point closest to the ultimate destination. This configuration might look something like the following: neighbor a.b.c.d send-community neighbor a.b.c.d route-map INC-COMMUNITY out neighbor a.b.c.d route-map SET-PREF-MED in ! route-map INC-COMMUNITY permit 1 match community-list 1 set community 2 route-map INC-COMMUNITY permit 2 match community-list 2 set community 3 ... route-map INC-COMMUNITY permit <n> match community-list <n> set community <n+1> route-map INC-COMMUNITY permit <n+1> match community-list <n+1> set community 1 ! route-map SET-PREF-MED permit 1 match community-list 1 set metric 1 set local-preference 99 route-map SET-PREF-MED permit 2 match community-list 2 set metric 2 set local-preference 98 ... route-map SET-PREF-MED permit <n> match community-list <n> set metric <n> set local-preference <100-n> route-map SET-PREF-MED permit <n+1> match community-list <n+1> ! ip community-list 1 permit 1 ip community-list 2 permit 2 ... ip community-list <n> permit <n> ip community-list <n+1> permit internet You will note the the INC-COMMUNITY route-map matches a range of community values, and "increments" the community. The final condition sets the community to 1 for routes that are newly introduced into the confederation. The SET-PREF-MED route-map matches the same range of community values and sets the MED and local preference accordingly. The final condition permits all other routes and leaves the attributes unchanged. Also, while you would want to apply both the INC-COMMUNITY output route-map and the SET-PREF-MED input filter to the neighbors in other sub-ASes, for internal neighbors you would only want to apply the SET-PREF-MED input route-map. You would apply neither filter to neighbors in ASes outside of the confederation. To be honest, even if this configuration works, it might well be more trouble than it is worth. -Richard