From: Scott Morris (swm@emanon.com)
Date: Sat Jul 05 2003 - 23:21:10 GMT-3
Perhaps it's a Cisco implementation of how to avoid connection
collisions, or perhaps it's a later RFC. I haven't been bored enough to
read all the BGP RFC's! :)
But when debugging bgp, I noticed a backoff delay message that came up
with a fairly large number (I assume it's in milliseconds though) on my
lower IP peer whereas my higher IP peer tried to connect immediately.
But you'll probably find from your debugs as R15 was getting reloaded,
R13 got a little miffed at the lack of conversation and tried to
initiate the connection itself.
Scott
-----Original Message-----
From: Volkov, Dmitry (IDS Canada) [mailto:dmitry_volkov@ca.ml.com]
Sent: Saturday, July 05, 2003 9:35 PM
To: 'swm@emanon.com'; 'Brian McGahan'; 'Donny MATEO'
Cc: ccielab@groupstudy.com
Subject: RE: BGP peer establishment
Scott,
You said "lower IP (because each one knows it's IP
in relation to the neighbor set up) will initiate a backoff delay so
that the side with the higher IP CAN initiate the connection." -
can you point me please where it's described.
I did test:
R13 (lower id) ----Hub(sniffer)--R15 (higher id)
1) reload both routers. R15 came first and espablished peering with R13.
1st packet R15 sent TCP SYN,
2nd R13 SYN-ACK,
3rd R15 ACK
4th R15 sent BGP Open
5th R13 sent BGP Open
and so on....
2) reload R15.
1st packet R13 sent TCP SYN,
2nd R15 SYN-ACK,
3rd R13 ACK
4th R13 sent BGP Open
5th R15 sent BGP Open
and so on... R13 estalished peering with R15.
3)
reload both, wait both up and connect broken media
R13---Hub(sniffer)---X---Hub(sniffer)--R15
X - no crossover
Silence. No TCP packets at all because on arp.
Connect crossover. The router which gets arp reply first - sending TCP
SYN first and establishes session. Another routers doesn't send any TCP
packets. I did item 3) twice: once I get lower id established session,
another time - higher. If one router receved TCP SYN from another it
doesnt start send back new TCP SYN.
My test somehow doesn't correlate with what said in RFC or maybe I
misunderstand something.
6.8 Connection collision detection.
If a pair of BGP speakers try simultaneously to establish a TCP
connection to each other, then two parallel connections between this
pair of speakers might well be formed. We refer to this situation as
connection collision. Clearly, one of these connections must be
closed.
Based on the value of the BGP Identifier a convention is established
for detecting which BGP connection is to be preserved when a
collision does occur. The convention is to compare the BGP
Identifiers of the peers involved in the collision and to retain only
the connection initiated by the BGP speaker with the higher-valued
BGP Identifier.
Dmitry
> -----Original Message-----
> From: Scott Morris [mailto:swm@emanon.com]
> Sent: Saturday, July 05, 2003 7:51 PM
> To: 'Volkov, Dmitry (IDS Canada)'; 'Brian McGahan'; 'Donny MATEO'
> Cc: ccielab@groupstudy.com
> Subject: RE: BGP peer establishment
>
>
> If you have a neighbor commmand configured, it will always attempt to
> establish a connection. It could care less whether you are sending
> routes or not. The object of BGP is kinda like an application at that
> point rather than a "decision" to make a connection.
>
> Scott
>
>
> -----Original Message-----
> From: Volkov, Dmitry (IDS Canada) [mailto:dmitry_volkov@ca.ml.com]
> Sent: Saturday, July 05, 2003 5:49 PM
> To: 'Brian McGahan'; Volkov, Dmitry (IDS Canada); 'Scott
> Morris'; 'Donny
> MATEO'
> Cc: ccielab@groupstudy.com
> Subject: RE: BGP peer establishment
>
>
> Brian,
>
> I agree that side with def route doesn't even send TCP SYN 179 (debug
> says "no route") I sniffed it In my case I just put static route on
> the router with def route. However I belive we all talk about the same
> ;) Router interprets bgp routes originated localy via "network"
> statement with "next hop 0.0.0.0" maybe here is the reason why router
> doesn't bother to establish session if it doesn't have longer match to
> peer.
>
>
> > -----Original Message-----
> > From: Brian McGahan [mailto:brian@cyscoexpert.com]
> > Sent: Saturday, July 05, 2003 5:40 PM
> > To: 'Volkov, Dmitry (IDS Canada)'; 'Scott Morris'; 'Donny MATEO'
> > Cc: ccielab@groupstudy.com
> > Subject: RE: BGP peer establishment
> >
> >
> > Dmitry,
> >
> > This is a different case then. What Scott said is correct. The
> side
> > with the default route cannot initiate the connection.
> >
> > In your case, since the side with the specific route is on the
> > outside interface, it can not initiate a BGP session to the
> router on
> > the inside.
> >
> > Did you try allowing the BGP connection in from the outside with
> an
> > access-list or a conduit?
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > Director of Design and Implementation
> > brian@cyscoexpert.com
> >
> > CyscoExpert Corporation
> > Internetwork Consulting & Training
> > Toll Free: 866.CyscoXP
> > Fax: 847.674.2625
> >
> >
> > > -----Original Message-----
> > > From: Volkov, Dmitry (IDS Canada) [mailto:dmitry_volkov@ca.ml.com]
> > > Sent: Friday, July 04, 2003 2:46 PM
> > > To: 'Brian McGahan'; 'Scott Morris'; 'Donny MATEO'
> > > Cc: ccielab@groupstudy.com
> > > Subject: RE: BGP peer establishment
> > >
> > > > -----Original Message-----
> > > > From: Brian McGahan [mailto:brian@cyscoexpert.com]
> > > > Sent: Friday, July 04, 2003 2:18 PM
> > > > To: 'Scott Morris'; 'Donny MATEO'; 'Volkov, Dmitry (IDS Canada)'
> > > > Cc: ccielab@groupstudy.com; nobody@groupstudy.com
> > > > Subject: RE: BGP peer establishment
> > > >
> > > >
> > > > Not necessarily. As long as one side of the
> connection has a
> > > > longer match than 0.0.0.0/0 adjacency can be established.
> > Take the
> > >
> > > I think this side (with longer match) should no be blocked by
> > firewall.
> > > In my case I had R5(172.50.50.5)---------(.1)pix(.10)--------
> > > (172.50.10.1)R1
> > > R5 inside (had default route), R1 outside (had specific
> route) TCP
> > > 179 session from R5 to R1 had to establish BGP peering R5
> did't try
> > > TCP 179 because of default route.
> > >
> > > r5#deb ip bgp out
> > > BGP debugging is on
> > > 01:19:08: BGP: 172.50.10.1 multihop open delayed 19152ms
> (no route)
> > >
> > > Does anybody know fundamental explanation - why BGP TCP
> > connection is
> > not
> > > established
> > > from source with def route to the neigbor ? is it cisco specific ?
> > >
> > >
> > > > following scenario:
> > > >
> > > > R1-16.0.0.0/8---R6---26.0.0.0/8---R2
> > > >
> > > > R1 is in AS 1, R2 is in AS 2. They are
> transitting R6 to peer.
> > > > The only route that R1 has to the 26.0.0.0/8 subnet is
> a default,
> > > > while R2 has a longer match to 16.0.0.0/8.
> > > >
> > > > R1#sh run | b router bgp
> > > > router bgp 1
> > > > bgp log-neighbor-changes
> > > > network 1.1.1.1 mask 255.255.255.255
> > > > neighbor 26.0.0.2 remote-as 2
> > > > neighbor 26.0.0.2 ebgp-multihop 255
> > > > !
> > > > ip route 0.0.0.0 0.0.0.0 16.0.0.6
> > > >
> > > > R2#sh run | b router bgp
> > > > router bgp 2
> > > > bgp log-neighbor-changes
> > > > network 2.2.2.2 mask 255.255.255.255
> > > > neighbor 16.0.0.1 remote-as 1
> > > > neighbor 16.0.0.1 ebgp-multihop 255
> > > > !
> > > > ip route 16.0.0.0 255.0.0.0 26.0.0.6
> > > >
> > > > R1#sh ip bgp sum | b Neighbor
> > > > Neighbor V AS MsgRcvd MsgSent TblVer InQ
> OutQ Up/Down
> > > > State/PfxRcd
> > > > 26.0.0.2 4 2 11 11 3 0
> > 0 00:06:32
> > > > 1
> > > >
> > > > R2#sh ip bgp sum | b Neighbor
> > > > Neighbor V AS MsgRcvd MsgSent TblVer InQ
> OutQ Up/Down
> > > > State/PfxRcd
> > > > 16.0.0.1 4 1 12 12 3 0
> > 0 00:07:10
> > > > 1
> > > >
> > > > R1#sh ip bgp
> > > > BGP table version is 3, local router ID is 16.0.0.1
> 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
> > > > *> 1.1.1.1/32 0.0.0.0 0 32768 i
> > > > *> 2.2.2.2/32 26.0.0.2 0 0 2 i
> > > >
> > > > R2#sh ip bgp
> > > > BGP table version is 3, local router ID is 26.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
> > > > *> 1.1.1.1/32 16.0.0.1 0 0 1 i
> > > > *> 2.2.2.2/32 0.0.0.0 0 32768 i
> > > >
> > > > R1#sh ip route
> > > > Codes: C - connected, S - static, I - IGRP, R - RIP, M
> - mobile, B
>
> > > > - BGP
> > > > D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter
> > area
> > > > N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
> > external type
> > 2
> > > > E1 - OSPF external type 1, E2 - OSPF external type
> > 2, E - EGP
> > > > i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
> > ia - IS-IS
> > > > inter area
> > > > * - candidate default, U - per-user static route, o - ODR
> > > > P - periodic downloaded static route
> > > >
> > > > Gateway of last resort is 16.0.0.6 to network 0.0.0.0
> > > >
> > > > C 16.0.0.0/8 is directly connected, FastEthernet0/6
> > > > 1.0.0.0/32 is subnetted, 1 subnets
> > > > C 1.1.1.1 is directly connected, Loopback0
> > > > 2.0.0.0/32 is subnetted, 1 subnets
> > > > B 2.2.2.2 [20/0] via 26.0.0.2, 00:06:08
> > > > S* 0.0.0.0/0 [1/0] via 16.0.0.6
> > > > R1#
> > > >
> > > > R2#sh ip route
> > > > Codes: C - connected, S - static, I - IGRP, R - RIP, M
> - mobile, B
>
> > > > - BGP
> > > > D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter
> > area
> > > > N1 - OSPF NSSA external type 1, N2 - OSPF NSSA
> > external type
> > 2
> > > > E1 - OSPF external type 1, E2 - OSPF external type
> > 2, E - EGP
> > > > i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
> > ia - IS-IS
> > > > inter area
> > > > * - candidate default, U - per-user static route, o - ODR
> > > > P - periodic downloaded static route
> > > >
> > > > Gateway of last resort is not set
> > > >
> > > > S 16.0.0.0/8 [1/0] via 26.0.0.6
> > > > 1.0.0.0/32 is subnetted, 1 subnets
> > > > B 1.1.1.1 [20/0] via 16.0.0.1, 00:06:55
> > > > 2.0.0.0/32 is subnetted, 1 subnets
> > > > C 2.2.2.2 is directly connected, Loopback0
> > > > C 26.0.0.0/8 is directly connected, FastEthernet0/6
> > > >
> > > >
> > > > As you can see from the above output, as long
> as one side has a
> > > > longer match than 0, BGP adjacency can be established.
> > > >
> > > > HTH,
> > > >
> > > > Brian McGahan, CCIE #8593
> > > > Director of Design and Implementation brian@cyscoexpert.com
> > > >
> > > > CyscoExpert Corporation
> > > > Internetwork Consulting & Training
> > > > Toll Free: 866.CyscoXP
> > > > Fax: 847.674.2625
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > Behalf
> > > > Of
> > > > > Scott Morris
> > > > > Sent: Friday, July 04, 2003 8:57 AM
> > > > > To: 'Donny MATEO'; 'Volkov, Dmitry (IDS Canada)'
> > > > > Cc: ccielab@groupstudy.com; nobody@groupstudy.com
> > > > > Subject: RE: BGP peer establishment
> > > > >
> > > > > There must be a non-default route to reach the other side. So
> > > > anything
> > > > > other than a 0/0 route will work.
> > > > >
> > > > > Scott
> > > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > Behalf
> > > > Of
> > > > > Donny MATEO
> > > > > Sent: Friday, July 04, 2003 1:58 AM
> > > > > To: Volkov, Dmitry (IDS Canada)
> > > > > Cc: 'ccielab@groupstudy.com'; nobody@groupstudy.com
> > > > > Subject: Re: BGP peer establishment
> > > > >
> > > > >
> > > > > If I remember correctly there was an old thread
> discussing this.
> > The
> > > > > conclusion is something like BGP need specific route to
> > establish
> > > > > peering. Not sure if there is anymore information as to why
> > > > and so on.
> > > > >
> > > > > Donny
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Volkov, Dmitry
> > > > >
> > > > > (IDS Canada)" To:
> > > > > "'ccielab@groupstudy.com'" <ccielab@groupstudy.com>
> > > > >
> > > > > <dmitry_volkov@ca cc:
> > > > >
> > > > > .ml.com> Subject:
> > BGP peer
> > > > > establishment
> > > > > Sent by:
> > > > >
> > > > > nobody@groupstudy
> > > > >
> > > > > .com
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 07/04/2003 06:22
> > > > >
> > > > > AM
> > > > >
> > > > > Please respond to
> > > > >
> > > > > "Volkov, Dmitry
> > > > >
> > > > > (IDS Canada)"
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > R5(172.50.50.5)---------(.1)pix(.10)--------(172.50.10.1)R1
> > > > >
> > > > > R5 can ping R1; R5 uses default route to reach R1. R5 can not
> > > > establish
> > > > > BGP peering with R1 until I put static route - more
> > specific than
> > > > > 0.0.0.0 0.0.0.0 - WHY ?
> > > > >
> > > > > r5#sh ip bgp sum
> > > > > BGP router identifier 60.5.5.5, local AS number 55 BGP table
> > > > > version is 1, main routing table version 1
> > > > >
> > > > > Neighbor V AS MsgRcvd MsgSent TblVer InQ
> > OutQ Up/Down
> > > > > State/PfxRcd
> > > > > 172.50.10.1 4 65 0 0 0 0
> 0 never
> > > > > Active
> > > > >
> > > > > r5#sh ip ro
> > > > > <snip>
> > > > > R* 0.0.0.0/0 [120/1] via 172.50.50.1, 00:00:06,
> > FastEthernet0/0
> > > > >
> > > > > r5#conf t
> > > > > Enter configuration commands, one per line. End with CNTL/Z.
> > > > > r5(config)#ip route 172.50.10.1 255.255.255.255 172.50.50.1
> > > > >
> > > > > 00:55:02: %BGP-5-ADJCHANGE: neighbor 172.50.10.1 Up bgp ev
> > > > >
> > > > > r5#sh ip bgp sum
> > > > > BGP router identifier 60.5.5.5, local AS number 55 BGP table
> > > > > version is 1, main routing table version 1
> > > > >
> > > > > Neighbor V AS MsgRcvd MsgSent TblVer InQ
> > OutQ Up/Down
> > > > > State/PfxRcd
> > > > > 172.50.10.1 4 65 5 5 1 0 0
> > 00:02:01
> > > > > 0
> > > > > r5# sh ip ro
> > > > > <snip>
> > > > >
> > > > > S 172.50.10.1/32 [1/0] via 172.50.50.1
> > > > > R* 0.0.0.0/0 [120/1] via 172.50.50.1, 00:00:13,
> > FastEthernet0/0
> > > > >
> > > > > r5#
> > > > > router bgp 55
> > > > > bgp log-neighbor-changes
> > > > > neighbor 172.50.10.1 remote-as 65
> > > > > neighbor 172.50.10.1 ebgp-multihop 2
> > > > > r1#
> > > > > router bgp 65
> > > > > bgp log-neighbor-changes
> > > > > neighbor 172.50.50.5 remote-as 55
> > > > > neighbor 172.50.50.5 ebgp-multihop 2
> > > > >
> > > > > Thank You,
> > > > >
> > > > > Dmitry Volkov
> > > > > CCIE # 10292
> > > > >
> > > > >
> > > > >
> > > > ______________________________________________________________
> > > > _________
> > > > > You are subscribed to the GroupStudy.com CCIE R&S Discussion
> > Group.
> > > > >
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > This message is for information purposes only and its content
> > > > > should not be construed as an offer, or solicitation of
> > an offer,
> > to
> > > > buy
> > > > > or sell any banking or financial instruments or
> services and no
> > > > > representation or warranty is given in respect of its
> accuracy,
> > > > > completeness or fairness. The material is subject to change
> > without
> > > > > notice. You should take your own independent tax, legal
> > and other
> > > > > professional advice in respect of the content of this message.
> > This
> > > > > message may contain confidential or legally
> privileged material
> > and
> > > > may
> > > > > not be copied, redistributed or published (in whole
> or in part)
> > > > without
> > > > > our prior written consent. This email may have been
> intercepted,
>
> > > > > partially destroyed, arrive late, incomplete or contain
> > > > viruses and no
> > > > > liability is accepted by any member of the Credit Agricole
> > Indosuez
> > > > > group as a result. If you are not the intended
> recipient of this
>
> > > > > message, please immediately notify the sender and delete
> > > > this message
> > > > > from your computer.
> > > > >
> > > > >
> > > > >
> > > > ______________________________________________________________
> > > > _________
> > > > > You are subscribed to the GroupStudy.com CCIE R&S Discussion
> > Group.
> > > > >
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > > >
> > > > >
> > > > >
> > > > ______________________________________________________________
> > > > _________
> > > > > You are subscribed to the GroupStudy.com CCIE R&S Discussion
> > Group.
> > > > >
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Aug 06 2003 - 06:52:26 GMT-3