SRX

Hi all,

I have a couple of sites, looking as the attached picture. All Sites #1-7 are currently connected to Datacenter #1 via route based VPN and working good. We are about to add a second domain server at our second datacenter. To acheive better routing and redundancy I want to run OSPF over the IPSec tunnels. I have that setup working in a lab environment, I however need help with two issues regarding that setup:

1. I don't want full OSPF area 0.0.0.0 the be distributed to the sites since they can't ever be used for passing transit traffic between the datacenters. As of now the number of hops between 192.168.132/24 and 192.168.172/24 is actually shorter via one of the sites compared to the backbone via the EX4500's. I figure I need to put the Sites in a different area (not 0.0.0.0) and somehow control what routes are being distributed intra-area. The current static routing installs a route 192.168/16 on the Sites and sends it to the SRX650, the SRX650 in turn send the Site's /22 to the st0.X interface and redistribute the route in area 0.0.0.0. I want to achive the very same thing with OSPF to enable redundancy.

2. To keep number of routes down, I would like to configure route aggregation and make sure the four (three in use, one reserved) /24's on the Sites are announced into OSPF area 0.0.0.0 as a /22. Is it adviceable to do this on the Site's firewalls or on the area border routers at the datacenters?

Thanks in advance!

Hi GustavO,

First of all - cool setup 🙂

To answer your questions:

1. Good idea - create area 0.0.0.1 on the SRX650s and place all the st0.x interfaces into the area.  Just make sure that you watch route selection  - your SRX650s will learn about your branches from area 1 as well as area 0 (from each other), so depending on whether your branch subnets are exported as type 1 or type 2 externals, you may get different results (they won't be intra-area routes because you'll only be advertising an aggregate, which will need to be exported).

2. It is usually best to aggregate as close as possible to the source of the route as you can, so in your case I would definitely do it on the site SRXs, rather than the core.  I'm assuming that the site SRXs are the gateways for each of those subnets, so the likelihood of only one of any site's subnets becoming unavailable via one WAN link should be minimal.

Thanks for your input and praise Ben!

I created a new area 0.0.0.1 and put the test-branch and attached st0.X interfaces at the hubs to it. I also created an aggregate route at the branch and exported it to ospf via policy. However I've realized it's probably a bit more difficult to get this to behave the way I want it to than I first realized:

- I don't want 0/0 distributed from the hubs, that traffic should go out NAT:ed via the local ISP
- I need more specific routes than the single 192.168/16 from the hubs to the spokes since I want traffic to each domain controller/dns to go the shortest/direct path.
- The branch-generated aggregate for the /22 from each branch won't get distributed unless area 0.0.0.1 is either nssa or "normal" area.
- I don't ever want routes in/from area 0.0.0.0 to be routed via area 0.0.0.1 (I though this was implied when you used different areas but realize that's not the case).
- Using area-range at the hub give's undesired results; the /24's from area 0.0.0.1 are installed in the routing table at the hub and the /22 is redistributed in area 0.0.0.0, this however gives an inconsistent view on routers in area 0.0.0.0. So route aggregation at the branch is, just as you pointed out, what I want to go with.

I think it would work the way I want it to if i could get everything from area 0.0.0.0 exported to 0.0.0.1 but only local (the /22 aggregate) announced from the branch to the hub but i realize i need a consistent LSDB accross the area and that won't do it. Current thinking is I probably need to separate the branches from the rest of the network by

I've drawn a more detailed diagram also showing the routes (not including ptp's and loopbacks for brevity) the way I'd like them distributed. There are some additional subnets originating from the ex's also, I left them out of the original diagram since I don't think they change the outcome, but added them now just to be sure.

Hi Gustav,

To address each of your problems:

- I don't want 0/0 distributed from the hubs, that traffic should go out NAT:ed via the local ISP

That's fine - your static default routes at each branch will override anything that OSPF advertises to you.  Just make sure you have a static host route to the VPN head-end IPs to ensure you don't accidently advertise something more specific that tears down the tunnel.  

- I need more specific routes than the single 192.168/16 from the hubs to the spokes since I want traffic to each domain controller/dns to go the shortest/direct path.

This will be default behaviour if you configure area 1 as a NSSA.  Just make sure you don't override this behaviour with the default-metric or no-summaries statements. 

- The branch-generated aggregate for the /22 from each branch won't get distributed unless area 0.0.0.1 is either nssa or "normal" area.

Correct - you want an NSSA though because the aggregate will be considered external (i'm assuming you mean you've created a route with protocol aggregate here)

- I don't ever want routes in/from area 0.0.0.0 to be routed via area 0.0.0.1 (I though this was implied when you used different areas but realize that's not the case).

Intra-area routes should be preferred over Inter-Area, but you'll just need to watch your branch aggregates (because they will be External) and which ABR gets used to reach them (eg: DC2 might go via DC1 to get to a branch in certain situations)

- Using area-range at the hub give's undesired results; the /24's from area 0.0.0.1 are installed in the routing table at the hub and the /22 is redistributed in area 0.0.0.0, this however gives an inconsistent view on routers in area 0.0.0.0. So route aggregation at the branch is, just as you pointed out, what I want to go with.

Yes - which is why an NSSA with external aggregates will solve this for you.

Good luck!

Thanks a lot for you input Ben!

I thought I'd share the resulting config with the rest of the forum.

These are the relevant (with regards to the routing) parts of the configuration for hub #1. The second hub looks the same as the one below but uses the 10.11.14/24 subnet for its NHTB subnet on the st0.9. The branches and their ipsec vpn's on the hub set bind-interface to st0.9.

interfaces {
    lo0 {
        unit 0 {
            family inet {
                address 127.0.0.1/32;
                address 10.11.12.1/32 {
                    primary;
                }
            }
        }
    }
    st0 {
        unit 9 {
            description "VPN NHTB Interface to branches";
            multipoint;
            family inet {
                address 10.11.15.1/24;
            }
        }
    }
    vlan {
        unit 58 {
            description "Inside interface";
            family inet {
                address 10.11.13.49/29;
            }
        }
    }
}

protocols {
    ospf {
        area 0.0.0.0 {
            interface lo0.0 {
                passive;
            }
            interface vlan.58;
        }
        area 0.0.0.1 {
            nssa;
            interface st0.9;
        }
    }
}

 And the relevant parts for one of the spoke sites:

interfaces {
    lo0 {
        unit 0 {
            family inet {
                filter {
                    input protect-re;
                }
                address 127.0.0.1/32;
                address 10.11.12.21/32 {
                    primary;
                }
            }
        }
    }
    st0 {
        unit 0 {
            description "VPN to hub #1";
            family inet {
                address 10.11.15.12/24;
            }
        }
        unit 1 {
            description "VPN to hub #2";
            family inet {
                address 10.11.14.12/24;
            }
        }
    }
}

routing-options {
    aggregate {
        route 192.168.164.0/22;
    }
    router-id 10.11.12.21;
}

protocols {
    ospf {
        export site-export;
        area 0.0.0.1 {
            nssa;
            interface lo0.0 {
                passive;
            }
            interface st0.1;
            interface st0.0;
        }
    }
}
policy-options {
    policy-statement site-export {
        term site_subnet {
            from {
                protocol aggregate;
                route-filter 192.168.164.0/22 exact;
            }
            then accept;
        }
    }
}