Re: BGP confederations

From: Brent Foster (jbrentfoster@yahoo.com)
Date: Sun Sep 17 2006 - 20:31:11 ART


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 <abzu79@dial.pipex.com> 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
>
>



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