From: rsevier (rsevier@xxxxxxxxxxxxxxxxxxx)
Date: Sat Aug 25 2001 - 12:30:42 GMT-3
B- You need the debugs from 2522B because that is the router that is
pointing to the loopback and is most probable to not be able to establish a
TCP connection. Your P4R2 router is pointing at a physical interface which
doesn't rely on any additional commands for the update source.
Raymond
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Brent D. Stewart
Sent: Saturday, August 25, 2001 6:53 AM
To: ccielab@groupstudy.com
Subject: RE: BGP - why does this work?
John and Raymond - thanks for your thoughts. I may have oversimplified the
configs in the original question, for which I apologize. As you requested,
I've compiled some feedback from the routers. I've edited the configs for
brevity, but tried to leave everything that could remotely effect BGP
routing. I've also edited the debugs for brevity, but only to remove
feedback from other neighbors.
Executive Summary: In this instance, update-source lo0 is not required. My
reading of the following is that John and Raymond are correct, that each BGP
neighbor tries to peer but that only one succeeds (2522B, I think).
First, the config for P4R2:
=======================
Current configuration:
!
version 12.0
hostname P4R2
!
ip subnet-zero
no ip domain-lookup
!
interface Loopback0
ip address 192.168.104.1 255.255.255.0
no ip directed-broadcast
!
interface Serial1/0
ip address 192.168.4.97 255.255.255.224
no ip directed-broadcast
!
router rip
network 192.168.4.0
network 192.168.104.0
!
router bgp 65042
redistribute connected
neighbor 172.24.5.5 remote-as 65041
neighbor 172.24.5.14 remote-as 65043
neighbor 192.168.4.98 remote-as 65501
no auto-summary
!
ip classless
!
end
And this is the current state:
==============================
P4R2#sh ip bgp n 192.168.4.98
BGP neighbor is 192.168.4.98, remote AS 65501, external link
Index 3, Offset 0, Mask 0x8
BGP version 4, remote router ID 10.22.22.2
BGP state = Established, table version = 54, up for 20:01:34
Last read 00:00:34, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 1288 messages, 12 notifications, 0 in queue
Sent 1387 messages, 0 notifications, 0 in queue
Prefix advertised 45, suppressed 0, withdrawn 1
Connections established 3; dropped 2
Last reset 20:01:37, due to Peer closed the session
3 accepted prefixes consume 96 bytes
0 history paths consume 0 bytes
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 192.168.104.1, Local port: 179
Foreign host: 192.168.4.98, Foreign port: 11899
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x8EFC5C0):
Timer Starts Wakeups Next
Retrans 5008 3797 0x0
TimeWait 0 0 0x0
AckHold 1205 1021 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
iss: 1529512307 snduna: 1529535773 sndnxt: 1529535773 sndwnd: 16118
irs: 1511910464 rcvnxt: 1511933411 rcvwnd: 15396 delrcvwnd: 988
SRTT: 304 ms, RTTO: 670 ms, RTV: 31 ms, KRTT: 0 ms
minRTT: 12 ms, maxRTT: 428 ms, ACK hold: 200 ms
Flags: passive open, nagle, gen tcbs
Datagrams (max data segment is 1460 bytes):
Rcvd: 1950 (out of order: 0), with data: 1205, total data bytes: 22946
Sent: 2247 (retransmit: 3797), with data: 1210, total data bytes: 23465
P4R2#
Here is the config for 2522B
============================
Current configuration:
!
version 12.0
hostname 2522B
!
ip subnet-zero
!
interface Loopback0
ip address 10.20.20.2 255.255.255.0
no ip directed-broadcast
!
interface Loopback1
ip address 10.22.22.2 255.255.255.0
no ip directed-broadcast
!
interface Serial4
bandwidth 115
ip address 192.168.4.98 255.255.255.224
no ip directed-broadcast
ip rip send version 1 2
ip rip receive version 1 2
ipx network 4004
clockrate 115200
!
router rip
version 2
passive-interface Ethernet0
passive-interface Loopback0
passive-interface Loopback1
network 10.0.0.0
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
network 192.168.5.0
network 192.168.6.0
no auto-summary
!
router bgp 65501
network 10.20.20.0 mask 255.255.255.0
network 10.22.22.0 mask 255.255.255.0
network 10.100.100.0 mask 255.255.255.0
neighbor 192.168.1.97 remote-as 65101
neighbor 192.168.2.97 remote-as 65102
neighbor 192.168.3.97 remote-as 65103
neighbor 192.168.4.97 remote-as 65104
neighbor 192.168.5.97 remote-as 65105
neighbor 192.168.6.97 remote-as 65106
neighbor 192.168.104.1 remote-as 65042
neighbor 192.168.104.1 ebgp-multihop 2
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.3 190
!
end
Per your suggestion, I looked to see if it was being refused one way and
accepted the other:
==================================
P4R2#debug ip bgp
BGP debugging is on
P4R2#clear ip bgp 192.168.4.98
P4R2#
1d17h: BGP: 192.168.4.98 closing
1d17h: BGP: 192.168.4.98 open active, delay 16036ms
P4R2#
1d17h: BGP: 192.168.4.98 open active, local address 192.168.4.97
1d17h: BGP: 192.168.4.98 sending OPEN, version 4
1d17h: BGP: 192.168.4.98 remote close, state CLOSEWAIT
1d17h: BGP: 192.168.4.98 closing
P4R2#
1d17h: BGP: 192.168.4.98 passive open
1d17h: BGP: 192.168.4.98 OPEN rcvd, version 4
1d17h: BGP: 192.168.4.98 sending OPEN, version 4
P4R2#
P4R2#sh ip bgp n 192.168.4.98
BGP neighbor is 192.168.4.98, remote AS 65501, external link
Index 3, Offset 0, Mask 0x8
BGP version 4, remote router ID 10.22.22.2
BGP state = Established, table version = 62, up for 00:01:24
Last read 00:00:24, hold time is 180, keepalive interval is 60 seconds
Minimum time between advertisement runs is 30 seconds
Received 1295 messages, 12 notifications, 0 in queue
Sent 1399 messages, 0 notifications, 0 in queue
Prefix advertised 60, suppressed 0, withdrawn 2
Connections established 4; dropped 3
Last reset 00:01:46, due to Peer closed the session
3 accepted prefixes consume 96 bytes
0 history paths consume 0 bytes
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 192.168.104.1, Local port: 179
Foreign host: 192.168.4.98, Foreign port: 12815
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x8F3DD34):
Timer Starts Wakeups Next
Retrans 10 3 0x0
TimeWait 0 0 0x0
AckHold 5 2 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
iss: 792459500 snduna: 792459862 sndnxt: 792459862 sndwnd: 16023
irs: 774273328 rcvnxt: 774273475 rcvwnd: 16238 delrcvwnd: 146
SRTT: 614 ms, RTTO: 4262 ms, RTV: 1517 ms, KRTT: 0 ms
minRTT: 12 ms, maxRTT: 300 ms, ACK hold: 200 ms
Flags: passive open, nagle, gen tcbs
Datagrams (max data segment is 1460 bytes):
Rcvd: 10 (out of order: 0), with data: 5, total data bytes: 146
Sent: 9 (retransmit: 3), with data: 6, total data bytes: 361
P4R2#
P4R2#debug ip bgp eve
BGP events debugging is on
P4R2#clear ip bgp 192.168.4.98
P4R2#
1d17h: BGP: 192.168.4.98 reset requested
1d17h: BGP: 192.168.4.98 reset due to User reset
1d17h: BGP: 192.168.4.98 went from Established to Idle
1d17h: BGP: 192.168.4.98 went from Idle to Active
P4R2#
1d17h: BGP: 192.168.4.98 went from Active to Idle
1d17h: BGP: 192.168.4.98 went from Idle to Connect
1d17h: BGP: 192.168.4.98 went from Connect to OpenSent
1d17h: BGP: 192.168.4.98 went from OpenSent to OpenConfirm
P4R2#
1d17h: BGP: 192.168.4.98 reset due to Peer closed the session
1d17h: BGP: 192.168.4.98 went from OpenConfirm to Idle
P4R2#
1d17h: BGP: scanning routing tables
P4R2#
1d17h: BGP: 172.24.5.14 computing updates, neighbor version 66, table
version 67
, starting at 0.0.0.0
1d17h: BGP: 172.24.5.14 update run completed, ran for 0ms, neighbor version
66,
start version 67, throttled to 67, check point net 0.0.0.0
1d17h: BGP: 192.168.4.98 went from Idle to Active
P4R2#
1d17h: BGP: 172.24.5.5 computing updates, neighbor version 66, table version
67,
starting at 0.0.0.0
1d17h: BGP: 172.24.5.5 update run completed, ran for 0ms, neighbor version
66, s
tart version 67, throttled to 67, check point net 0.0.0.0
P4R2#
1d17h: BGP: 192.168.4.98 went from Active to Idle
1d17h: BGP: 192.168.4.98 went from Idle to Connect
1d17h: BGP: 192.168.4.98 went from Connect to OpenSent
1d17h: BGP: 192.168.4.98 went from OpenSent to OpenConfirm
1d17h: BGP: 192.168.4.98 went from OpenConfirm to Established
P4R2#
1d17h: BGP: 192.168.4.98 computing updates, neighbor version 0, table
version 67
, starting at 0.0.0.0
1d17h: BGP: 192.168.4.98 update run completed, ran for 0ms, neighbor version
0,
start version 67, throttled to 67, check point net 0.0.0.0
P4R2#u all
All possible debugging has been turned off
P4R2#
-----Original Message-----
From: rsevier [mailto:rsevier@zealousolutions.com]
Sent: Friday, August 24, 2001 6:56 PM
To: John Hever; 'Brent D. Stewart'; ccielab@groupstudy.com
Subject: RE: BGP - why does this work?
John - I agree with everything you say, but I want to expand on that just a
little.
When a BGP session is estabished, both routers try to set up the TCP
connections by sending TCP SYN packets to each other. If both succeed, one
of the sessions will be brought down so only one remains. So with that
being said only one side is suceeding with the TCP connection and that is
all you need. If no update-source is configured, the source IP address will
be set to the IP address of the outgoing physical interface. The source
address configured on one peering router must match the destination address
configured on the other. The BGP session will not start otherwise.
Brent- Do some debugs and see if you can see one side failing and that
should prove that only a one way TCP connection is needed. I am interested
to see the proof.
Raymond
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
John Hever
Sent: Friday, August 24, 2001 11:08 AM
To: 'Brent D. Stewart'; ccielab@groupstudy.com
Subject: RE: BGP - why does this work?
Hi Brent,
OK here is my understanding:
The neighbor x.x.x.x update-source loopback x command is usually used
between IBGP peers when there is more than one physical path between them.
This ensures that the loopback interface address specified in the
'update-source' command is used as the source address in IBGP packets, this
ensures that the IBGP session is not reset (as it would be if we had not
specified an update-source address, because the IBGP packets would have used
the physical interface's IP address) if one of the physical interfaces
fails.
EBGP peerings are usually via a single serial link so the situation does not
arise.
A clearer, concise example is available in the Cisco BGP-4 Command and
Configuration Handbook, on page 235.
Other than that the configs you have posted should work, apart from the nei
10.0.0.2 ebgp-m 2 statement which I assume is a typo, and should say nei
10.0.0.1 ebgp-m 2.
HTH
John
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Brent D. Stewart
Sent: 24 August 2001 18:19
To: ccielab@groupstudy.com
Subject: BGP - why does this work?
I've got two routers that are directly attached with an HDLC circuit in my
lab. Each run BGP, one uses the serial address of the other in it's
neighbor statement; the other peers to a loopback interface.
R1--------------------------R2
s0 192.168.0.1/24 lo0 10.0.0.1/32
The R1 configuration looks like
router bgp 1
nei 10.0.0.1 remote-as 2
nei 10.0.0.2 ebgp-m 2
The R2 configuration looks like
router bgp 2
nei 192.168.0.1 remote-as 1
RIP is running between them as well, so R1 knows how to get to R2's
loopback.
Why does this work? I thought I needed to add to R2's configuration "nei
192.168.0.1 update-s lo0". I thought that R1's BGP process would check the
source address before peering (btw - adding the statement doesn't break it).
Obviously I thought wrong, because it works. R1 is running 12.0(10) and R2
is running 12.0(3c), but I've duplicated this with a couple of intervening
versions. Is this a v12 protect-them-from-themselves thing, or did I just
never understand this correctly?
Thanks everyone.
Regards,
Brent D. Stewart, CCSI
Global Knowledge
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:58 GMT-3