From: Brian McGahan (brian@cyscoexpert.com)
Date: Wed Oct 23 2002 - 18:55:52 GMT-3
Mark,
BGP backdoor is used to raise the distance of an EBGP learned
prefix to 200, and then not advertise it to any iBGP neighbor.
Theoretically, BGP backdoor should work in this case, however it does
not (at least in 12.1, I haven't tested this in other versions). The
order in which the BGP process is handling the attributes is most likely
the culprit.
The problem you are having is called BGP race condition. BGP
race condition exists when BGP depends on itself for connectivity. Do
not think of BGP as a routing protocol, think of it instead as a
reachability protocol. It is not possible to route your network with
just BGP (without a full physical mesh). IGP always has to be used for
TCP transport.
In your case, the BGP peering session between these two routers
is based off of the address 137.20.200.18. This prefix is being
advertised both via OSPF and via BGP. When the prefix 137.20.200.16/28
is first learned via OSPF, TCP transport is established for the BGP
session, and the BGP peering comes up. After the BGP peering is
established, the prefix is advertised into the BGP domain. Since this
prefix 137.20.200.16/28 is now received via EBGP with a distance of 20,
it preempts the OSPF route with a distance of 110, and is installed into
the IP routing table as a BGP route. BGP is now depending on itself for
transport, hence the error in recursion.
Instead of using BGP backdoor to solve this, just change the
distance manually. Either raise the distance of the BGP prefix to at
least 111, or lower the OSPF prefix to at most 19. Take the following
example:
Access-list 1 permit host 137.20.200.16
!
router bgp 1
distance 111 0.0.0.0 255.255.255.255 1
!
This syntax means: change the distance to 111 for the prefix
137.20.200.16 learned from any neighbor.
The distance syntax is:
Distance [ad] [neighbor_address] [neighbor_wildcard] [ACL]
Neighbor_address matches the "from" field shown in the route lookup.
This is a different value depending on which protocol you are referring
to.
Rack8R4#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "isis", distance 115, metric 10, candidate default path,
type level-1
Redistributing via isis
Last update from 155.8.14.1 on Serial1, 02:01:38 ago
Routing Descriptor Blocks:
* 155.8.14.1, from 155.8.14.1, via Serial1 <------neighbor_address
Route metric is 10, traffic share count is 1
In this case, the neighbor we are learning this prefix from is
155.6.14.1, as seen in the field "from 155.8.14.1, via..." This value
is not always the interface address associated with the protocol
peering.
Neighbor_wildcard is a wildcard pair that specifies which bits are
significant of the neighbor_address.
Distance 111 1.2.3.4 0.0.0.0 1
! learned from 1.2.3.4 only
Distance 111 0.0.0.0 255.255.255.255 1
! learned from any neighbor
ACL matches the prefix for which you are changing the distance.
Note: changing distance on a per prefix basis works for all protocols
except external EIGRP.
HTH
Brian McGahan, CCIE #8593
Director of Design and Implementation
brian@cyscoexpert.com
CyscoExpert Corporation
Internetwork Consulting & Training
Voice: 847.674.3392
Fax: 847.674.2625
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Mark
> Sent: Wednesday, October 23, 2002 9:41 AM
> To: ccielab@groupstudy.com
> Subject: Re: BGP backdoor and routing loops
>
> just test lab scenario - if my understanding of backdoor was right
then
> I'd
> not have this problem.
>
> Mark
>
>
> ----- Original Message -----
> From: <carl.newman@elynxtech.com>
> To: <ms6275@yahoo.de>
> Sent: Wednesday, October 23, 2002 3:12 PM
> Subject: RE: BGP backdoor and routing loops
>
>
> Mark:
>
> Looks like to me that you would want to peer off a loop back interface
in
> order to not create the loop. This looks like a double T1 install to
me.
> You should peer off of the ISP's Loop Back and not the connected
> interface.
>
> Carl
>
> -----Original Message-----
> From: Mark [mailto:ms6275@yahoo.de]
> Sent: Wednesday, October 23, 2002 8:13 AM
> To: ccielab@groupstudy.com
> Subject: BGP backdoor and routing loops
>
> If I use backdoor then the EBGP route should never defeat the IGRP
routing
> by
> my understanding.
>
> R3 has 8 meg flash hence
> IOS (tm) 2500 Software (C2500-INS-L), Version 12.0(23), RELEASE
SOFTWARE
> (fc1)
>
> Other peers
> IOS (tm) 2500 Software (C2500-JOS56I-L), Version 12.1(17), RELEASE
> SOFTWARE
> (fc1)
>
> router bgp 65000
> network 137.20.200.16 backdoor
> network 137.20.200.18 backdoor
> redistribute static
> neighbor 137.20.200.18 remote-as 4
> neighbor 137.20.200.18 ebgp-multihop 2
>
> 04:16:48: RT: recursion error routing 137.20.200.18 - probable routing
> loop
> 04:16:48: RT: recursion error routing 137.20.200.18 - probable routing
> loop
>
> I would like to see this all the time
>
> r3#i 137.20.200.16
> Routing entry for 137.20.200.16/28
> Known via "ospf 1", distance 110, metric 164, type extern 1
> Redistributing via ospf 1
> Last update from 137.20.100.34 on Serial0, 00:00:12 ago
> Routing Descriptor Blocks:
> * 137.20.100.34, from 137.20.100.34, 00:00:12 ago, via Serial0
> Route metric is 164, traffic share count is 1
>
> But
> r3#i 137.20.200.16
> Routing entry for 137.20.200.16/28
> Known via "bgp 65000", distance 20, metric 0
> Tag 4, type external
> Last update from 137.20.200.18 00:00:06 ago
> Routing Descriptor Blocks:
> * 137.20.200.18, from 137.20.200.18, 00:00:06 ago
> Route metric is 0, traffic share count is 1
> AS Hops 2
>
>
>
http://127.0.0.1:8080/cc/td/doc/product/software/ios122/122cgcr/fiprrp_r
/b
> gp
> _r
> /1rfbgp2.htm#xtocid15
>
> __________________________________________________________________
>
> Gesendet von Yahoo! Mail - http://mail.yahoo.de
> Mvchten Sie mit einem Gru_ antworten? http://grusskarten.yahoo.de
>
> __________________________________________________________________
>
> Gesendet von Yahoo! Mail - http://mail.yahoo.de
> Yahoo! prdsentiert als offizieller Sponsor das Fu_ball-Highlight des
> Jahres: - http://www.FIFAworldcup.com
This archive was generated by hypermail 2.1.4 : Tue Nov 05 2002 - 08:35:54 GMT-3