Re: BGP Session Flapping with dual AS

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
Blogs and organic groups at http://www.ccie.net