From: Scott M Vermillion (scott_ccie_list@it-ag.com)
Date: Fri Oct 24 2008 - 19:30:59 ARST
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.2 2/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
This archive was generated by hypermail 2.1.4 : Sat Nov 01 2008 - 15:35:22 ARST