Routing
Routing

Two DC connected L2 and OSPF over IPSec VPN from Branch Offices.

[ Edited ]
‎01-03-2019 06:12 AM

I have Two DataCenter configuration. Main DC01 have cluster SRX345 and one ISP (BGP) and VirtualChassis inside. Second DC02 have his VirtualChassis in LAN and cluster SRX240 with one ISP (L3 interface tagged on two physical links).

We have multiple Branch Office – for this example we use only two and every Branch Office have  SRX300 or SRX320 with 2 ISP. Second ISP are on the second routing-instance.

We have IPSec VPN tunnel between DC01 and every ISP in every Branch Office, the same situation on DC02. There is no VPN tunnel between DC01 and DC02 - they have L2 connection.

 

For this point everything works great. If I use static routing with qualified-next-hop and preference everything works great!

Great means:

  1. Traffic from Branch Office to the servers run into VPN from from DC01 to main routing instance of every SRX from Branch Office.
  2. When main ISP down in Branch Office, VPN works from second ISP (second routing-instance) to DC01 – when main ISP start back, traffic back to using VPN from main ISP to DC01.
  3. When DC01 down, Branch Office connect to servers from his main ISP to DC02 tunnel – and back to DC01 tunnel when ISP on DC01 back.
  4. When DC01 is down and main ISP in branch office down (in the same time), everything works great using DC02 and ISP2 on Branch Office.

Now we want to use OSPF to works with all this routing. OSPF is new for us. We use only zone 0.0.0.0 because this looks clear and properly for this situation.

So our OSPF looks like this:


DC01:

 

root@DC01# show protocols ospf

import ospf-import

area 0.0.0.0 {

    interface st0.250 {

        priority 50;

    }

    interface irb.0 {

        passive;

    }

    interface st0.251 {

        priority 50;

    }

}

root@DC01# show policy-options policy-statement ospf-import

from {

    route-filter 10.250.250.2/32 exact;

    route-filter 10.250.251.2/32 exact;

}

then reject;

 

 

DC02:


root@DC02# show protocols ospf

import ospf-import

area 0.0.0.0 {

    interface st0.250;

    interface irb.0 {

        passive;

    }

    interface st0.251;

}

 

root@DC02# show policy-options policy-statement ospf-import

from {

    route-filter 10.250.250.1/32 exact;

    route-filter 10.250.251.1/32 exact;

}

then reject;

 

 

Client1:


root@Client1# show protocols ospf

rib-group ExportRouting;

export inet0;

area 0.0.0.0 {

    interface st0.250 {

        interface-type p2mp;

        neighbor 10.250.250.1;

        neighbor 10.250.250.2;

    }

    interface vlan.0 {

        passive;

    }

}

 

root@Client1# show routing-instances ISP2-vr protocols ospf

rib-group ImportRouting;

export StaticdoOSPF;

area 0.0.0.0 {

    interface st0.251 {

        interface-type p2mp;

        priority 50;

        neighbor 10.250.251.1;

        neighbor 10.250.251.2;

    }

}

 

root@Client# show routing-options rib-groups

ImportRouting {

    import-rib [ ISP2-vr.inet.0 inet.0 ];

}

ExportRouting {

    import-rib [ inet.0 ISP2-vr.inet.0 ];

}

 

root@Client# show policy-options

policy-statement StaticdoOSPF {

    term 10 {

        from {

            instance master;

            route-filter 192.168.78.0/24 exact;

            route-filter 172.16.120.0/24 exact;

        }

        then accept;

    }

    term 30 {

        then reject;

    }

}

policy-statement inet0 {

    term 10 {

        from {

            instance ISP2-vr;

            route-filter 172.16.120.0/24 exact;

            route-filter 192.168.78.0/24 exact;

        }

        then accept;

    }

    term 30 {

        then reject;

    }

}

 

Client2:

 

root@Client2# show protocols ospf

rib-group ExportRouting;

export inet0;

area 0.0.0.0 {

    interface st0.250 {

        interface-type p2mp;

        neighbor 10.250.250.1;

        neighbor 10.250.250.2;

    }

    interface vlan.0 {

        passive;

    }

}

root@Client2# show routing-instances ISP2-vr protocols ospf

rib-group ImportRouting;

export StaticdoOSPF

area 0.0.0.0 {

    interface st0.251 {

        interface-type p2mp;

        priority 50;

        neighbor 10.250.251.1;

        neighbor 10.250.251.2;

    }

}

 

root@Client2# show routing-options rib-groups

ImportRouting {

    import-rib [ ISP2-vr.inet.0 inet.0 ];

}

ExportRouting {

    import-rib [ inet.0 ISP2-vr.inet.0 ];

}

 

root@Client2# show policy-options

policy-statement StaticdoOSPF {

    term 10 {

        from {

            instance master;

            route-filter 192.168.38.0/24 exact;

            route-filter 172.16.120.0/24 exact;

        }

        then accept;

    }

    term 30 {

        then reject;

    }

}

policy-statement inet0 {

    term 10 {

        from {

            instance ISP2-vr;

            route-filter 172.16.120.0/24 exact;

            route-filter 192.168.38.0/24 exact;

        }

        then accept;

    }

    term 30 {

        then reject;

    }

}

 



We have two problems with this configuration:

  1. Why we see OSPF routes to st0 interface address to DC01 from DC02 and vice versa?

 We use policy-statement ospf-import to prevent this situation!

 Example from DC01 (10.250.250.1):
10.250.250.2/32    *[OSPF/10] 00:04:46, metric 2

                    > to 10.250.250.38 via st0.250

                      to 10.250.250.78 via st0.250

                      to 10.250.251.38 via st0.251

                      to 10.250.251.78 via st0.251

10.250.251.2/32    *[OSPF/10] 00:04:46, metric 2

                      to 10.250.250.38 via st0.250

                    > to 10.250.250.78 via st0.250

                      to 10.250.251.38 via st0.251

                      to 10.250.251.78 via st0.251

 

     2. Why OSPF sometimes set route from Branch Office to DC1 using interface with priority 50 and sometimes this with no proioity definet (that means that with default priority = 128)?

We use interface st0.250 priority 50 to prevent this situation.

Example on Client1:
172.16.120.0/24    *[OSPF/10] 00:14:27, metric 2

                      to 10.250.250.1 via st0.250

                    > to 10.250.250.2 via st0.250

                    [OSPF/10] 00:09:05, metric 2

                    > to 10.250.251.1 via st0.251

                      to 10.250.251.2 via st0.251

Example on Client2 (in the same time):

172.16.120.0/24    *[OSPF/10] 00:00:48, metric 2

                    > to 10.250.250.1 via st0.250

                      to 10.250.250.2 via st0.250

                    [OSPF/10] 00:00:48, metric 2

                      to 10.250.251.1 via st0.251

                    > to 10.250.251.2 via st0.251

 

I enclose the whole diagram.

Attachments

6 REPLIES 6
Routing

Re: Two DC connected L2 and OSPF over IPSec VPN from Branch Offices.

‎01-03-2019 06:41 AM

1.Why we see OSPF routes to st0 interface address to DC01 from DC02 and vice versa?

A. ospf import policy is used to control/filter external routes. It has no effect on ospf intra/inter area routes (This is your case)

Reference: https://www.juniper.net/documentation/en_US/junos/topics/example/ospf-import-routing-policy-configur...

"OSPF import policy allows you to prevent external routes from being added to the routing tables of OSPF neighbors. The import policy does not impact the OSPF database. This means that the import policy has no impact on the link-state advertisements. The filtering is done only on external routes in OSPF. The intra-area and interarea routes are not considered for filtering. "

 

2.  Why OSPF sometimes set route from Branch Office to DC1 using interface with priority 50 and sometimes this with no proioity definet (that means that with default priority = 128)?

 

priority is used to control the selection of Designated Router (DR) in a segment. It has no role in route selection. In your case, you have to use "metric" to control/prefer the routes

 

Reference: https://www.juniper.net/documentation/en_US/junos/topics/example/ospf-segment-cost-configuring.html#...

 

Thanks,
Nellikka
JNCIE x3 (SEC #321; SP #2839; ENT #790)
Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!
Routing

Re: Two DC connected L2 and OSPF over IPSec VPN from Branch Offices.

‎01-03-2019 11:19 PM

Thanks Nellikka!

The second point is obvious and solved but what about the first point?

I can't stay with this configuration because when I will add 20 Branch Office i will have dozens of route from DC to DC through these Branch Offices.

Can I prevent learning of this routes from OSPF?

Any control that works inside the AS?

Maybe the concept from 0.0.0.0 is wrong and should I use the declined area for each Branch Office?

Routing

Re: Two DC connected L2 and OSPF over IPSec VPN from Branch Offices.

‎01-04-2019 03:02 AM

you best bet for the kind of routing control you want is to use bgp instead of ospf for the deploy.  That will allow you to create the kind of detailed routing import/export policies you are looking for.

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
Routing

Re: Two DC connected L2 and OSPF over IPSec VPN from Branch Offices.

‎01-07-2019 05:05 AM

@Nellikka

Maybe not so obvious...

I changed the priorities to the metric and have now on Branch Office site:

root@Client2# show protocols

ospf {

    rib-group ExportRouting;

    export inet0;

    area 0.0.0.0 {

        interface st0.250 {

            interface-type p2mp;

            neighbor 10.250.250.1 eligible;

            neighbor 10.250.250.2;

        }

        interface vlan.0 {

            passive;

        }

    }

}

 

root@Client2# show routing-instances ISP2-vr protocols

ospf {

    rib-group ImportRouting;

    export StaticdoOSPF;

    area 0.0.0.0 {

        interface st0.251 {

            interface-type p2mp;

            metric 50;

            neighbor 10.250.251.1 eligible;

            neighbor 10.250.251.2;

        }

    }

}

 

And status:


root@Client2# run show route protocol ospf 172.16.120.0/24

 

inet.0: 20 destinations, 31 routes (20 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

172.16.120.0/24    *[OSPF/10] 00:15:22, metric 2

                    > to 10.250.250.1 via st0.250

                      to 10.250.250.2 via st0.250

                    [OSPF/10] 00:15:17, metric 51

                      to 10.250.251.1 via st0.251

                    > to 10.250.251.2 via st0.251

 

ISP2-vr.inet.0: 20 destinations, 31 routes (20 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

172.16.120.0/24    *[OSPF/10] 00:15:22, metric 2

                    > to 10.250.250.1 via st0.250

                      to 10.250.250.2 via st0.250

                    [OSPF/10] 00:15:17, metric 51

                      to 10.250.251.1 via st0.251

                    > to 10.250.251.2 via st0.251

 

After some time status:
 

inet.0: 20 destinations, 31 routes (20 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

172.16.120.0/24    *[OSPF/10] 00:25:12, metric 2

                      to 10.250.250.1 via st0.250

                    > to 10.250.250.2 via st0.250

                    [OSPF/10] 00:25:20, metric 51

                      to 10.250.251.1 via st0.251

                    > to 10.250.251.2 via st0.251

 

ISP2-vr.inet.0: 20 destinations, 31 routes (20 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

172.16.120.0/24    *[OSPF/10] 00:25:12, metric 2

                    > to 10.250.250.1 via st0.250

                      to 10.250.250.2 via st0.250

                    [OSPF/10] 00:25:20, metric 51

                    > to 10.250.251.1 via st0.251

                      to 10.250.251.2 via st0.251

 

 

After some time status:

 

inet.0: 20 destinations, 31 routes (20 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

172.16.120.0/24    *[OSPF/10] 00:27:08, metric 2

                    > to 10.250.250.1 via st0.250

                      to 10.250.250.2 via st0.250

                    [OSPF/10] 00:27:19, metric 51

                    > to 10.250.251.1 via st0.251

                      to 10.250.251.2 via st0.251

 

ISP2-vr.inet.0: 20 destinations, 31 routes (20 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

172.16.120.0/24    *[OSPF/10] 00:27:08, metric 2

                      to 10.250.250.1 via st0.250

                    > to 10.250.250.2 via st0.250

                    [OSPF/10] 00:27:19, metric 51

                    > to 10.250.251.1 via st0.251

                      to 10.250.251.2 via st0

 

 

@SPuluka

I would really like to do it with ospf, but maybe I should change the concept. Maybe separate the area between each dc/drc and branch to make a separate area? 

Routing

Re: Two DC connected L2 and OSPF over IPSec VPN from Branch Offices.

‎01-07-2019 05:40 AM

Maybe I was not too clear, I will try again - it's easier.

I have a situation like in an attachment OSPF-IPSec2 (attached to this post) + static routing:

Client inet.0:

route 0.0.0.0/0 next-hop 10.1.0.10;
route 172.16.120.0/24 {

    next-hop 10.250.250.1;

    qualified-next-hop 10.250.251.1 {

        preference 6;

    }

    qualified-next-hop 10.250.250.2 {

        preference 7;

    }

    qualified-next-hop 10.250.251.2 {

        preference 8;

    }

    preference 5;

}

 

Client ISP2-vr.inet.0:

    route 0.0.0.0/0 next-hop 10.2.0.10;

    route 172.16.120.0/24 {

        next-hop 10.250.250.1;

        qualified-next-hop 10.250.251.1 {

            preference 6;

        }

        qualified-next-hop 10.250.250.2 {

            preference 7;

        }

        qualified-next-hop 10.250.251.2 {

            preference 8;

        }

        preference 5;

    }

 

DC inet.0:

    route 0.0.0.0/0 next-hop 10.3.0.10;

    route 192.168.78.0/24 {

        next-hop 10.250.250.78;

        qualified-next-hop 10.250.251.78 {

            preference 6;

        }

        preference 5;

 

DRC inet.0:

    route 0.0.0.0/0 next-hop 10.4.0.10;

    route 192.168.78.0/24 {

        next-hop 10.250.250.78;

        qualified-next-hop 10.250.251.78 {

            preference 6;

        }

        preference 5;

 

 

It works perfectly! How to convert this to OSPF?

Attachments

Routing

Re: Two DC connected L2 and OSPF over IPSec VPN from Branch Offices.

‎01-07-2019 06:35 AM

Since st0 interface is configured as multipoint, you can not control routes like static routes as interface cost is same for both neighbors.  One option is to advertise the 172.16.120.0/24 with low cost from DC and high cost from DRC. You can achieve this by adding high metric statement on the interface which is having 172.16.120.0/24 network on DRC. Or you may have to change the design and  use st0 interface as point-to-point interfaces

 

Thanks,
Nellikka
JNCIE x3 (SEC #321; SP #2839; ENT #790)
Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!