Couple comments inserted below
*********** REPLY SEPARATOR ***********
On 2/20/2001 at 11:55 AM Ahmed Aden wrote:
>Scott,
>
>I think the problem is with you putting 'no synchronization' in
>router1. I would also say that if you did a ping to 33.33.33.1 from
>router2 it would work because the 192 net is reachable from router2. When
>you issue a 'no synchronization' you are saying that if this route is
>being announced to me via an IBGP peer, I will install it into the
>routing
>table regardless. Keep in mind it will go into the routing
>table without any
>knowledge of whether the next-hop address is reachable.
This last sentence is actually not true. A BGP router will never install a prefix
into the routing table that it cannot resolve a route to the next_hop for. There is
no way to turn this feature off as doing so would very likely create huge black holes.
>From RFC 1771
"If the NEXT_HOP attribute of a BGP route depicts an address to which
the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
route SHOULD be excluded from the Phase 2 decision function."
Note: Phase two involves route selection and routes that do not meet phase two
criteria are dropped.
Synchronization in my opinion seems often misunderstood. Essentially, this feature is
relevant when a transit AS (one that passes traffic for which it is neither the source
nor destination) chooses not to use a full iBGP mesh. Hence, if routers a,b,c, and d
were connected in series, consider that only A and D are IBGP peers and are providing
transit between multiple ISPs. For this to work, an IGP would have to have full
prefix awareness, or said another way, the IGP table and the BGP tables would need to
contain the same routes. Hence, it could be said that the tables would need to be
synchronized. For protection, the BGP routers will not advertise a prefix outbound
via EBGP to other AS's until their internal IGP table has the prefix installed. This
means that likely the other IGP routers in the domain also have the prefix and thus
traffic will not be black holed.
In practise, no one does this! Redistributing 100k routes into an IGP is not a good
thing :) All transit provides fully mesh with IBGP (with the exception of traffic
engineered cores over MPLS) Synchronization is thus always turned off. In fact,
Juniper does not even offer a synchronization nob.
You would need an
>IGP or static routes to ensure that all next-hop
>addresses are reachable from all IBGP peers. It's your responsibility to
>verify that a next-hop route exists for every bgp route.
In practise, the next_hop self method, or adding the external links as passive
OSPF/IS-IS interfaces are the common methods for this procedure. Statics simply
involve too much work.
>
>> This is my confusion: I was under the impression that routes do not
>> get installed into routing tables if there is no route for the next-hop
>> address. Specifically, since R1 does not know how to get to
>> 192.1.1.1, the 33.33.33.0 route should not get installed.
>
>You have described the normal behavior, but you have also overridden this
>behavior with 'no synchronization'.
Again, this is not the case. As far as the problem goes, lets see the full routing
table on R2 and R1 along with the BGP summaries.. This would help. Somehow, R1 is
finding a route to 192.1.1.1.
-pete
>hope this helps,
>
>
>On Tue, 20 Feb 2001, scott wrote:
>
>> Hello all - I may have been working on this too long. Take a look
>> at the following network.
>>
>> AS100 iBGP AS100
>> 22.22.22.0 11.11.11.0
>> R2-173.4.175.19------173.4.175.17-R1 <synchronization turned
>>
>>
>> 192.1.1.2
>> off on R1 and R2
>> |
>> |
>> | eBGP
>> |
>> |
>> |
>> 192.1.1.1
>> R3
>> AS300
>> |
>> 33.33.33.0
>>
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
