[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] BGP path hunting, MRAI timer and Path Length Damping
BGP is a complex system and I don't pretend to be an expert.
That doesn't stop me trying to understand patterns of behavior.
Assuming for the moment that my analysis of Geoff's Fig 1
scenario is correct, here is what happens if that Fig 1 pattern:
|
|
(5)
/ | \
/ | \
/ | \
(2)--(3)--(4)
|
|
(1)
is plugged into another such structure with routers in ASes 6 to 9:
(10) (11) (12)
\ | /
\ | /
\ | /
(9)
/ | \
/ | \
/ | \
(6)--(7)--(8)
|
|
(5)
/ | \
/ | \
/ | \
(2)--(3)--(4)
|
|
(1)
As before, each router is in its own autonomous system and the
same principles probably apply in general to many meshed
networks with more realistic arrangements of routers, such as
two or more routers in the same AS instead of just one as shown
above.
The upstream peers (10), (11) and (12) all get this sequence
from (9):
T = 0.4 sec AA+ "9, 6, 5, 3, 2, 1" replacing:
"9, 6, 5, 2, 1".
T = 30.4 sec AA+ "9, 7, 6, 5, 3, 2, 1".
T = 60.4 sec Withdrawal.
Assuming my analysis is correct, and going on gut feel from
there, I would say that generally any meshed pattern of routers
will probably do much the same thing. It propagates AA+
messages at MRAI intervals and finally a withdrawal. The number
of AA+ messages probably depends on how many pairs of detours
and bottlenecks there are in the system.
I haven't checked, but I think this should generate four AA+
messages followed by a withdrawal, 120 seconds later than it
should have been propagated:
(2) (3) (9) (12) /
/ \ / \ / \ / \ / Upstream
/ \ / \ / \ / \ / routers
(1)---(3)---(4)---(6)---(8)--(10)---(11)-(13)----
|
X
|
(0)
If the RFC's text:
http://tools.ietf.org/html/rfc4271#section-9.2.1.1
Two UPDATE messages sent by a BGP speaker to a peer that
advertise feasible routes and/or withdrawal of unfeasible
routes to some common set of destinations MUST be separated
by at least MinRouteAdvertisementIntervalTimer.
was extended to include 6 extra words:
unless the second UPDATE is a withdrawal.
then the withdrawals would not be delayed by 30 seconds for each
stage of 4-stage the pattern above.
Then, maybe we wouldn't be so unhappy about BGP's convergence
rate and the number of messages - which are two of the primary
reasons we are having to invent a new routing and addressing
architecture.
Maybe if the sentence was changed, to:
An UPDATE message sent by a BGP speaker to a peer that
advertises a longer feasible route than previously
announced to that peer for a common set of destinations MUST
be separated by at least MinRouteAdvertisementIntervalTimer
from the any previous UPDATE message for that common set.
If such a message is delayed by this timer while a new
UPDATE message for the common set would otherwise be
sent, advertising a still longer feasible route, then
the delayed message is replaced by the new message and
the timer restarted.
This would let through withdrawals, shorter best path and
same-length best path messages without any delay, though perhaps
it would be best to delay any same-length messages too.
My working of the problem is below.
- Robin
The lower system's output, from (5) is:
T = 0.2 sec AA+ longer path announcement: "5, 3, 2, 1"
T = 30.2 sec Withdrawal.
Here is what I think occurs.
T = 0.3 sec
(6), having received the above AA+ announcement, announces
to (9) and (7) another AA+:
"6, 5, 3, 2, 1". Previously it had announced
"6, 5, 2, 1".
(6) sets its MRAI timer to expire at 30.3 seconds.
T = 0.4 sec
! (9), having received the above AA+ announcement, announces
! to its upstream peers (10), (11) and (12) another A++:
"9, 6, 5, 3, 2, 1". Previously it had announced:
"9, 6, 5, 2, 1".
(9) sets its MRAI timer to expire at 30.4 seconds.
(7) also sets its MRAI timer to expire at 30.4 seconds and
announces a similar A++:
"7, 6, 5, 3, 2, 1". Previously it had announced:
"7, 6, 5, 2, 1".
T = 0.5 sec
(9) receives (7)'s AA+ but this doesn't alter (9)'s
best path.
(8) receives it as well, and this does alter its best path.
It sets its MRAI timer to expire at 30.5 seconds and
announces to (9):
"8, 7, 6, 5, 3, 2, 1". Previously it had announced:
"8, 7, 6, 5, 2, 1".
T = 0.6 sec
(9) receives (8)'s AA+ but this doesn't alter (9)'s
best path.
T = 30.2 sec
(5) announces the withdrawal to (6).
T = 30.3 sec
(6) receives this withdrawal and its RIB is updated to the
drop packets addressed to this prefix.
The MRAI timer expires at this time, so (6) announces a
withdrawal to (9) and (7).
T = 30.4 sec
(9) receives the withdrawal and changes its RIB to have a
new longer path. Its MRAI timer expires at this time, and
! so it announces its new best path AA+ to its upstream peers:
! "9, 7, 6, 5, 3, 2, 1". Previously it had been:
"9, 6, 5, 3, 2, 1".
(9) configures its FIB to forward this prefix to (7) instead
of (6).
(9) sets its MRAI timer to expire at T = 60.4 seconds.
(7) receives this withdrawal and changes its FIB to drop
packets to this prefix.
(7) announces a withdrawal to (9) and (8), and sets its
MRAI timer to expire at 60.4 seconds.
T = 30.5 sec
(9) receives this withdrawal from (7) and updates its best
path to be via (8):
"9, 8, 7, 6, 5, 3, 2, 1". Previously (0.1s) it had been:
"9, 7, 6, 5, 3, 2, 1".
(9) configures its FIB to forward this prefix to (8) instead
of (7).
(9) does not announce anything, because the MRAI timer has
not yet expired.
(8) also receives the withdrawal from (7) and so announces
a withdrawal to (9). (8) also configures its FIB to drop
packets addressed to this prefix.
T = 30.6 sec
(9) receives the withdrawal from (8) and updates its RIB
to have no best path for the prefix. It updates its FIB
to drop packets addressed to this prefix.
It does not announce anything, because its MRAI timer is
still running.
T = 60.4 sec
! (9)'s MRAI timer expires, so it announces the withdrawal
! to its upstream peers.
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg