North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BGP Confederation config problem...

  • From: Richard Parker
  • Date: Tue Mar 10 22:27:19 1998

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

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.