SRX

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.

  • 1.  OSPF stub area not generating default route

    Posted 03-18-2014 07:09

    Background

     

    I know that you can configure an OSPF area as stub to prevent the flooding of Type 5 LSAs, and that if you use the default-metric option the ABR will generate a Type 3 LSA 0.0.0.0 that can serve as a default route to other routers in the stub area.

     

    I have this OSPF configuration on a clustered pair of SRX240H devices running Junos 11.4:

     

    area 0.0.0.1 {
      stub default-metric 1;
      area-range 172.25.128.0/23;
      interface reth0.0 {
        priority 128;
      }
    }
    area 0.0.0.0 {
      area-range 172.24.130.0/24;
      area-range 172.24.128.0/23;
      interface st0.0 {
        metric 5;
      }
      interface st0.1 {
        metric 10;
      }
    }

     

    The other router in area 1 is a Force10 Layer 3 switch. I had an issue a week ago where the SRX240s lost connectivity back to the other routers in area 0 (they are connected via the st0.0 and st0.1 interfaces, which are IPsec tunnels). When they lost connectivity, the default route the SRX240s had been flooding into area 1 was removed from the OSPF database, and all the clients connected to the Force10 switch lost connectivity to the Internet. It's worth mentioning that throughout all this the SRX240s are not just an ABR in my OSPF design, but are also ASBR, as they also have a default route installed pointing to an upstream ISP.

     

    Question

     

    Is it necessary for an OSPF stub area to maintain connectivity to area 0 in order for the ABR router to generate a default route? If so, is there a better design that will allow what are effectively two sites to maintain independent connections to upstream ISPs, but also exchange routes and network information over a point-to-point connection between the sites (which were IPsec tunnels in this case)?

     

     



  • 2.  RE: OSPF stub area not generating default route
    Best Answer

    Posted 03-18-2014 08:18

    Hello,

    "Active backbone detection" is on by default.

    http://www.juniper.net/techpubs/en_US/junos13.3/topics/concept/ospf-areas-overview.html

     

    Junos OS supports active backbone detection. Active backbone detection is implemented to verify that ABRs are connected to the backbone. If the connection to the backbone area is lost, then the routing device’s default metric is not advertised, effectively rerouting traffic through another ABR with a valid connection to the backbone.

     

    You can turn it off with

     

    [edit]
aarseniev@router# set protocols ospf no-active-backbone

     NOTE: "no-active-backbone" knob is hidden, please type it in full.

    HTH

    Thanks
    Alex



  • 3.  RE: OSPF stub area not generating default route

    Posted 03-18-2014 14:55

    Thank you! I labbed this and confirmed that it will keep the Type 3 LSA 0.0.0.0 flooding into the stub area if the ABR looses its connection to the area 0 backbone.



  • 4.  RE: OSPF stub area not generating default route

    Posted 15 days ago

    I'm here because this looked like it would solve my issues, but it did not. 
    I have a routing instance with a ospf area 1,( no back bone ) 
    Use case a is the migration of legacy infrastructure. 

    set routing-instances SUPPLIER protocols ospf area 0.0.0.1 stub default-metric 10
    set routing-instances SUPPLIER protocols ospf area 0.0.0.1 interface ae0.1234 interface-type p2p
    set routing-instances SUPPLIER protocols ospf no-active-backbone

    this did NOT result in area 1 getting 0/0 route.
    I was forced to bring up a loopback in area 0

    set ospf area 0.0.0.0 interface lo0.123

    maybe the no-active-backbone does not work in a routing instance. 



    ------------------------------
    JNCIE-ENT 907
    ------------------------------

    Original Message


  • 5.  RE: OSPF stub area not generating default route

    Posted 15 days ago

    If you ask me the default loopback will get you

    your default Route. That loopback already has the 16384-5, and 32768 interfaces. Those are

    already set for ospf. Your backbone is your

    own. External? You bet.



    ------------------------------
    Adrian Aguinaga
    B.S.C.M. I.T.T. Tech
    (Construction Management)
    A.A.S. I.T.T. Tech
    (Drafting & Design)
    ------------------------------

    Original Message


  • 6.  RE: OSPF stub area not generating default route

    Posted 15 days ago

    Hi 
    so my scenario, is A new core network, based on BGP lots of VRFs, 
    I'm migrating a legacy service onto the new network 
    the legacy network was Traditional OSPF area1 area 0 etc.

    I'm migrating this Stub area 1 to the new core. 
    so it will be BGP <> OSPF area1 ( stub ) 
    this should be doable without too much reconfiguration of the legacy connection ( which involves other organisations so hard work )  
    Legacy area 1 only really requires a default route. 
    But being a stub, I cannot redistribute the BGP > OSPF
    so generating a default route looks like the best solution, but certainly, in my EVE-NG it just does not work 
    I looks like the Backbone connectivity detection but 
    no-active-backbone
    did not make it work. 
    Adding a loopback to area0 brought up area0 and the ABR started advertising a default. 
    But I in  my mind this is to messy now. 
    I think I will convert the area to a non-stub area. 



    ------------------------------
    JNCIE-ENT 907
    ------------------------------

    Original Message


  • 7.  RE: OSPF stub area not generating default route

    Posted 15 days ago

    Perhaps it would help you to exactify the

    traffic in terms of protocol that is allowable

    to the backbone in the 16384-85(I'm not

    remembering which at the moment)

    interface, so that you can only allow those

    in your lo0.123 interface. Perhaps that is

    whats stopping you. 10.0.0.6 or whatever

    address it assigns. Maybe then it will

    start advertising. The SRX lives by the

    rule on those interfaces.



    ------------------------------
    Adrian Aguinaga
    B.S.C.M. I.T.T. Tech
    (Construction Management)
    A.A.S. I.T.T. Tech
    (Drafting & Design)
    ------------------------------

    Original Message