Expand all | Collapse all

OSPF nssa multi-WAN

Jump to Best Answer
  • 1.  OSPF nssa multi-WAN

    Posted 10-11-2017 06:39

    Dear all,


    Our network has a number of MAN-type switched segments for customer access, routed core with no customer access, ospf area zero is the core and the nssa areas align with the MANs.


    I'm trying to build a config on a CPE running JunOS that will ideally :


    1. Connect to two different MANs on two assigned WAN ports.
    2. Run OSPF on both WANs (so two nssa areas) advertising the direct prefix on the third (assigned LAN) port.
    3. Not connect directly to the core, so will not be adjacent to or connect to area zero.


    So far, I have OSPF adjacency to the two MANs on the two nssa's, I'm seeing routes from each area, export policy allows ONLY the export of the designated customer prefix (and the LSAs onthe running interfaces). That all seems to be working.


    The problem is, despite the default routes being in the ospf database, they are not installed in the routing table :

    root@*****# run show ospf database nssa                        
        OSPF database, Area
     Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
    NSSA          10.x.y.144     0x800028ac  2545  0x20 0x61c2  36
    NSSA          10.x.y.153     0x800013c2  1012  0x20 0x20fc  36
        OSPF database, Area
     Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
    NSSA          10.x.y.143     0x80003677  1074  0x20 0x89c5  36
    NSSA          10.x.y.151     0x800013da  1732  0x20 0xfb0b  36
    root@*****# run show route 0

    As soon as I take one of the adjancencies down, the default route for the other area is installed.


    I'm thinking this is because this device isn't adjacent to area zero. I don't need (in fact would design against) communication between the two areas in question, one is primary, the other is failover.


    I was just wondering if someone could tell me whether this would be the expected behaviour? If it is I can work around using bgp to install default route, I just prefer to keep things simple if this can be handled with some kind of special case policy or config...


    Thanks, folks, in advance for any trouble taken!

  • 2.  RE: OSPF nssa multi-WAN
    Best Answer

    Posted 10-11-2017 11:36


    Short answer - this is expected NSSA border router behaviour in conjunction with Type-7 default route.

    Long answer - You are into one of many peculiarities of OSPF NSSA. According to RFC 3101 section 2.4:


    A Type-7 default LSA for the network may be originated into
       the NSSA by any NSSA router.  The Type-7 default LSA originated by an
       NSSA border router must have the P-bit clear.

    When You configure two NSSA areas in Your CPE, You make it a NSSA ABR.  The NSSA ABR must not install routes with P-bit clear as per RFC 3101 section 2.5:


    if the destination is a Type-7 default route (destination
              ID = DefaultDestination) and one of the following is true,
              then do nothing with this LSA and consider the next in the
    The calculating router is a border router and the LSA has  its P-bit clear.

     And when You bring down one of the links, then Your CPE stops becoming an NSSA ABR and happily installs the remaining 0/0 route.

    AFAIK, JUNOS does not have a knob to override this behavior.

    You have 3 choices here:

    1/ reconfigure Your MANs+CPE to use identical NSSA area on both links

    2/ reconfigure MAN routers to send a Type-3 0/0 route into Your NSSA areas/to Your CPE.

    3/ reconfigure Your CPE to use 2 different routing-instances for 2 links to MANs.

    Finally, I strongly recommend NOT to use OSPF as PE-CE protocol at all, and this of course includes OSPF NSSA.

    BGP is much less complex and far more flexible. JUNOS supports both eBGP and iBGP as PE-CE protocol. 

    You can use BFD with BGP to achieve very short timers not possible with OSPF.




  • 3.  RE: OSPF nssa multi-WAN

    Posted 10-12-2017 01:46

    Thanks for the comprehensive and swift reply Alex, kudos to you!


    Unfortunately same MAN is not an acceptable solution as one of the design goals is MAN redundancy, so the two WAN connections MUST be on different MANs.


    Option 1 is interesting, I might spend some (short) amount of time trying to fudge that.


    I agree with you by the way, OSPF wasn't the first choice, we actually had the solution working with iBGP/BFD for accceptable convergence times, unfortunately, the switches with in the MAN are actually "swouting", so need to be able to route to the CPE, and they're not running BGP, so the only option I have is OSPF.


    I might instead use iBGP to get the default route across, then when we do start running bgp in the MAN (it's in the roadmap) the solution will move transparently...


    Thanks again Alex, Kind regards,