Re: BGP Session Flapping with dual AS

Jorge,

Yeah, sounds like you got it. This was an interesting scenario :)

On Fri, Dec 18, 2009 at 11:09 AM, Jorge Cortes
<jorge.cortes.cano_at_gmail.com>wrote:

> Hi Bryan,
>
> I tried this today again and "no bgp enforce-first-as" on R5 did the
> trick and stopped the flapping. After reviewing the routes R5 is
> learning from R4 it looks like you are correct, R5 is receiving those
> routes with AS 100 in leftmost position instead of 146, and 146 is not
> shown anywhere in the ASPATH, while the output of sh ip bgp sum on R5
> shows R4 being in AS 146. This leads me to think that that when
> issuing command "replace-as" it will ALWAYS replace the real AS with
> the local AS in the ASPATH, because if the peering on R5 to R4 is done
> using remote-as 100 the problem is not showing. So it looks like
> option "dual-as" only works for the OPEN message sent, but not for the
> UPDATE messages.
>
> Thanks a lot for your help!!!
>
> This was quite an interesting exercise.
>
> Regards,
>
> Jorge
>
>
> On Thu, Dec 17, 2009 at 9:54 PM, Bryan Bartik <bbartik_at_ipexpert.com>
> wrote:
> > What the solution says about AS hiding is correct, but there are several
> > possible scenarios and that statement serves as a general explanation. It
> > looks like R4 sends updates to R5 with leftmost AS 146. R5 is expecting
> 100.
> > R5 sends a notification and the session is torn.
> >
> > Perhaps the lab writer never saw the behavior, for some reason.
> >
> > On Thu, Dec 17, 2009 at 8:18 PM, Jorge Cortes <
> jorge.cortes.cano_at_gmail.com>
> > wrote:
> >>
> >> Thanks Bryan.
> >>
> >> I'm still quite confused though. According to the solution for this
> >> activity it says the following:
> >>
> >> "It is possible to configure the "hiding" peer (in this case 45.4) to
> >> initiate/accept BGP sessions using both AS numbers (the real number
> >> -146- and the local number -100-). The external peer will accept the
> >> correct number -146- and negotiate the BGP session. The "hiding peer
> >> will then use the negotiated AS number -it should then be 146- to
> >> prepend the updates sent to the external peer"
> >>
> >> So according to it neighbor .45.4 should be sending the updates with
> >> AS146 on the leftmost position of the AS PATH to neighbor 45.5, and
> >> .45.5 should be expecting this, since it is peering to neighbor .45.4
> >> remote-as 146, so the update check should pass.
> >>
> >> However your explanation makes a lot of sense and it could be that
> >> neighbor .45.4 is replacing AS146 with AS100 and sending the updates
> >> with AS100 in the leftmost position, thus failing the update check and
> >> tearing down the session. It shouldn't be the correct behavior
> >> according to the solution I think.
> >>
> >> Regards,
> >>
> >> Jorge
> >>
> >> On Thu, Dec 17, 2009 at 8:37 PM, Bryan Bartik <bbartik_at_ipexpert.com>
> >> wrote:
> >> > I just read my mail again, meant to say R2 is in AS20, so path looks
> >> > like 20
> >> > 30. Use "no bgp enforce-first-as" on the routers that peer with AS100
> >> > (actual AS 20) to allow these routes.
> >> >
> >> > -hth
> >> >
> >> > On Thu, Dec 17, 2009 at 7:22 PM, Bryan Bartik <bbartik_at_ipexpert.com>
> >> > wrote:
> >> >>
> >> >> Jorge,
> >> >>
> >> >> When you do no-prepend, you can pass routes to your neighbor that
> might
> >> >> not have your "local-as" first and so another peer may drop this and
> >> >> kill
> >> >> the session. Example:
> >> >>
> >> >> R1---R2---R3
> >> >>
> >> >> R1 (AS10) and R3 (AS30) both treat R2 as in AS100.
> >> >> R2 is AS200.
> >> >>
> >> >> If R2 uses the no-prepend option, routes from R3 look like this to
> R1:
> >> >>
> >> >> route: 10.1.1.3
> >> >> as-path: 20 30
> >> >>
> >> >> R1, by default, expects all routes from R2 to have 100 as the first
> AS
> >> >> in
> >> >> the path. You can use "no bgp enforce-first-as" to allow this.
> >> >>
> >> >> You can read more details in RFC 4271:
> >> >>
> >> >> 6.3. UPDATE Message Error Handling
> >> >>
> >> >> "the local system MAY check whether the leftmost (with respect to the
> >> >> position
> >> >> of octets in the protocol message) AS in the AS_PATH attribute is
> >> >> equal to the autonomous system number of the peer that sent the
> >> >> message. If the check determines this is not the case, the Error
> >> >> Subcode MUST be set to Malformed AS_PATH."
> >> >>
> >> >> It might be worth noting that if you want dual-as and replace-as, you
> >> >> must
> >> >> use no-prepend. Looks like you can have a lot of fun with this
> command.
> >> >> Interesting scenario :)
> >> >>
> >> >> On Thu, Dec 17, 2009 at 6:44 PM, gokul krishna <gokulbruno_at_gmail.com
> >
> >> >> wrote:
> >> >>>
> >> >>> Hi Jorge,
> >> >>>
> >> >>> Did you check the IGP routing table to reach the neighbour? Is it
> >> >>> steady?
> >> >>> Is
> >> >>> the BGP route flapping every 30 sec?
> >> >>>
> >> >>> Kris
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Thu, Dec 17, 2009 at 1:39 PM, Jorge Cortes
> >> >>> <jorge.cortes.cano_at_gmail.com>wrote:
> >> >>>
> >> >>> > Hi Team,
> >> >>> >
> >> >>> > Working on the lab for BGP Dual AS I am running into a problem
> where
> >> >>> > the BGP session between the eBGP peers is constantly flapping and
> I
> >> >>> > just can't understand where the problem could be. Following the
> >> >>> > relevant configurations on both peers:
> >> >>> >
> >> >>> >
> >> >>> > ======Peer 155.1.45.4=======
> >> >>> >
> >> >>> > router bgp 146
> >> >>> > no synchronization
> >> >>> > bgp log-neighbor-changes
> >> >>> > network 155.1.146.0 mask 255.255.255.0
> >> >>> > aggregate-address 155.1.0.0 255.255.0.0 summary-only
> >> >>> > neighbor 155.1.45.5 remote-as 200
> >> >>> > neighbor 155.1.45.5 local-as 100 no-prepend replace-as dual-as
> >> >>> > neighbor 155.1.45.5 remove-private-as
> >> >>> > neighbor 155.1.146.1 remote-as 146
> >> >>> > neighbor 204.12.1.254 remote-as 54
> >> >>> > neighbor 204.12.1.254 local-as 100 no-prepend replace-as
> >> >>> > neighbor 204.12.1.254 remove-private-as
> >> >>> > no auto-summary
> >> >>> >
> >> >>> >
> >> >>> > ======Peer 155.1.45.5=========
> >> >>> >
> >> >>> > router bgp 200
> >> >>> > no synchronization
> >> >>> > bgp log-neighbor-changes
> >> >>> > bgp dampening 4
> >> >>> > neighbor 155.1.0.2 remote-as 200
> >> >>> > neighbor 155.1.0.2 route-reflector-client
> >> >>> > neighbor 155.1.23.3 remote-as 200
> >> >>> > neighbor 155.1.45.4 remote-as 146
> >> >>> > neighbor 155.1.45.4 remove-private-as
> >> >>> > neighbor 155.1.58.8 remote-as 200
> >> >>> > neighbor 155.1.58.8 route-reflector-client
> >> >>> > neighbor 155.1.108.10 remote-as 200
> >> >>> > neighbor 155.1.108.10 route-reflector-client
> >> >>> > no auto-summary
> >> >>> >
> >> >>> >
> >> >>> > Here the log messages and the debug TCP on peer 45.5
> >> >>> >
> >> >>> > Rack1R5#
> >> >>> > *Dec 17 19:03:23.330: tcp0: O SYNRCVD 155.1.45.4:11528
> >> >>> > 155.1.45.5:179
> >> >>> > seq 1925862638
> >> >>> > OPTS 4 ACK 2264873293 SYN WIN 16384
> >> >>> > *Dec 17 19:03:23.358: tcp0: O ESTAB 155.1.45.4:11528
> 155.1.45.5:179
> >> >>> > seq 1925862639
> >> >>> > DATA 64 ACK 2264873338 PSH WIN 16339
> >> >>> > *Dec 17 19:03:23.386: %BGP-5-ADJCHANGE: neighbor 155.1.45.4 Up
> >> >>> > *Dec 17 19:03:23.386: tcp0: O ESTAB 155.1.45.4:11528
> 155.1.45.5:179
> >> >>> > seq 1925862703
> >> >>> > DATA 366 ACK 2264873357 PSH WIN 16320
> >> >>> > *Dec 17 19:03:23.450: tcp0: O ESTAB 155.1.45.4:11528
> 155.1.45.5:179
> >> >>> > seq 1925863069
> >> >>> > DATA 54 ACK 2264873771 PSH WIN 15906
> >> >>> > *Dec 17 19:03:23.470: tcp0: O ESTAB 155.1.45.4:11528
> 155.1.45.5:179
> >> >>> > seq 1925863123
> >> >>> > DATA 38 ACK 2264873877 PSH WIN 15800
> >> >>> > *Dec 17 19:03:23.690: tcp0: O ESTAB 155.1.45.4:11528
> 155.1.45.5:179
> >> >>> > seq 1925863161
> >> >>> > ACK 2264874151 WIN 15526
> >> >>> > Rack1R5#
> >> >>> > *Dec 17 19:03:54.082: %BGP-5-ADJCHANGE: neighbor 155.1.45.4 Down
> BGP
> >> >>> > Notification sent
> >> >>> > *Dec 17 19:03:54.082: %BGP-3-NOTIFICATION: sent to neighbor
> >> >>> > 155.1.45.4
> >> >>> > 3/11 (invalid or corrupt AS path) 13 bytes 40020A02 04006400
> >> >>> > 36003200
> >> >>> > 3C
> >> >>> > Rack1R5#
> >> >>> > *Dec 17 19:03:54.082: BGP: 155.1.45.4 Bad attributes FFFF FFFF
> FFFF
> >> >>> > FFFF FFFF FFFF FFFF FFFF 0033 0200 0000 1840 0101 0040 020A 0204
> >> >>> > 0064
> >> >>> > 0036 0032 003C 4003 049B 012D 0408 7108 70
> >> >>> > *Dec 17 19:03:54.082: tcp0: O ESTAB 155.1.45.4:11528
> 155.1.45.5:179
> >> >>> > seq 1925863161
> >> >>> > DATA 34 ACK 2264874351 PSH WIN 15326
> >> >>> > *Dec 17 19:03:54.102: tcp0: O CLOSEWAIT 155.1.45.4:11528
> >> >>> > 155.1.45.5:179 seq 1925863195
> >> >>> > ACK 2264874352 WIN 15326
> >> >>> > *Dec 17 19:03:54.182: tcp0: O LASTACK 155.1.45.4:11528
> >> >>> > 155.1.45.5:179
> >> >>> > seq 1925863195
> >> >>> > ACK 2264874352 FIN PSH WIN 15326
> >> >>> >
> >> >>> > I would appreciate if someone could provide any pointers on what I
> >> >>> > could be missing here.
> >> >>> >
> >> >>> > Thanks and regards,
> >> >>> >
> >> >>> > Jorge
> >> >>> >
> >> >>> >
> >> >>> > Blogs and organic groups at http://www.ccie.net
> >> >>> >
> >> >>> >
> >> >>> >
> _______________________________________________________________________
> >> >>> > Subscription information may be found at:
> >> >>> > http://www.groupstudy.com/list/CCIELab.html
> >> >>>
> >> >>>
> >> >>> Blogs and organic groups at http://www.ccie.net
> >> >>>
> >> >>>
> >> >>>
> _______________________________________________________________________
> >> >>> Subscription information may be found at:
> >> >>> http://www.groupstudy.com/list/CCIELab.html
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Bryan Bartik
> >> >> CCIE #23707 (R&S, SP), CCNP
> >> >> Sr. Support Engineer - IPexpert, Inc.
> >> >> URL: http://www.IPexpert.com
> >> >
> >> >
> >> >
> >> > --
> >> > Bryan Bartik
> >> > CCIE #23707 (R&S, SP), CCNP
> >> > Sr. Support Engineer - IPexpert, Inc.
> >> > URL: http://www.IPexpert.com
> >> >
> >
> >
> >
> > --
> > Bryan Bartik
> > CCIE #23707 (R&S, SP), CCNP
> > Sr. Support Engineer - IPexpert, Inc.
> > URL: http://www.IPexpert.com
> >
>

-- 
Bryan Bartik
CCIE #23707 (R&S, SP), CCNP
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com
Blogs and organic groups at http://www.ccie.net