Go CCIE Go!! - A Cisco Certified Internetwork Expert

Neil,
I think the key here may be the statement
“3 of the rtrs (B,C,2) are to present themselves externally as AS#70″
So, you can trick router C in to thinking router 2 is in a different AS using the “neighbor local-as” command on Router 2 toward router C. You may need the “no-prepend” and/or the “replace-as” options so that AS70 won’t appear in the AS path. Just experiment with that.
I haven’t tested this, but I suspect this is the trick for solving it.
–Brent
— neil moss wrote:
> 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 > >