headers
Perez, Stephane | 3 Apr 2009 16:44
Favicon

OSPF and AS External LSA

Hello guys,

I would like to raise a generic question about the OSPF AS External LSA
handling to which I have only found a workaround.

I had experienced a specific corner case with the OSPF process which can
cause some problems in some network environment.
The scenario is a firewall cluster composed of 2 firewalls using VRRP,
running. Each firewall announces a specific set of AS External routes to
the OSPF with identical parameters including the same next-hop
(VRRP-VIP) for L2 redundancy.

In this configuration both firewalls are redistributing into the OSPF
process the same external routes with the same next-hop the VRRP-VIP and
the same metric. The only difference between these LSAs is the
router-ID.

 As per OSPF standard 2328 (page 142) this will be considered as two
functionally identical LSA for each external route. To avoid effort
duplication, only the one with the highest router-id of the two LSA will
be kept into the LSDB.

Router A ---+-- Firewall A  (rid ra.rb.rc.1) --+- Network ABC
            |    vip w.x.y.z                   |
            |-- Firewall B  (rid ra.rb.rc.2) --|  

The main problem comes when the router with the router with the highest
router-id dies (Firewall B).

 At that point the following happen:
(Continue reading)

Permalink | Reply |
headers
Acee Lindem | 3 Apr 2009 17:22

Re: OSPF and AS External LSA

Stephane,

If one of the firewalls dies, the other should originate the suppressed 
As external advertisement immediately. Note the qualification 
"both reachable from one another" in the excerpted RFC 2328 text below.
If one firewal is dead, it is clearly not reachable from the other. 

   In figure 16, suppose instead that both RTA and RTB
   exchange BGP information with RTX.  In this case,
   RTA and RTB would originate the same set of AS-
   external-LSAs.  These LSAs, if they specify the same
   metric, would be functionally equivalent since they
   would specify the same destination and forwarding
   address (RTX).  This leads to a clear duplication of
   effort.  If only one of RTA or RTB originated the
   set of AS-external-LSAs, the routing would remain
   the same, and the size of the link state database
   would decrease.  However, it must be unambiguously
   defined as to which router originates the LSAs
   (otherwise neither may, or the identity of the
   originator may oscillate).  The following rule is
   thereby established: if two routers, both reachable
   from one another, originate functionally equivalent
   AS-external-LSAs (i.e., same destination, cost and
   non-zero forwarding address), then the LSA
   originated by the router having the highest OSPF
   Router ID is used.  The router having the lower OSPF
   outer ID can then flush its LSA.  Flushing an LSA
   is discussed in Section 14.1.


If you don't need to run OSPF on the VRRP LAN, a workaround may be to
advertise it as an OSPF external network to avoid it usage as a forwarding
address. 

Hope this helps,
Acee 
                                +

   
On Apr 3, 2009, at 10:44 AM, Perez, Stephane wrote:

Hello guys,

I would like to raise a generic question about the OSPF AS External LSA
handling to which I have only found a workaround.

I had experienced a specific corner case with the OSPF process which can
cause some problems in some network environment.
The scenario is a firewall cluster composed of 2 firewalls using VRRP,
running. Each firewall announces a specific set of AS External routes to
the OSPF with identical parameters including the same next-hop
(VRRP-VIP) for L2 redundancy.

In this configuration both firewalls are redistributing into the OSPF
process the same external routes with the same next-hop the VRRP-VIP and
the same metric. The only difference between these LSAs is the
router-ID.

 As per OSPF standard 2328 (page 142) this will be considered as two
functionally identical LSA for each external route. To avoid effort
duplication, only the one with the highest router-id of the two LSA will
be kept into the LSDB.


Router A ---+-- Firewall A  (rid ra.rb.rc.1) --+- Network ABC
            |    vip w.x.y.z                   |
            |-- Firewall B  (rid ra.rb.rc.2) --|  


The main problem comes when the router with the router with the highest
router-id dies (Firewall B).

 At that point the following happen:
- Firewall B is marked as unreachable after the Dead interval timer
- routes are removed from the Router A FIB
- All External LSAs from FW-B are kept in the LSDB until the LSA age
reaches the MaxAge time of 3600s
- when the External LSA is being withdrawn from the LSDB the FW-A flood
a new LSA and Djikstra is calculated again.

 In such a case this create an outage in a network for about 1 hour.
There is an easy workaround which is to redistribute the Network ABC
with a different metric from FW-A and FW-B, however this just comes back
to a duplication of effort where we will have 2 LSAs functionally
identical in the LSDB.

Premature aging seems not of any help here since the router can only age
an LSA which contains its own router-id.

I would like to have your thought about this particular case where it
can result in a 1 hour network outage.

Thanks in advance
Stephane Perez


_______________________________________________
OSPF mailing list

<div>
Stephane,<div><br></div>
<div>If one of the firewalls dies, the other should originate the suppressed&nbsp;</div>
<div>As external advertisement immediately. Note the qualification&nbsp;</div>
<div>"both reachable from one&nbsp;another" in the excerpted RFC 2328 text below.</div>
<div>If one firewal is dead, it is clearly not&nbsp;reachable from the other.&nbsp;</div>
<div><br></div>
<div>
<div>&nbsp;&nbsp;&nbsp;In figure 16, suppose instead that both RTA and RTB</div>
<div>&nbsp;&nbsp; exchange BGP information with RTX. &nbsp;In this case,</div>
<div>&nbsp;&nbsp; RTA and RTB would originate the same set of AS-</div>
<div>&nbsp;&nbsp; external-LSAs. &nbsp;These LSAs, if they specify the same</div>
<div>&nbsp;&nbsp; metric, would be functionally equivalent since they</div>
<div>&nbsp;&nbsp; would specify the same destination and forwarding</div>
<div>&nbsp;&nbsp; address (RTX). &nbsp;This leads to a clear duplication of</div>
<div>&nbsp;&nbsp; effort. &nbsp;If only one of RTA or RTB originated the</div>
<div>&nbsp;&nbsp; set of AS-external-LSAs, the routing would remain</div>
<div>&nbsp;&nbsp; the same, and the size of the link state database</div>
<div>&nbsp;&nbsp; would decrease. &nbsp;However, it must be unambiguously</div>
<div>&nbsp;&nbsp; defined as to which router originates the LSAs</div>
<div>&nbsp;&nbsp; (otherwise neither may, or the identity of the</div>
<div>&nbsp;&nbsp; originator may oscillate). &nbsp;The following rule is</div>
<div>&nbsp;&nbsp; thereby established: if two routers, both reachable</div>
<div>&nbsp;&nbsp; from one another, originate functionally equivalent</div>
<div>&nbsp;&nbsp; AS-external-LSAs (i.e., same destination, cost and</div>
<div>&nbsp;&nbsp; non-zero forwarding address), then the LSA</div>
<div>&nbsp;&nbsp; originated by the router having the highest OSPF</div>
<div>&nbsp;&nbsp; Router ID is used. &nbsp;The router having the lower OSPF</div>
<div>&nbsp;&nbsp; outer ID can then flush its LSA. &nbsp;Flushing an LSA</div>
<div>&nbsp;&nbsp; is discussed in Section 14.1.</div>
<div><br></div>
<div><br></div>
<div>If you don't need to run OSPF on the VRRP LAN, a workaround may be to</div>
<div>advertise it as an OSPF external network to avoid it usage as a forwarding</div>
<div>address.&nbsp;</div>
<div><br></div>
<div>Hope this helps,</div>
<div>Acee&nbsp;</div>
<div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;+</div>
<div><br></div>
</div>
<div>&nbsp;&nbsp;&nbsp;<br><div>
<div>On Apr 3, 2009, at 10:44 AM, Perez, Stephane wrote:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div>Hello guys,</div>
<div><br></div>
<div>I would like to raise a generic question about the OSPF AS External LSA</div>
<div>handling to which I have only found a workaround.</div>
<div><br></div>
<div>I had experienced a specific corner case with the OSPF process which can</div>
<div>cause some problems in some network environment.</div>
<div>The scenario is a firewall cluster composed of 2 firewalls using VRRP,</div>
<div>running. Each firewall announces a specific set of AS External routes to</div>
<div>the OSPF with identical parameters including the same next-hop</div>
<div>(VRRP-VIP) for L2 redundancy.</div>
<div><br></div>
<div>In this configuration both firewalls are redistributing into the OSPF</div>
<div>process the same external routes with the same next-hop the VRRP-VIP and</div>
<div>the same metric. The only difference between these LSAs is the</div>
<div>router-ID.</div>
<div><br></div>
<div>
<span class="Apple-converted-space">&nbsp;</span>As per OSPF standard 2328 (page 142) this will be considered as two</div>
<div>functionally identical LSA for each external route. To avoid effort</div>
<div>duplication, only the one with the highest router-id of the two LSA will</div>
<div>be kept into the LSDB.</div>
<div><br></div>
<div><br></div>
<div>Router A ---+-- Firewall A<span class="Apple-converted-space">&nbsp; </span>(rid ra.rb.rc.1) --+- Network ABC</div>
<div>
<span class="Apple-converted-space">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span>|<span class="Apple-converted-space">&nbsp; &nbsp; </span>vip w.x.y.z <span class="Apple-converted-space">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span>|</div>
<div>
<span class="Apple-converted-space">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span>|-- Firewall B<span class="Apple-converted-space">&nbsp; </span>(rid ra.rb.rc.2) --| <span class="Apple-converted-space">&nbsp;</span>
</div>
<div><br></div>
<div><br></div>
<div>The main problem comes when the router with the router with the highest</div>
<div>router-id dies (Firewall B).</div>
<div><br></div>
<div>
<span class="Apple-converted-space">&nbsp;</span>At that point the following happen:</div>
<div>- Firewall B is marked as unreachable after the Dead interval timer</div>
<div>- routes are removed from the Router A FIB</div>
<div>- All External LSAs from FW-B are kept in the LSDB until the LSA age</div>
<div>reaches the MaxAge time of 3600s</div>
<div>- when the External LSA is being withdrawn from the LSDB the FW-A flood</div>
<div>a new LSA and Djikstra is calculated again.</div>
<div><br></div>
<div>
<span class="Apple-converted-space">&nbsp;</span>In such a case this create an outage in a network for about 1 hour.</div>
<div>There is an easy workaround which is to redistribute the Network ABC</div>
<div>with a different metric from FW-A and FW-B, however this just comes back</div>
<div>to a duplication of effort where we will have 2 LSAs functionally</div>
<div>identical in the LSDB.</div>
<div><br></div>
<div>Premature aging seems not of any help here since the router can only age</div>
<div>an LSA which contains its own router-id.</div>
<div><br></div>
<div>I would like to have your thought about this particular case where it</div>
<div>can result in a 1 hour network outage.</div>
<div><br></div>
<div>Thanks in advance</div>
<div>Stephane Perez</div>
<div><br></div>
<div><br></div>
<div>_______________________________________________</div>
<div>OSPF mailing list</div>
<div><a href="mailto:OSPF <at> ietf.org">OSPF <at> ietf.org</a></div>
<div><a href="https://www.ietf.org/mailman/listinfo/ospf">https://www.ietf.org/mailman/listinfo/ospf</a></div> </blockquote>
</div>
<br>
</div>
</div>
Permalink | Reply |

Gmane