Hi,
I am looking for some clarification on BGP internal update process as
stated in section 9.2.1 of rfc 1771. To illustrate my point let me
explain using the example given below.
According to rfc 1771 an internal update should be sent to internal
peers as part of phase 1 itself i.e. before start of phase 2.
(x3)
----------C-----------
IBGP| AS I |IBGP
| |
| | EBGP
A---------------------B------------M (x2)
/AS I IBGP AS I \ AS IV
/ \
/EBGP \EBGP
/ \
H K (x1)
AS II AS III
1. A, B and C are IBGP peers.
2. H is an EBGP peer of A.
3. K and M are EBGP peers of B.
Consider the following scenario in which a bgp speaker, say B, has three
updates for same destination x in its Adj-RIBs-IN viz x1, x2 and x3 with
degree of preference d1, d2 and d3 such that d3 >d2 >d1. Lets suppose
that
1. Local system B does not have Next hop reachability for destination
x2 in its Loc-RIB.
2. x3 is originated by one of the internal peers, say C.
3. x1 and x2 are sent by external peers K and M, respectively.
According to decision process of rfc1771, x3 having larger DOP, will be
installed in Loc-RIB of B as best phase 2 route.
Now my questions are :
a) Will there ever be a situation when a BGP speaker (B) receive a route
(x2) through an EBGP update for which there is no NH reachablity in
its Loc_RIB.
One way this could happen is if the sending speaker (M) sets some
policy for next hop then it may be possible for receiving speaker
(B) to not have NH reachability in its Loc-RIB.
But then section 5.1.3 of <draft-ietf-idr-bgp4-12.txt> says
When advertising a NEXT_HOP attribute to an external peer, a
router may use one of its own interface addresses in the NEXT_HOP
attribute provided the external peer to which the route is
being advertised shares a common subnet with the NEXT_HOP address.
This is known as a "first party" NEXT_HOP attribute. A BGP
speaker can advertise to an external peer an interface of any
internal peer router in the NEXT_HOP attribute provided the
external peer to which the route is being advertised shares a
common subnet with the NEXT_HOP address. This is known as a
"third party" NEXT_HOP attribute.
What I understand from this is, a bgp speaker (M) can only set
some policy to change the NH of an update message to one of
its interface address provided that the receiving external
peer (B) shares a common subnet with that address.
I would appreciate if someone can enlighten this with a practical
scenario when such a thing can happen.
b) What routes should be there in Adj-RIBs-IN of internal peer A.
1. x3 and x2.
x3 from C and x2 from B as it is the best route to send to internal
peers according to section 9.2.1 of rfc 1771 having larger value of
DOP among externally received route.
2. x3 and x1. (If the answer to (a) is NO ).
But its nowhere written in rfc 1771 or in draft that an external
route for which next hop reachability is not there, should not be
sent to internal peers.
3. x3 alone.
As it is the route which will be selected after phase 2 to be put
in Loc-RIB of B, therefore B should withdraw the route x2 (or
x1, whichever it has advertised earlier to A as part of internal
update process) as according section 9.2.1 of draft:
"When a BGP speaker receives a new route from an external peer, it
MUST advertise that route to all other internal peers by means of
an UPDATE message if this route will be installed in its Loc-RIB
according to the route selection rules in 9.1.2."
This means that only those route should be sent to internal peers
which *will* be there in Loc-RIB after phase 2.
===================================================================
The point of concern is, if the necessary condition for a route to
be advertised to internal peers is that it should be present in
Loc-RIB, then why rfc and draft both say that internal update can be
sent (at the end/as part of) phase 1.
It appears that if the above is necessary condition then internal
updates should be sent after phase 2 i.e. when Loc-RIB has been
modified. Whats the point in first sending the update after phase 1
and then withdrawing it if that route is not there in Loc-RIB.
===================================================================
NOTE: where ever I have given reference for draft, I
meant
<draft-ietf-idr-bgp4-12.txt>
Regards,
Deepak Srivastava
--
---------------------------------------------------------------------------------
DEEPAK SRIVASTAVA ds113(_at_)ascend(_dot_)com
Infosys- India Development Team Phone Office: 91-80-8520261
Bangalore -INDIA Extn: 6522
--------------------------------------------------------------------------------