From: Jung-I Lin (easyman.lin@gmail.com)
Date: Mon Sep 18 2006 - 10:45:51 ART
Hi,
I'm not sure if this worked.
Could you tell me the result after trying?
allowas-in Accept as-path with my AS present in it
Rack10R1(config-router)# neighbor 1.1.1.1 allowas-in ?
<1-10> Number of occurances of AS number
<cr>
HTH.
On 9/18/06, 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Thanks Best Regards,Jung-I Lin
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:40 ART