re: Pervasive BGP and routing loops.

[[e-mail]]

Radha Gowda <[e-mail]> describes a scenario

>          AS 1             AS 2
> 	  -----            -----
>         | 1 | -----/---- | 2 |
>         -----            -----
>           \                /
> -----------\--------------/-----------
>             /            \      AS 3
>              \          /
>             -----     -----
>             | 4 |--/--| 3 |
>             -----     -----
>                  IBGP
>
>  R1 starts advertising route to 128.185.128.0/17 
>  Both R3 and R4 now have two paths to get to 128.185.128.0/17, and the
>  best one happens to be via R4.

Well, let's look at this. How did each of them learn 2 paths?

  - R4 learns about the route from R1, and sends the R1 path to R3
  - R3 learns about the route from R2, and sends the R2 path to R4

But if R3 decides the "best route" is via R4, then shouldn't it send an
UNREACHABLE update to R4 ? In other words, if I advertise path X to any
route R, and I then learn a better path Y to route R, then I forward the
new path as a replacement OR (in this case, because of your stricture not
to reflect routes back to the advertiser) I should send an UNREACHABLE.

In other words if a route is advertiseable, it must also be un-advertiseable.

In your scenario, R3 advertises a path to a route which it does not revoke,
even though R3 itself stops using that path. Not good BGP, in my opinion.

>  R1 reboots with a changed policy, and starts advertising 128.185.0.0/16

Irrelevant, really. R1 could come back as before. The scenario is the same.

>  During which time (when the connection to R1 is lost) R4 thinks that 
>  it can get to 128.185.128.0/17 via R3.
>  R3 thinks it can get to 128.185.128.0/17 via R4.
>  Both R3 and R4 end up pointing to each other as the next hop to get
>  to route 128.185.128.0/17.  Neither advertises this new path
>  information to the other as the paths learnt from IBGP speakers are 
>  not to be advertised back to the sender.  

If R3 had done its job correctly, it would receive an UNREACHABLE from R4.
This would cause the earlier path via R2 to be reinstated, and then R3
advertises the R2 path to R4. So no loop would exist.

============================

Now, a loop COULD occur (for a short time) when the "best path" from R4 is
direct to R1, while the "best path" from R3 is via R2. Now, you have two
competitive routes simultaneously. When R1 goes down, R4 detects this and
invalidates the direct path to R1, and switches to the "backup path" via
R3. Then assume at the same time, R3 receives an unreachable from R2, so
it switches to its backup via R4 ... bingo, routing loop.

However, the loop disappears during the next UPDATE cycle -- which can be
quite soon, depending on the implementation and policy.

( BTW, the picture doesn't depict it, but I assume the route is "behind"
  R1, and not directly reachable via R2. )

Any comments? Does this seem reasonable, or am I missing something?

Tim O'Connor