From: Kevin Young (kvyoung@xxxxxxxx)
Date: Sat May 13 2000 - 23:36:56 GMT-3
thanks Kevin, Jack, Mark, Kvle, I think i got it, as a summary, could i unders
tand as below:
A learns bgp routes from IBGP peer B, the bgp routes will enter into to
ute table satisfy 2 conditions. first one is A should learn the routes through
IGP, second is the next-hop address should already be in A's route table(whethe
r learned from IGP or BGP). is it correct?
----- Original Message -----
From: Kevin M. Woods <kev@nil.org>
To: JackZhang <jack@townsky.com>
Cc: Kevin Young <kvyoung@sina.com>; ccielab <ccielab@groupstudy.com>
Sent: Sunday, May 14, 2000 3:10 AM
Subject: Re: BGP question
> Jack is absolutely correct here, but I do want to clarify a couple of points.
>
> The first being that synchronization is to avoid black holes whereas AS_PATH
> is to avoid routing loops (I feel this is important to understand in order to
> make requirements such as full-mesh IBGP and such more intuitive).
>
> The second being that A will not only suppress the update from C, but it will
> not use the update in its best path selection algorithm either. This is why
> no route shows up in the routing table as Kevin discovered (I really like his
> name for some reason).
>
> But the real question is why can't A use the route? Jack pointed out that if
> a router C then forwarded traffic to A destined to B then A would discard the
> traffic. The premise is correct, but really A is not worried about itself
> discarding traffic (why should it, it has the all the information it needs
> to forward any packets to B). Instead A is worried about other routers in
> its AS that are only running an IGP discarding traffic since it sees that its
> own IGP does not have the route either. In other words, it realizes that the
> IGP is not yet "synchronized" so it suppresses the update until it does or
> synchronization is disabled. So what does "synchronized" mean: routes are
> redistributed from BGP into the IGP and and the IGP has converged.
> Convergence takes time so that is what A is waiting for. If it never happens
> then, well, I guess you lose points unless you disabled synchronization 8-).
>
> Of course there are no other routers in the topology we are discussing, but A
> has no real way of knowing that.
>
> In addition to Halabi's book (second edition on its way I hear!) I would also
> recommend RFC 1772, Appendix A for more information on this topic.
>
> Kevin
>
> // Kevin,
> //
> // The nightmare of each routing protocols is Route Looping, to avoid this, e
very routing protocol will have some methods set.
> //
> // According to BGP, if A learned the IBGP route from B (redistributed from R
IP), A will check its routing table to see if this route could be reached via o
ther IP routing protocols, if it couldn't, then A will not send this route to i
t's EBGP neighbor (assume it's C). Otherwise if C learned this route from A and
will send traffic to A, actually, A did not have route to reach the dest. The
traffic then will be discarded.
> //
> // you can call me to discuss.
> //
> // Jack
> //
> // -----Original Message-----
> // From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> // Kevin Young
> // Sent: Saturday, May 13, 2000 7:08 PM
> // To: ccielab
> // Subject: BGP question
> //
> //
> // Hi,guys, there is a question puzzled me.
> // Halabi'book said synchronization within an AS is IBGP peer check for th
e existence of the destination in the IGP,to dicide to whether announce it to o
ther EBGP peers,
> // Does it also influence the bgp route which learn from other IBGP peer ente
r into itself's route table?
> // this is the phenomenon , A and B are IBGP peer, B redistributing RIP r
outes into BGP,then B advertise the routes to A, I can see the routes in A's BG
P table, but couldn't see them in A's route table, when no synchonization in A,
the routes appear in A'route table,
> // Why? wish someone give me light ,thanks.
> //
> //
> // **************************************
> // Kevin Young
> // Senior Network Engineer
> // Yinxi Electronic Information Co.,Ltd
> // (86)-10-82625798 x 810
> // **************************************
> //
> //
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:23:29 GMT-3