Subject: [OSPF] OSPF and AS External LSA

From: "Perez, Stephane" <[email-masked]>
Date: Fri, 3 Apr 2009 10:44:28 -0400

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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 3 Apr 2009 11:22:12 -0400

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:

> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf