From: Shahid Ansari (shahid1357@gmail.com)
Date: Fri Oct 24 2008 - 20:37:27 ARST
I did small lab setup just have a look on that
R1#sh runn | b r b
router bgp 100
no synchronization
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 1.1.1.2 remote-as 200
no auto-summary
(Suppose we dont have control on BB1)
BB1#runn | b r b
router bgp 200
no synchronization
bgp router-id 1.1.1.2
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
no auto-summary
R1#sh ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
1.1.1.2 4 200 42 43 1 0 0 00:01:12 0
BB2#sh ip bgp summary
BGP router identifier 1.1.1.2, local AS number 200
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
1.1.1.1 4 100 4 4 1 0 0 00:00:53 0
Error is appearing where you configured Wrong AS on R1
R1(config)#router bgp 100
R1(config-router)#nei
R1(config-router)#neighbor 1.1.1.2 remo
R1(config-router)#neighbor 1.1.1.2 remot
R1(config-router)#no neighbor 1.1.1.2 remote-as 200
R1(config-router)#no neighbor 1.1.1.2 remote-as 200
*Mar 1 00:25:31.631: %BGP-5-ADJCHANGE: neighbor 1.1.1.2 Down Neighbor
deleted
R1(config-router)# *neighbor 1.1.1.2 remote-as 600 (as I dont know and I
mistyped it)*
R1(config-router)#
*Mar 1 00:26:01.875: %BGP-3-NOTIFICATION: sent to neighbor 1.1.1.2 2/2
(peer in
wrong AS) 2 bytes *00C8 *FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104
00C8 0
0B4 0101 0102 1002 0601 0400 0100 0102 0280 0002 0202 00
*Mar 1 00:26:29.543: %BGP-3-NOTIFICATION: sent to neighbor 1.1.1.2 2/2
(peer in
wrong AS) 2 bytes 00C8 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104
00C8 0
0B4 0101 0102 1002 0601 0400 0100 0102 0280 0002 0202 00
*00C8 is BB1`s AS = 200 and showing on R1*
BB1#(Dont have control )
*Mar 1 00:26:01.455: %BGP-3-NOTIFICATION: received from neighbor 1.1.1.12/2 (p
eer in wrong AS) 2 bytes 00C8
*Mar 1 00:26:29.115: %BGP-3-NOTIFICATION: received from neighbor 1.1.1.12/2 (p
eer in wrong AS) 2 bytes 00C8
now what you think ?
On Sat, Oct 25, 2008 at 12:30 AM, Scott M Vermillion <
scott_ccie_list@it-ag.com> wrote:
> Just as a final follow-up, I wanted to post some trace file snippets (yes,
> I started to doubt myself and just had to fire up the protocol analyzer to
> be 100% certain of everything). The situation is as follows:
>
>
> R1 F1/0 - 192.168.0.0/24 - F1/0 R2
>
>
> R1#sh run | sec bgp
> router bgp 100
> no synchronization
> bgp log-neighbor-changes
> neighbor 192.168.0.2 remote-as 200
> no auto-summary
> R1#
> *Mar 1 04:40:19.846: %BGP-3-NOTIFICATION: sent to neighbor 192.168.0.22/2 (peer in wrong AS) 2 bytes 0014
>
> R2#sh run | sec bgp
> router bgp 20
> no synchronization
> bgp log-neighbor-changes
> neighbor 192.168.0.1 remote-as 100
> no auto-summary
> R2#
> *Mar 1 00:17:45.427: %BGP-3-NOTIFICATION: received from neighbor
> 192.168.0.1 2/2 (peer in wrong AS) 2 bytes 0014
>
>
> Notice that the router configured with the "unexpected" AS is the one
> receiving the message; it is R1 that is doing the sending.
>
> Here is an open attempt from R1 to R2:
>
>
> Frame 10 (99 bytes on wire, 99 bytes captured)
> Ethernet II, Src: cc:00:1b:94:00:10 (cc:00:1b:94:00:10), Dst:
> cc:01:1b:94:00:10 (cc:01:1b:94:00:10)
> Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.2 (
> 192.168.0.2)
> Transmission Control Protocol, Src Port: 28656 (28656), Dst Port: bgp
> (179), Seq: 1, Ack: 1, Len: 45
> Source port: 28656 (28656)
> Destination port: bgp (179)
> Sequence number: 1 (relative sequence number)
> [Next sequence number: 46 (relative sequence number)]
> Acknowledgement number: 1 (relative ack number)
> Header length: 20 bytes
> Flags: 0x18 (PSH, ACK)
> Window size: 16384
> Checksum: 0x39ea [correct]
> Border Gateway Protocol
> OPEN Message
> Marker: 16 bytes
> Length: 45 bytes
> Type: OPEN Message (1)
> Version: 4
> My AS: 100
> Hold time: 180
> BGP identifier: 192.168.0.1
> Optional parameters length: 16 bytes
> Optional parameters
> Capabilities Advertisement (8 bytes)
> Parameter type: Capabilities (2)
> Parameter length: 6 bytes
> Multiprotocol extensions capability (6 bytes)
> Capability code: Multiprotocol extensions capability (1)
> Capability length: 4 bytes
> Capability value
> Address family identifier: IPv4 (1)
> Reserved: 1 byte
> Subsequent address family identifier: Unicast (1)
> Capabilities Advertisement (4 bytes)
> Parameter type: Capabilities (2)
> Parameter length: 2 bytes
> Route refresh capability (2 bytes)
> Capability code: Route refresh capability (128)
> Capability length: 0 bytes
> Capabilities Advertisement (4 bytes)
> Parameter type: Capabilities (2)
> Parameter length: 2 bytes
> Route refresh capability (2 bytes)
> Capability code: Route refresh capability (2)
> Capability length: 0 bytes
>
>
> Note that R1 identifies "My AS" but not "Your AS" that I'm expecting to
> peer with. So we can't infer anything from the open attempts coming towards
> us (which was the doubt that crept into my mind). Now here is the
> notification message R1 is sending R2:
>
>
> No. Time Source Destination Protocol
> Info
> 12 32.859000 192.168.0.1 192.168.0.2 BGP
> NOTIFICATION Message
>
> Frame 12 (77 bytes on wire, 77 bytes captured)
> Ethernet II, Src: cc:00:1b:94:00:10 (cc:00:1b:94:00:10), Dst:
> cc:01:1b:94:00:10 (cc:01:1b:94:00:10)
> Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.2 (
> 192.168.0.2)
> Transmission Control Protocol, Src Port: 28656 (28656), Dst Port: bgp
> (179), Seq: 46, Ack: 65, Len: 23
> Source port: 28656 (28656)
> Destination port: bgp (179)
> Sequence number: 46 (relative sequence number)
> [Next sequence number: 69 (relative sequence number)]
> Acknowledgement number: 65 (relative ack number)
> Header length: 20 bytes
> Flags: 0x18 (PSH, ACK)
> Window size: 16320
> Checksum: 0x0436 [correct]
> [SEQ/ACK analysis]
> Border Gateway Protocol
> NOTIFICATION Message
> Marker: 16 bytes
> Length: 23 bytes
> Type: NOTIFICATION Message (3)
> Error code: OPEN Message Error (2)
> Error subcode: Bad Peer AS (2)
> Data
>
>
> Note that in the actual trace file, "Data" at the very end is in fact
> "0014" and nothing more. That obviously is R1 echoing back to R2 what it
> sent as "My AS" in the R2->R1 BGP open attempt. Just for the sake of being
> thorough, here is the open message (actually, this is not an original "open"
> message but rather a follow-up attempt before the TCP socket was closed
> following the R1->R2 error notification and the whole thing started again --
> but the differences are minimal) from R2 to R1 that is being rejected:
>
>
> Frame 11 (118 bytes on wire, 118 bytes captured)
> Ethernet II, Src: cc:01:1b:94:00:10 (cc:01:1b:94:00:10), Dst:
> cc:00:1b:94:00:10 (cc:00:1b:94:00:10)
> Internet Protocol, Src: 192.168.0.2 (192.168.0.2), Dst: 192.168.0.1 (
> 192.168.0.1)
> Transmission Control Protocol, Src Port: bgp (179), Dst Port: 28656
> (28656), Seq: 1, Ack: 46, Len: 64
> Source port: bgp (179)
> Destination port: 28656 (28656)
> Sequence number: 1 (relative sequence number)
> [Next sequence number: 65 (relative sequence number)]
> Acknowledgement number: 46 (relative ack number)
> Header length: 20 bytes
> Flags: 0x18 (PSH, ACK)
> Window size: 16339
> Checksum: 0x2722 [correct]
> [SEQ/ACK analysis]
> Border Gateway Protocol
> OPEN Message
> Marker: 16 bytes
> Length: 45 bytes
> Type: OPEN Message (1)
> Version: 4
> My AS: 20
> Hold time: 180
> BGP identifier: 192.168.0.2
> Optional parameters length: 16 bytes
> Optional parameters
> Capabilities Advertisement (8 bytes)
> Parameter type: Capabilities (2)
> Parameter length: 6 bytes
> Multiprotocol extensions capability (6 bytes)
> Capability code: Multiprotocol extensions capability (1)
> Capability length: 4 bytes
> Capability value
> Address family identifier: IPv4 (1)
> Reserved: 1 byte
> Subsequent address family identifier: Unicast (1)
> Capabilities Advertisement (4 bytes)
> Parameter type: Capabilities (2)
> Parameter length: 2 bytes
> Route refresh capability (2 bytes)
> Capability code: Route refresh capability (128)
> Capability length: 0 bytes
> Capabilities Advertisement (4 bytes)
> Parameter type: Capabilities (2)
> Parameter length: 2 bytes
> Route refresh capability (2 bytes)
> Capability code: Route refresh capability (2)
> Capability length: 0 bytes
> Border Gateway Protocol
> KEEPALIVE Message
> Marker: 16 bytes
> Length: 19 bytes
> Type: KEEPALIVE Message (4)
>
>
> And finally, just for the hell of it, here's an original R2->R1 "open"
> message sent immediately following the establishment of a new TCP socket:
>
>
> No. Time Source Destination Protocol
> Info
> 25 61.611000 192.168.0.2 192.168.0.1 BGP
> OPEN Message
>
> Frame 25 (99 bytes on wire, 99 bytes captured)
> Ethernet II, Src: cc:01:1b:94:00:10 (cc:01:1b:94:00:10), Dst:
> cc:00:1b:94:00:10 (cc:00:1b:94:00:10)
> Internet Protocol, Src: 192.168.0.2 (192.168.0.2), Dst: 192.168.0.1 (
> 192.168.0.1)
> Transmission Control Protocol, Src Port: 16804 (16804), Dst Port: bgp
> (179), Seq: 1, Ack: 1, Len: 45
> Source port: 16804 (16804)
> Destination port: bgp (179)
> Sequence number: 1 (relative sequence number)
> [Next sequence number: 46 (relative sequence number)]
> Acknowledgement number: 1 (relative ack number)
> Header length: 20 bytes
> Flags: 0x18 (PSH, ACK)
> Window size: 16384
> Checksum: 0x64e7 [correct]
> Border Gateway Protocol
> OPEN Message
> Marker: 16 bytes
> Length: 45 bytes
> Type: OPEN Message (1)
> Version: 4
> My AS: 20
> Hold time: 180
> BGP identifier: 192.168.0.2
> Optional parameters length: 16 bytes
> Optional parameters
> Capabilities Advertisement (8 bytes)
> Parameter type: Capabilities (2)
> Parameter length: 6 bytes
> Multiprotocol extensions capability (6 bytes)
> Capability code: Multiprotocol extensions capability (1)
> Capability length: 4 bytes
> Capability value
> Address family identifier: IPv4 (1)
> Reserved: 1 byte
> Subsequent address family identifier: Unicast (1)
> Capabilities Advertisement (4 bytes)
> Parameter type: Capabilities (2)
> Parameter length: 2 bytes
> Route refresh capability (2 bytes)
> Capability code: Route refresh capability (128)
> Capability length: 0 bytes
> Capabilities Advertisement (4 bytes)
> Parameter type: Capabilities (2)
> Parameter length: 2 bytes
> Route refresh capability (2 bytes)
> Capability code: Route refresh capability (2)
> Capability length: 0 bytes
>
>
> So unless Marko and I are both missing something, the "expected" AS is
> never sent to the offending router.
>
> Regards,
>
> Scott
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Marko Milivojevic
> Sent: Friday, October 24, 2008 2:04 PM
> To: nouman abbasi
> Cc: Scott M Vermillion; Cisco certification
> Subject: Re: BGP Error
>
> On Fri, Oct 24, 2008 at 17:12, nouman abbasi <abbasi.nouman@gmail.com>
> wrote:
> > But in the LAB Exam ; we dont have access to the BackBone ; how to
> overcome
> > in such scenario.
>
> No, you don't. However, the very error message yourself should
> indicate to you that you are doing something wrong. I hope you read my
> blog (I'm not advertising, but I don't want to write something for 4th
> time). It is clearly an impossible problem to solve and those are NOT
> present in the lab. So, if something appears to be impossible, it
> means that you are doing something wrong. That is troubleshooting
> portion of the exam -- you need to figure out way out of the mess you
> made!
>
> > Sorry to say but proctor behaves wierd sometimes.
> > I remember a comment from a proctor to my friend
> >
> > Comment => "The question is in plain English ; dont ask such question"
>
> Please, don't trust those stories. Proctors are very helpful and
> forthcoming professionals. If you ask them politely, you will receive
> answer that should point you in the right direction. If your friend
> got that answer, that means that he asked a very wrong question. I
> once got an answer "please, read your workbook". That was enough for
> me to know that I horribly overlooked something!
>
> --
> Marko
> CCIE #18427 (SP)
> My network blog: http://cisco.markom.info/
>
>
> 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
>
>
>
>
>
>
>
>
-- Regards,Shahid Ansari Saudi Arabia(Riyadh)
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sat Nov 01 2008 - 15:35:22 ARST