BGP confederations

From: neil moss (abzu79@dial.pipex.com)
Date: Sun Sep 17 2006 - 14:36:35 ART


Afternoon Team; my first post, failed my lab in May06 and revising again for
attempt 2 - I can't see this problem in the archives, so here I go:

Situation: I am revising confederations ("confeds"). I have 5 rtrs (A,B,C,2,1)
wired in that order connected b2b via serial or Eth VLANs. Each rtr is running
BGP, with each natively advertising a single /32 from a loopback into BGP using
"network X mask X". Goal: all rtrs to have all 5 /32s in the BGP table.

3 of the rtrs (B,C,2) are to present themselves externally as AS#70, however
only rtrs B+C may use a "confederation identifier X" statement. Rtr 2 peers
with the confeds and has "confederation peer 101 102", but cannot exist within a
sub-AS and must not use "confederation identifier X" - the goal of this lab is
to emulate a large AS where only part of the network uses confeds, or is
partially migrated to use confeds - Rtr 2 is the device we are trying to emulate
as not yet being migrated to a confed but is part of the overall AS#70.

'Rtr name' #AS [confed sub-AS]

Rtr 'A' #26 - Rtr 'B' #70 [101] - Rtr 'C' #70 [102] - Rtr '2' #70 - Rtr '1' #15

Rtr name - /32 prefix (loopback)
A - 21.21.21.21
B - 67.67.67.67
C - 87.87.87.87
2 - 34.34.34.34
1 - 19.19.19.19

Problem: all routers peer perfectly, no error msgs, etc. The problem is to do
with route propagation. All routes advertised by rtrs A+B+C are passed to all
rtrs, however routes originating on rtr 2 or 1, are not accepted by rtr C.

"debug ip bgp updates" on Rtr C (from routes received from Rtr 2 [the non-confed
router in AS70]) show:
 
Rtr_C_#
*Mar 1 05:47:30.906: BGP(0): 2.2.2.2 rcv UPDATE w/ attr: nexthop 2.2.2.2,
origin i, localpref 100, metric 76, originator 0.0.0.0, path 70, community ,
extended community
*Mar 1 05:47:30.906: BGP(0): 2.2.2.2 rcv UPDATE about 34.34.34.34/32 -- DENIED
due to: AS-PATH contains our own AS;

*Mar 1 05:47:30.906: BGP(0): 2.2.2.2 rcv UPDATE w/ attr: nexthop 2.2.2.2,
origin i, localpref 100, metric 76, originator 0.0.0.0, path 70 15, community ,
extended community
*Mar 1 05:47:30.910: BGP(0): 2.2.2.2 rcv UPDATE about 19.19.19.19/32 -- DENIED
due to: AS-PATH contains our own AS;
Rtr_C_#

I understand why this is happening - AS loop prevention on rtr C analysing the
AS path on routes passed from rtr 2, and seeing its own AS, rejects the route.
I can't believe this situation hasn't existed in the real world, so was
wondering if there is something I am overlooking to make this work.

Any help would be greatly appreciated - thanks for your support,

best regards,

Neil Moss
www.smogey.net

Partial configs for completeness:

Rtr A
router bgp 26
 network 21.21.21.21 mask 255.255.255.255
 neighbor 9.0.0.1 remote-as 70

Rtr B
router bgp 101
 bgp confederation identifier 70
 bgp confederation peers 70 102
 network 67.67.67.67 mask 255.255.255.255
 neighbor 9.0.0.2 remote-as 26
 neighbor 9.0.0.10 remote-as 102

Rtr C
router bgp 102
 bgp confederation identifier 70
 bgp confederation peers 70 101
 network 87.87.87.87 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 70
 neighbor 9.0.0.9 remote-as 101

Rtr 2
router bgp 70
 bgp confederation peers 101 102
 network 34.34.34.34 mask 255.255.255.255
 neighbor 2.2.2.1 remote-as 102
 neighbor 3.0.0.1 remote-as 15

Rtr 1
router bgp 15
 network 19.19.19.19 mask 255.255.255.255
 neighbor 3.0.0.2 remote-as 70



This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:40 ART