From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Sun Aug 08 2004 - 13:20:05 GMT-3
Another reason the BGP update source can be changed is to offer
a very basic form of load balancing. For example, if you have multiple
circuits from the same provider terminating on the same router, you can
use BGP's dependence on the IGP table to perform load balancing. Take
the following example:
/---\
R1 R2--ISP
\---/
R1 has multiple T1 circuits to the ISP which terminate on R2.
Suppose the interfaces are 12.0.0.0/8 and 21.0.0.0/8. R1 and R2 also
have the loopback addresses 1.1.1.1/32 and 2.2.2.2/32 respectively. A
BGP peering is created using these loopback addresses, and identical
routing information is configured for the loopback addresses out both
interfaces:
R1:
Router bgp 1
Neighbor 2.2.2.2 remote-as 2
Neighbor 2.2.2.2 update-source loopback0
Neighbor 2.2.2.2 ebgp-multihop
!
Ip route 2.2.2.2 255.255.255.255 serial0
Ip route 2.2.2.2 255.255.255.255 serial1
As the next hop value of all BGP learned information on R1 will
have the next-hop of 2.2.2.2, all traffic destined to the ISP will be
load balanced over both T1's based on the router's configured switching
mechanism.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> ccie2be
> Sent: Saturday, August 07, 2004 10:52 PM
> To: Larry Metzger; 'James'
> Cc: 'Group Study'
> Subject: Re: BGP Update Source
>
> Larry,
>
> Thanks to your question and keen observation, you started a lively
> discussion in which many of us learned something new.
>
> You're right. That's what GS is all about.
>
> Keep those cards and letters coming.
>
> Tim
> ----- Original Message -----
> From: "Larry Metzger" <larrymetzger@sbcglobal.net>
> To: "'James'" <james@towardex.com>; "'ccie2be'" <ccie2be@nyc.rr.com>
> Cc: "'Group Study'" <ccielab@groupstudy.com>
> Sent: Saturday, August 07, 2004 11:48 PM
> Subject: RE: BGP Update Source
>
>
> Thanks to all that participated in this. I checked the TCP
connections
> and they show R2 (port 11003) has connected to R1 (port 179). I
> remember reading about this once now that James brings it up. It
> usually goes back to theory. John also gives a good explanation of it
> in his last e-mail.
>
> Thanks again for giving me more information and a better
understanding.
> That's what this is all about.
>
> Larry
>
> -----Original Message-----
> From: James [mailto:james@towardex.com]
> Sent: Saturday, August 07, 2004 8:27 PM
> To: ccie2be
> Cc: Larry Metzger; 'Group Study'
> Subject: Re: BGP Update Source
>
> On Sat, Aug 07, 2004 at 11:12:40PM -0400, ccie2be wrote:
> > Very interesting. Hopefully, one of the bgp guru's will chime in
with
> an
> > explanation for why this is happening.
>
> Remember that in BGP, it uses Finite State Machine (FSM) to manage
> connectivity
> and session. If one end is not able to connect to the remote neighbor
> largely
> due to update-source, etc, (but not major issue like AS number
mismatch,
> etc)
> then the other end still has the chance to bring the connection alive
as
> long
> as TCP session works and OPEN message confirms proper neighbor
> relationship.
>
> In BGP, there is no Server vs. Client model as there is in most TCP
> application.
> You got two peers, whomever successfully makes connection first is the
> winner.
> If one is unable to do so, the other one still can provided your
config
> is not
> totally broken that will prevent it :)
>
> So for example, if R1 is peering with R2. And R2 peers with R1's
> loopback
> address and R1 peers with R2's ethernet address.. and let us say R1
does
> not have update-so loopback0 in its configuration. R1 attempting to
> start
> communication to R2 will fail as packets will source from non-loopback
> that
> R2 wants to peer with. R2 creating session to R1 will succeed as R2
> sources
> pkt from ethernet that is expected by R1.
>
> You may however notice and I say *may*, that bgp session is coming up
a
> tad
> bit slower than usual with this setup, b/c only one neighbor is able
to
> successfully initiate the connection through FSM loop.
>
> -J
>
> >
> > All, I can say, is that in my limited bgp experience, if I didn't
> follow the
> > rules exactly, things never worked.
> >
> > I'll stayed tuned to this thread.
> >
> >
> > ----- Original Message -----
> > From: "Larry Metzger" <larrymetzger@sbcglobal.net>
> > To: "'Group Study'" <ccielab@groupstudy.com>
> > Sent: Saturday, August 07, 2004 10:45 PM
> > Subject: RE: BGP Update Source
> >
> >
> > > I'll respond here for both CCIE2BE and William. If you're not
into
> BGP
> > > ignore this!!!!!
> > >
> > > I understand the concepts very well. However, I have to say that
in
> the
> > > lab it works as I have described and the following should show
what
> I am
> > > talking about.
> > >
> > > For those interested in a full network diagram...I'm using
IPExpert
> lab
> > > number 9 on BGP. I have a router R1 (1605 with 12.2(15)T13)
> connecting
> > > over Ethernet to R2 (2503 with 12.2(24b)). The R1 has a loopback0
> IP
> > > 200.0.0.1 that will be called as the neighbor by R2. R1 calls
> neighbor
> > > using Ethernet address. WITH OR WITHOUT the update-source command
> > > connections are created and the systems work with BGP. What
follows
> is
> > > lengthy.
> > >
> > > hostname r1
> > > !
> > > interface Loopback0
> > > ip address 200.0.0.1 255.255.255.255
> > > !
> > > interface Ethernet0
> > > ip address 150.50.17.1 255.255.255.0
> > > !
> > > router bgp 100
> > > no synchronization
> > > bgp router-id 200.0.0.1
> > > bgp log-neighbor-changes
> > > network 192.168.10.0 mask 255.255.255.240
> > > network 192.168.10.16 mask 255.255.255.240
> > > network 192.168.20.32 mask 255.255.255.240
> > > network 192.168.20.48 mask 255.255.255.240
> > > aggregate-address 192.168.10.0 255.255.255.0 summary-only
> > > aggregate-address 192.168.20.0 255.255.255.0 summary-only
> > > neighbor 150.50.17.2 remote-as 200
> > > no auto-summary
> > > !
> > >
> > > r1#clear ip bgp *
> > > r1#
> > > *Mar 1 00:05:01.175: %BGP-5-ADJCHANGE: neighbor 150.50.17.2 Down
> User
> > > reset
> > > r1#
> > > *Mar 1 00:05:43.513: %BGP-5-ADJCHANGE: neighbor 150.50.17.2 Up
> > > r1#sh ip bgp nei
> > > BGP neighbor is 150.50.17.2, remote AS 200, external link
> > > BGP version 4, remote router ID 200.0.0.2
> > > BGP state = Established, up for 00:01:16
> > > Last read 00:00:15, hold time is 180, keepalive interval is 60
> seconds
> > > Neighbor capabilities:
> > > Route refresh: advertised and received(old & new)
> > > Address family IPv4 Unicast: advertised and received
> > > Message statistics:
> > > InQ depth is 0
> > > OutQ depth is 0
> > > Sent Rcvd
> > > Opens: 2 2
> > > Notifications: 0 0
> > > Updates: 2 4
> > > Keepalives: 10 10
> > > Route Refresh: 0 0
> > > Total: 14 16
> > > Default minimum time between advertisement runs is 30 seconds
> > >
> > > For address family: IPv4 Unicast
> > > BGP table version 14, neighbor version 14
> > > Index 1, Offset 0, Mask 0x2
> > > Sent Rcvd
> > > Prefix activity: ---- ----
> > > Prefixes Current: 2 3 (Consumes 144
> bytes)
> > > Prefixes Total: 2 3
> > > Implicit Withdraw: 0 0
> > > Explicit Withdraw: 0 0
> > > Used as bestpath: n/a 3
> > > Used as multipath: n/a 0
> > >
> > > Outbound Inbound
> > > Local Policy Denied Prefixes: -------- -------
> > > Bestpath from this peer: 3 n/a
> > > Suppressed due to dampening: 4 n/a
> > > Total: 7 0
> > > Number of NLRIs in the update sent: max 2, min 0
> > >
> > > Connections established 2; dropped 1
> > > Last reset 00:02:00, due to User reset
> > > Connection state is ESTAB, I/O status: 1, unread input bytes: 0
> > > Local host: 200.0.0.1, Local port: 179
> > > Foreign host: 150.50.17.2, Foreign port: 11003
> > >
> > > Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0
> bytes)
> > >
> > > Event Timers (current time is 0x67EE8):
> > > Timer Starts Wakeups Next
> > > Retrans 7 0 0x0
> > > TimeWait 0 0 0x0
> > > AckHold 5 1 0x0
> > > SendWnd 0 0 0x0
> > > KeepAlive 0 0 0x0
> > > GiveUp 0 0 0x0
> > > PmtuAger 0 0 0x0
> > > DeadWait 0 0 0x0
> > >
> > > iss: 3216124146 snduna: 3216124336 sndnxt: 3216124336
sndwnd:
> > > 16195
> > > irs: 1986047258 rcvnxt: 1986047484 rcvwnd: 16159
delrcvwnd:
> > > 225
> > >
> > > SRTT: 182 ms, RTTO: 1073 ms, RTV: 891 ms, KRTT: 0 ms
> > > minRTT: 4 ms, maxRTT: 300 ms, ACK hold: 200 ms
> > > Flags: passive open, nagle, gen tcbs
> > > --More--
> > > Datagrams (max data segment is 536 bytes):
> > > Rcvd: 10 (out of order: 0), with data: 5, total data bytes: 225
> > > Sent: 8 (retransmit: 0, fastretransmit: 0), with data: 6, total
data
> > > bytes: 189
> > > r1#sh ip bgp
> > > BGP table version is 14, local router ID is 200.0.0.1
> > > Status codes: s suppressed, d damped, h history, * valid, > best,
i
> -
> > > internal,
> > > r RIB-failure, S Stale
> > > Origin codes: i - IGP, e - EGP, ? - incomplete
> > >
> > > Network Next Hop Metric LocPrf Weight Path
> > > *> 10.1.1.0/24 150.50.17.2 0 200
300
> 310
> > > 320 330 i
> > > s> 192.168.10.0/28 0.0.0.0 0 32768 i
> > > *> 192.168.10.0 0.0.0.0 32768 i
> > > s> 192.168.10.16/28 0.0.0.0 0 32768 i
> > > *> 192.168.20.0 0.0.0.0 32768 i
> > > s> 192.168.20.32/28 0.0.0.0 0 32768 i
> > > s> 192.168.20.48/28 0.0.0.0 0 32768 i
> > > *> 200.0.0.4/32 150.50.17.2 0 200
300
> 310
> > > 320 330 i
> > > *> 200.0.0.6/32 150.50.17.2 0 200 i
> > > r1#sh tcp
> > >
> > > Stand-alone TCP connection from host 150.50.17.2
> > > Connection state is ESTAB, I/O status: 1, unread input bytes: 0
> > > Local host: 200.0.0.1, Local port: 179
> > > Foreign host: 150.50.17.2, Foreign port: 11003
> > >
> > > Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0
> bytes)
> > >
> > > Event Timers (current time is 0x69CCC):
> > > Timer Starts Wakeups Next
> > > Retrans 7 0 0x0
> > > TimeWait 0 0 0x0
> > > AckHold 5 1 0x0
> > > SendWnd 0 0 0x0
> > > KeepAlive 0 0 0x0
> > > GiveUp 0 0 0x0
> > > PmtuAger 0 0 0x0
> > > DeadWait 0 0 0x0
> > >
> > > iss: 3216124146 snduna: 3216124336 sndnxt: 3216124336
sndwnd:
> > > 16195
> > > irs: 1986047258 rcvnxt: 1986047484 rcvwnd: 16159
delrcvwnd:
> > > 225
> > >
> > > SRTT: 182 ms, RTTO: 1073 ms, RTV: 891 ms, KRTT: 0 ms
> > > minRTT: 4 ms, maxRTT: 300 ms, ACK hold: 200 ms
> > > Flags: passive open, nagle, gen tcbs
> > >
> > > Datagrams (max data segment is 536 bytes):
> > > Rcvd: 10 (out of order: 0), with data: 5, total data bytes: 225
> > > Sent: 8 (retransmit: 0, fastretransmit: 0), with data: 6, total
data
> > > bytes: 189
> > > r1#
> > > *************************************************
> > > hostname r2
> > > !
> > > interface Ethernet0
> > > ip address 150.50.17.2 255.255.255.0
> > > !
> > > router bgp 65256
> > > no synchronization
> > > bgp router-id 200.0.0.2
> > > bgp log-neighbor-changes
> > > bgp confederation identifier 200
> > > bgp confederation peers 65078
> > > neighbor 150.50.24.4 remote-as 300
> > > neighbor 150.50.24.4 route-map task11 out
> > > neighbor 150.50.100.5 remote-as 65256
> > > neighbor 150.50.100.5 next-hop-self
> > > neighbor 150.50.100.5 route-map task10 out
> > > neighbor 200.0.0.1 remote-as 100
> > > neighbor 200.0.0.1 ebgp-multihop 2
> > > no auto-summary
> > > !
> > > ip route 200.0.0.1 255.255.255.255 150.50.17.1
> > >
> > >
> > > sh ip bgp nei 200.0.0.1
> > > BGP neighbor is 200.0.0.1, remote AS 100, external link
> > > BGP version 4, remote router ID 200.0.0.1
> > > BGP state = Established, up for 00:02:07
> > > Last read 00:00:08, hold time is 180, keepalive interval is 60
> seconds
> > > Neighbor capabilities:
> > > Route refresh: advertised and received(old & new)
> > > Address family IPv4 Unicast: advertised and received
> > > Message statistics:
> > > InQ depth is 0
> > > OutQ depth is 0
> > > Sent Rcvd
> > > Opens: 2 2
> > > Notifications: 0 0
> > > Updates: 4 2
> > > Keepalives: 11 11
> > > Route Refresh: 0 0
> > > Total: 17 15
> > > Default minimum time between advertisement runs is 30 seconds
> > >
> > > For address family: IPv4 Unicast
> > > BGP table version 12, neighbor version 12
> > > Index 3, Offset 0, Mask 0x8
> > > Sent Rcvd
> > > Prefix activity: ---- ----
> > > Prefixes Current: 3 2 (Consumes 72
bytes)
> > > Prefixes Total: 3 2
> > > Implicit Withdraw: 0 0
> > > Explicit Withdraw: 0 0
> > > Used as bestpath: n/a 2
> > > Used as multipath: n/a 0
> > >
> > > Outbound Inbound
> > > Local Policy Denied Prefixes: -------- -------
> > > Well-known Community: 2 n/a
> > > Bestpath from this peer: 2 n/a
> > > Total: 4 0
> > > Number of NLRIs in the update sent: max 2, min 0
> > >
> > > Connections established 2; dropped 1
> > > Last reset 00:02:49, due to Peer closed the session
> > > External BGP neighbor may be up to 2 hops away.
> > > --More-- Connection state is ESTAB, I/O
> > > status: 1, unread input bytes: 0
> > > Local host: 150.50.17.2, Local port: 11003
> > > Foreign host: 200.0.0.1, Foreign port: 179
> > >
> > > Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0
> bytes)
> > >
> > > Event Timers (current time is 0x87ED4):
> > > Timer Starts Wakeups Next
> > > Retrans 7 0 0x0
> > > TimeWait 0 0 0x0
> > > AckHold 7 4 0x0
> > > SendWnd 0 0 0x0
> > > KeepAlive 0 0 0x0
> > > GiveUp 0 0 0x0
> > > PmtuAger 0 0 0x0
> > > DeadWait 0 0 0x0
> > >
> > > iss: 1986047258 snduna: 1986047503 sndnxt: 1986047503
sndwnd:
> > > 16140
> > > irs: 3216124146 rcvnxt: 3216124355 rcvwnd: 16176
delrcvwnd:
> > > 208
> > >
> > > SRTT: 182 ms, RTTO: 1073 ms, RTV: 891 ms, KRTT: 0 ms
> > > minRTT: 8 ms, maxRTT: 300 ms, ACK hold: 200 ms
> > > Flags: higher precedence, nagle
> > > --More--
> > > Datagrams (max data segment is 536 bytes):
> > > Rcvd: 10 (out of order: 0), with data: 7, total data bytes: 208
> > > Sent: 12 (retransmit: 0, fastretransmit: 0), with data: 6, total
> data
> > > bytes: 244
> > > r2#sh ip bgp
> > > BGP table version is 12, local router ID is 200.0.0.2
> > > Status codes: s suppressed, d damped, h history, * valid, > best,
i
> -
> > > internal
> > > Origin codes: i - IGP, e - EGP, ? - incomplete
> > >
> > > Network Next Hop Metric LocPrf Weight Path
> > > *>i8.8.8.0/24 150.50.100.5 0 100 0
(65078)
> ?
> > > *> 10.1.1.0/24 150.50.24.4 0 0 300
310
> 320
> > > 330 i
> > > *>i150.50.4.0/24 150.50.100.5 20 100 0
(65078)
> ?
> > > *> 192.168.10.0 200.0.0.1 0 0 100 i
> > > *> 192.168.20.0 200.0.0.1 0 0 100 i
> > > *> 200.0.0.4/32 150.50.24.4 0 0 300
310
> 320
> > > 330 i
> > > *>i200.0.0.6/32 150.50.100.6 0 100 0 i
> > > r2#sh tcp
> > >
> > > Stand-alone TCP connection to host 150.50.100.5
> > > Connection state is ESTAB, I/O status: 1, unread input bytes: 0
> > > Local host: 150.50.100.2, Local port: 11000
> > > Foreign host: 150.50.100.5, Foreign port: 179
> > >
> > > Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0
> bytes)
> > >
> > > Event Timers (current time is 0x8A168):
> > > Timer Starts Wakeups Next
> > > Retrans 16 0 0x0
> > > TimeWait 0 0 0x0
> > > AckHold 10 6 0x0
> > > SendWnd 0 0 0x0
> > > KeepAlive 0 0 0x0
> > > GiveUp 0 0 0x0
> > > PmtuAger 0 0 0x0
> > > DeadWait 0 0 0x0
> > >
> > > iss: 3993375966 snduna: 3993376441 sndnxt: 3993376441
sndwnd:
> > > 15910
> > > irs: 1772481955 rcvnxt: 1772482393 rcvwnd: 15947
delrcvwnd:
> > > 437
> > >
> > > SRTT: 265 ms, RTTO: 545 ms, RTV: 280 ms, KRTT: 0 ms
> > > --More-- minRTT: 8 ms, maxRTT: 308 ms,
> ACK
> > > hold: 200 ms
> > > Flags: higher precedence, nagle
> > >
> > > Datagrams (max data segment is 1460 bytes):
> > > Rcvd: 19 (out of order: 0), with data: 10, total data bytes: 437
> > > Sent: 23 (retransmit: 0, fastretransmit: 0), with data: 15, total
> data
> > > bytes: 474
> > >
> > > Stand-alone TCP connection to host 200.0.0.1
> > > Connection state is ESTAB, I/O status: 1, unread input bytes: 0
> > > Local host: 150.50.17.2, Local port: 11003
> > > Foreign host: 200.0.0.1, Foreign port: 179
> > >
> > > Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0
> bytes)
> > >
> > > Event Timers (current time is 0x8AA78):
> > > Timer Starts Wakeups Next
> > > Retrans 7 0 0x0
> > > TimeWait 0 0 0x0
> > > AckHold 7 4 0x0
> > > SendWnd 0 0 0x0
> > > KeepAlive 0 0 0x0
> > > GiveUp 0 0 0x0
> > > --More-- PmtuAger 0
0
> > > 0x0
> > > DeadWait 0 0 0x0
> > >
> > > iss: 1986047258 snduna: 1986047503 sndnxt: 1986047503
sndwnd:
> > > 16140
> > > irs: 3216124146 rcvnxt: 3216124355 rcvwnd: 16176
delrcvwnd:
> > > 208
> > >
> > > SRTT: 182 ms, RTTO: 1073 ms, RTV: 891 ms, KRTT: 0 ms
> > > minRTT: 8 ms, maxRTT: 300 ms, ACK hold: 200 ms
> > > Flags: higher precedence, nagle
> > >
> > > Datagrams (max data segment is 536 bytes):
> > > Rcvd: 10 (out of order: 0), with data: 7, total data bytes: 208
> > > Sent: 12 (retransmit: 0, fastretransmit: 0), with data: 6, total
> data
> > > bytes: 244
> > >
> > > Stand-alone TCP connection to host 150.50.24.4
> > > Connection state is ESTAB, I/O status: 1, unread input bytes: 0
> > > Local host: 150.50.24.2, Local port: 11001
> > > Foreign host: 150.50.24.4, Foreign port: 179
> > >
> > > Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0
> bytes)
> > >
> > > Event Timers (current time is 0x8B298):
> > > Timer Starts Wakeups Next
> > > --More-- Retrans 13
0
> > > 0x0
> > > TimeWait 0 0 0x0
> > > AckHold 12 7 0x0
> > > SendWnd 0 0 0x0
> > > KeepAlive 0 0 0x0
> > > GiveUp 0 0 0x0
> > > PmtuAger 0 0 0x0
> > > DeadWait 0 0 0x0
> > >
> > > iss: 2325565762 snduna: 2325566044 sndnxt: 2325566044
sndwnd:
> > > 16103
> > > irs: 1896377811 rcvnxt: 1896378110 rcvwnd: 16086
delrcvwnd:
> > > 298
> > >
> > > SRTT: 253 ms, RTTO: 657 ms, RTV: 404 ms, KRTT: 0 ms
> > > minRTT: 24 ms, maxRTT: 404 ms, ACK hold: 200 ms
> > > Flags: higher precedence, nagle
> > >
> > > Datagrams (max data segment is 1460 bytes):
> > > Rcvd: 18 (out of order: 0), with data: 12, total data bytes: 298
> > > Sent: 21 (retransmit: 0, fastretransmit: 0), with data: 12, total
> data
> > > bytes: 281
> > > r2
> > >
> > > -----Original Message-----
> > > From: William Chen [mailto:kwchen@netvigator.com]
> > > Sent: Saturday, August 07, 2004 7:07 PM
> > > To: Larry Metzger; Group Study
> > > Subject: Re: BGP Update Source
> > >
> > > Hi Larry,
> > >
> > > I think update-source is necessary, if you want to form the BGP
> peer
> > > using loopback address. It is because, when BGP get reply from
> neighbor,
> > > it
> > > will expected the source address of the reply is matching with the
> > > address
> > > you set in the neighbor statement. It is impossible that the reply
> > > message
> > > from the BGP peer use loopback as source address (it will use the
> > > outging
> > > physical address as the source address for most time), unless you
> told
> > > the
> > > router to do so (i.e. using the update-source command).
> > >
> > > I will appreciate if you send us the configuration and also
state
> > > which
> > > IOS version you used.
> > >
> > > HTH,
> > > William
> > >
> > > ----- Original Message -----
> > > From: "Larry Metzger" <larrymetzger@sbcglobal.net>
> > > To: "Group Study" <ccielab@groupstudy.com>
> > > Sent: Sunday, August 08, 2004 8:10 AM
> > > Subject: BGP Update Source
> > >
> > >
> > > > I am working on BGP configurations. I have Router1 (as100) and
> > > Router2
> > > > (as200). I'm using the loopback on Router1 for the neighbor
> > > statement.
> > > > The recommendation is to add "neigh R2 update-source loop0" I
> have
> > > > configured these routers with and without the update source and
> > > > everything works fine either way (sh ip bgp, sh ip bgp nei, sh
> tcp).
> > > Is
> > > > it necessary? What problems will it cause if you don't change
the
> > > > update-source?
> > > >
> > > > Larry
> > > >
> > > >
> > >
>
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:35 GMT-3