Branch Connectivity Overview: VPN and OSPF Configuration

Connectivity Overview of Branch Connectivity:
This connectivity is segregated in two step.

1. Branch End IPSEC tunnel & OSPF configuration.
2. Core end IPSEC tunnel & OSPF configuration.
Branch End IPSEC tunnel & OSPF configuration brief description is given below.
At branch end we have configured route based numbered tunnels. For Production Site we have allocated tunnel.7 and tunnel.8 for
primary and secondary media respectively and for Disaster Recovery Site we have allocated tunnel.9 and tunnel.10 for primary and
secondary media respectively. Underlay routes are for vendor media reachability till Lahore DR site and overlay routes are for IPSEC
VPN configuration and to run OSPF on those overlay IP’s. We are using Juniper SRX and SSG firewall routers for this purpose. The
tunnel interfaces 7, 8, 9 and 10 are P2MP.
Core End IPSEC tunnel & OSPF configuration brief description is given below.
At core end we have Juniper SRX5400 Firewall installed which is working as a VPN concentrator. This branch to aggregation
connectivity is deployed in HUB and spoke mode. All of 8 media Service Provider providing country wide branch connectivity to UBL
are terminated on Juniper MX-104 Routers. These Juniper MX104 Routers are connected with Juniper SRX5400 Firewall providing
Peer IP connectivity to the branch routers.
UBL Network Operation Team have segregated country wide UBL branches in 74 p2mp st interface and 37 OSPF areas. First st
interface is dedicated to primary media and second one for secondary media. For example, in the st interface # 1271 and st interface
1272 interfaces, the number 127 stands for the OSPF area and number 1 stands for primary media and number 2 stands for
secondary media.
P a g e 1 | 22
SUMMARY:
For controlling the routes being installed in the routing table and OSPF process, two VRs are created called GREEN-VR and BLUE-
VR. All the branches are present in the GREEN-VR. The interfaces connected to the NEXUS 7K (whether KHI or LHR) are in BLUE-
VR. Import policies and export policies are utilized in the SRX5400 for controlling and distribution of necessary routes.
P a g e 2 | 22
IMPORT POLICY:
Import policy is used to populate the routing table. There are two import policies implemented at both DR and HO.
1. GREEN-TO-BLUE
2. BLUE-TO-GREEN
GREEN-TO-BLUE – HO SIDE:
From GREEN-TO-BLUE import policy, we are importing routes from the GREEN-VR to BLUE-VR. When importing from GREEN-TO-
BLUE, OSPF routes are imported as E1 routes, while static routes are imported as static routes with metric 300.
set policy-options policy-statement GREEN-to-BLUE term 1 from instance GREEN-VR

set policy-options policy-statement GREEN-to-BLUE term 1 from protocol ospf
set policy-options policy-statement GREEN-to-BLUE term 1 then external type 1
set policy-options policy-statement GREEN-to-BLUE term 1 then accept
set policy-options policy-statement GREEN-to-BLUE term 2 from protocol static
set policy-options policy-statement GREEN-to-BLUE term 2 then metric 300
set policy-options policy-statement GREEN-to-BLUE term 2000 then reject
set routing-instances BLUE-VR routing-options instance-import GREEN-to-BLUE
OSPF BRANCH:
We have run the following command: “show ip route 10.5.50.1”
GREEN VR BLUE VR
10.5.50.0/24 *[OSPF/10] 3d 00:29:40, metric 181 10.5.50.0/24 *[OSPF/10] 3d 00:29:40, metric 181
> to 10.128.1.56 via st0.1011 > to 10.128.1.56 via st0.1011
STATIC BRANCH:
GREEN VR BLUE VR
10.4.40.0/24 *[Static/20] 2w5d 07:18:50 10.4.40.0/24 *[Static/20] 2w5d 07:18:50, metric 300
P a g e 3 | 22
> via st0.2175 > via st0.2175
[Static/25] 21:40:15
> via st0.3175
 As configured, the metric has changed to 300.
GREEN TO BLUE – DR SIDE:

We have limited the installation of 10.1, 10.2 and 10.3 networks in BLUE-VR because these are the networks behind the KHI
Nexus. Later on all the other prefixes are allowed to be installed in the BLUE-VR routing table.

set policy-options policy-statement GREEN-to-BLUE term 1 from route-filter 10.1.0.0/16 exact
set policy-options policy-statement GREEN-to-BLUE term 2 from route-filter 10.0.0.0/11 orlonger
set routing-instances BLUE-VR routing-options instance-import GREEN-to-BLUE
OSPF BRANCH:
GREEN VR – DR SRX5400 BLUE VR – DR SRX5400
10.5.50.0/24 *[OSPF/10] 1w0d 00:24:15, metric 221 10.5.50.0/24 *[OSPF/10] 1w0d 00:24:15, metric 221
> to 10.128.1.184 via st0.1011 > to 10.128.1.184 via st0.1011
P a g e 4 | 22
STATIC BRANCH –DR SIDE:
GREEN VR – DR SRX5400 BLUE VR – DR SRX 5400
10.4.40.0/24 *[Static/30] 2d 22:53:44 10.4.40.0/24 *[Static/30] 2d 22:53:44
> via st0.2175 > via st0.2175
[Static/35] 1d 14:49:56
> via st0.3175
BLUE-TO-GREEN- HO SIDE:
NEXUS7K-HO SITE is OSPF neighbor with RETH interfaces in BLUE-VR. In NEXUS-KHI we have following types of routes available
which has to be advertised to the BLUE-VR:
1. OSPF ROUTE
2. STATIC ROUTE
Both of these types of routes from NEXUS 7K-KHI is imported from BLUE-VR to GREEN-VR with “as it is” condition.
set policy-options policy-statement BLUE-TO-GREEN term 1 from instance BLUE-VR

set policy-options policy-statement BLUE-TO-GREEN term 1 from protocol ospf
set policy-options policy-statement BLUE-TO-GREEN term 1 then accept
set policy-options policy-statement BLUE-TO-GREEN term 2 from protocol static
set policy-options policy-statement BLUE-TO-GREEN term 3 then reject
set routing-instances GREEN-VR routing-options instance-import BLUE-TO-GREEN
OSPF ROUTE:
We have run the “show ip route 10.2.15.1” on both NEXUS and SRX5400.
NEXUS-KHI SRX5400 –KHI (BLUE VR + GREEN VR)
10.2.15.0/24, ubest/mbest: 1/0 10.2.15.0/24 *[OSPF/10] 4w1d 22:59:56, metric 3
*via 10.2.20.2, Eth3/1, [110/2], 4w1d, ospf-1, intra > to 172.31.4.65 via reth1.0
P a g e 5 | 22
 Metric has increased from 2 to 3 because of the cost link of 1 between NEXUS and SRX5400.
STATIC ROUTE:
We have run the “show ip route 10.20.1.1” on both NEXUS and SRX5400.
NEXUS-KHI SRX5400 –KHI (BLUE VR + GREEN VR)
10.20.1.0/24, ubest/mbest: 1/0 10.20.1.0/24 *[OSPF/150] 11w2d 09:25:14, metric 20, tag 0
*via 10.1.106.15, [1/0], 2y15w, static to 172.31.4.69 via reth2.0
> to 172.31.4.65 via reth1.0
 Static routes learnt from NEXUS 7K-KHI are treated as E2 type with metric set to 20.
BLUE-TO-GREEN -- DR SITE:
NEXUS7K-DR SIDE is OSPF neighbor with RETH interfaces in BLUE-VR. Unlike HO site, where NEXUS7K-KHI was advertising the
static and the OSPF routes to the KHI-SRX5400, NEXUS7K-DR is only advertising the routes of the server farm which NEXUS7K-DR
has learnt from another OSPF relationship.
Here we are defining that the following prefixes will be allowed into the GREEN-VR from BLUE-VR.

set policy-options policy-statement BLUE-TO-GREEN term 1 from route-filter 10.98.0.0/16 orlonger
set policy-options policy-statement BLUE-TO-GREEN term 2 then reject
set routing-instances GREEN-VR routing-options instance-import BLUE-TO-GREEN
P a g e 6 | 22
OSPF ROUTE:
We have run the “show ip route 10.98.12.1” on both LHR NEXUS and LHR SRX5400.
NEXUS - LHR SRX5400 –LHR (BLUE VR + GREEN VR)
10.98.12.0/24, ubest/mbest: 1/0 10.98.12.0/24 *[OSPF/10] 29w5d 18:32:33, metric 43
*via 172.31.3.26, Po5, [110/42], 1y0w, ospf-1, intra to 172.31.3.69 via reth2.0
>to 172.31.3.65 via reth1.0
 Metric has increased from 42 to 43 because of the cost link of 1 between NEXUS and SRX5400.
EXPORT POLICY:
Export policy is used in Juniper when the routes from the routing table are exported (or redistributed in Cisco terms) to the
protocol. In our case the protocol is OSPF.
We have two export policies implemented at both HO and DR site.

1. To-Branch
2. From-Branch
TO-BRANCH
This is used for advertising external routes to the branches.
i. FOR DEFAULT ROUTE:
1. As HO is more preferred, the metric is set to 20 for HO and for DR the metric is increased to 100.
ii. FOR 10.98.0.0/16 ROUTE:
1. Only the DR is advertising this route to the branches with a metric of 20.
P a g e 7 | 22
TO-BRANCH –FOR DEFAULT ROUTE -HO SITE:
P a g e 8 | 22
set policy-options policy-statement To-Branch term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement To-Branch term 1 then metric 20
set policy-options policy-statement To-Branch term 1 then external type 1
set policy-options policy-statement To-Branch term 1 then accept
set policy-options policy-statement To-Branch term 2 then reject
set routing-instances GREEN-VR protocols ospf export To-Branch
TO-BRANCH – FOR DEFAULT ROUTE -DR SITE:

vendor.arwentech1@UBL-PR-AGG-FW-B> show ospf database instance GREEN-VR nssa
OSPF database, Area 0.0.0.101

Type ID Adv Rtr Seq Age Opt Cksum Len
NSSA *0.0.0.0 172.31.31.1 0x800035b4 2741 0x20 0x56f3 36
…[output omitted]…….
BRANCH END – DEFAULT ROUTE:

Branch-Router> show route 8.8.8.8
inet.0: 239 destinations, 243 routes (237 active, 2 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 2d 18:30:37, metric 200, tag 0
> to 10.128.1.1 via st0.7
P a g e 9 | 22
See the table below for the metric observed with various scenarios for default route:
DEF. ROUTE EXIT METRIC CALCULATION

ADVERTISER INTERFAC
E
HO ST0.7 200 (20 + 180)

(HO DEF. ROUTE METRIC + BRANCH ST0.7 OSPF
METRIC)
HO ST0.8 210 (20 + 190)
(HO DEF. ROUTE METRIC + BRANCH ST0.8 OSPF
METRIC)
HO ST0.9 275 (Utilizing primary (20 + 55 + 200)
interconnect link – st0.5xx- (HO DEF. ROUTE METRIC + st0.5xx LINK METRIC +
MULTINET) BRANCH ST0.9 OSPF METRIC)
HO ST0.9 280 (Utilizing secondary (20 + 60 + 200)
PTCL) BRANCH ST0.9 OSPF METRIC)
HO ST0.10 285 (Utilizing primary (20 + 55 + 210)
MULTINET) BRANCH ST0.10 OSPF METRIC)
HO ST0.10 290 (Utilizing secondary (20 + 60 + 210)
PTCL) BRANCH ST0.10 OSPF METRIC)
DR ST0.9 300 (100 + 200)
(DR DEF. ROUTE METRIC + BRANCH ST0.9 OSPF
METRIC)
DR ST0.10 310 (DR DEF. ROUTE METRIC + BRANCH ST0.10 OSPF
P a g e 10 | 22
METRIC)
FAILOVER SCENARIOS - DEFAULT ROUTE -BRANCH END:
In the table below, failover scenarios are discussed:
TO-BRANCH – FOR 10.98.0.0/16 -DR SITE:

set policy-options policy-statement To-Branch term 3 then reject
vendor.arwentech1@UBL-PR-AGG-FW-B> show ospf database instance GREEN-VR nssa
OSPF database, Area 0.0.0.101

Type ID Adv Rtr Seq Age Opt Cksum Len
…[output omitted]…….
P a g e 11 | 22
NSSA *10.98.0.0 172.31.31.31 0x80002882 2509 0x20 0xef0 36
FAILOVER SCENARIOS -10.98.0.0/16 ROUTE - BRANCH END:
BRANCH END – 10.98.0.0/16 ROUTE:
Branch-Router> show route 10.98.77.2

inet.0: 239 destinations, 243 routes (237 active, 2 holddown, 0 hidden)
10.98.0.0/16 *[OSPF/150] 2d 18:30:37, metric 220, tag 0
> to 10.128.1.193 via st0.9
See the table below for the metric observed with various scenarios for default route:
EXIT METRIC CALCULATION ROUTE

INTERFAC ADVERTISER
E
ST0.9 220 (20 + 200) DR

(DR. 10.98. ROUTE METRIC + BRANCH ST0.9 OSPF METRIC)
P a g e 12 | 22
ST0.10 230 (20 + 210) DR
(DR. 10.98. ROUTE METRIC + BRANCH ST0.10 OSPF METRIC)
ST0.7 250 (Utilizing primary (20 + 50 + 180) DR
interconnect link – st0.5xx- (DR. 10.98. ROUTE METRIC + st0.5xx LINK METRIC + BRANCH
MULTINET) ST0.7 OSPF METRIC)
ST0.7 255 (Utilizing secondary (20 + 55 + 180) DR
PTCL) ST0.7 OSPF METRIC)
ST0.8 260 (Utilizing primary (20 + 50 + 190) DR
MULTINET) ST0.8 OSPF METRIC)
ST0.8 265 (Utilizing secondary (20 + 55 + 190) DR
PTCL) ST0.8 OSPF METRIC)
FROM-BRANCH:
From-Branch is utilized to control the routes being installed in NEXUS at both DR and HO from SRX5400 (DO + HR).
There are two types of routes present in the routing table of BLUE VR.
1. OSPF
2. STATIC
FROM-BRANCH – HO SITE:
set policy-options policy-statement From-Branch term 1 from protocol ospf

set policy-options policy-statement From-Branch term 1 from route-filter 10.38.104.0/24 exact
…….[output omitted]…….
set policy-options policy-statement From-Branch term 1 then external type 2
P a g e 13 | 22
set policy-options policy-statement From-Branch term 1 then accept
set policy-options policy-statement From-Branch term 2 from protocol static
…….[output omitted]…….
set policy-options policy-statement From-Branch term 4000 then reject
set routing-instances BLUE-VR protocols ospf export From-Branch
Both of these routes (which are representing branches) are exported (redistributed) in OSPF process of BLUE-VR with E2 type.
We can see the results at the NEXUS end.
OSPF BRANCH:
GREEN VR BLUE VR
10.5.50.0/24 *[OSPF/10] 3d 00:29:40, metric 181 10.5.50.0/24 *[OSPF/10] 3d 00:29:40, metric 181
> to 10.128.1.56 via st0.1011 > to 10.128.1.56 via st0.1011
BLUE-VR OSPF DATABASE
vendor.arwentech1@UBL-PR-AGG-FW-B> show ospf database external instance BLUE-VR extensive | find 10.5.50
Extern *10.5.50.0 172.31.4.66 0x80000bf5 893 0x22 0x7336 36
mask 255.255.255.0
Topology default (ID 0)
Type: 2, Metric: 181, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
Gen timer 00:34:05
Aging timer 00:45:06
Installed 00:14:53 ago, expires in 00:45:07, sent 00:14:52 ago
Last changed 3d 20:40:54 ago, Change count: 284, Ours
NEXUS 7K:
P a g e 14 | 22
STATIC BRANCH:
GREEN VR BLUE VR
10.4.40.0/24 *[Static/20] 2w5d 07:18:50 10.4.40.0/24 *[Static/20] 2w5d 07:18:50, metric 300
> via st0.2175 > via st0.2175
[Static/25] 21:40:15
> via st0.3175
vendor.arwentech1@UBL-PR-AGG-FW-B> show ospf database external extensive instance BLUE-VR | find 10.4.40
Extern *10.4.40.0 172.31.4.66 0x80001072 1624 0x22 0x8f2c 36
mask 255.255.255.0
Gen timer 00:21:24
Last changed 11w3d 05:57:38 ago, Change count: 1, Ours
AT NEXUS:
P a g e 15 | 22
 For branches operating on OSPF, their metric remains unchanged. For branches operating in STATIC, their metric is shown
as 300 as a representation of static branch.
FROM BRANCH–DR SIDE:
10.1.,10.2,10.3 are being denied to be installed in the DR-NEXUS7K from the BLUE-VR. Rest of the routes, irrespective of the
protocol, are being exported (redistributed) in the BLUE-VR’s OSPF process as E2 type.

set policy-options policy-statement From-Branch term 2 from route-filter 10.0.0.0/11 orlonger
set routing-instances BLUE-VR protocols ospf export From-Branch
OSPF BRANCH:
P a g e 16 | 22
GREEN VR – DR SRX5400 BLUE VR – DR SRX5400
10.5.50.0/24 *[OSPF/10] 1w0d 00:24:15, metric 221 10.5.50.0/24 *[OSPF/10] 1w0d 00:24:15, metric 221
> to 10.128.1.184 via st0.1011 > to 10.128.1.184 via st0.1011

vendor.arwentech1@UBL-DR-AGG-FW-A> show ospf database external extensive instance BLUE-VR | find 10.5.50.
Extern *10.5.50.0 172.31.31.33 0x80001055 610 0x22 0x40e2 36
mask 255.255.255.0
Gen timer 00:38:09
Last changed 03:25:03 ago, Change count: 99, Ours
AT NEXUS 7K – DR:
 Same metric of 221 is being learnt at NEXUS 7K – DR as E2.
STATIC BRANCH –DR SIDE:
P a g e 17 | 22
GREEN VR – DR SRX5400 BLUE VR – DR SRX 5400

10.4.40.0/24 *[Static/30] 2d 22:53:44 10.4.40.0/24 *[Static/30] 2d 22:53:44
> via st0.2175 > via st0.2175
[Static/35] 1d 14:49:56
> via st0.3175
vendor.arwentech1@UBL-DR-AGG-FW-A> show ospf database external extensive instance BLUE-VR | find 10.4.40.
Extern *10.4.40.0 172.31.31.33 0x80000060 636 0x22 0x2ae6 36
mask 255.255.255.0
Gen timer 00:37:40
AT NEXUS - DR:
 As the branch was static, and we are not setting any metric values, the metric is set to 0 as E2.
BRANCHES OPERATING USING STATIC ROUTING:
P a g e 18 | 22
All the branches working in static routing have been assigned “ST” interfaces starting from range 2000 and 3000. So ST0.2xxx will
represent primary and ST0.3xxx will represent secondary tunnel interface.
For the branches that are operating on static routing. Tunnels are being established on both DR & HO. Static routes are pointing
towards the branches LAN subnets with different preference. Same methodology of OSPF tunnel preference is utilized for the
branches utilizing static routing.
HO SITE
set routing-instances GREEN-VR routing-options static route 10.4.40.0/24 qualified-next-hop st0.2175 preference 20
vendor.arwentech1@UBL-PR-AGG-FW-B> show route table GREEN-VR.inet.0 10.4.40.1
GREEN-VR.inet.0: 6969 destinations, 8089 routes (6969 active, 0 holddown, 0 hidden)

10.4.40.0/24 *[Static/20] 2w6d 04:20:19

> via st0.2175
[Static/25] 1d 18:41:44
> via st0.3175
DR SITE
vendor.arwentech1@UBL-DR-AGG-FW-A> show route table GREEN-VR.inet.0 10.4.40.1
GREEN-VR.inet.0: 6591 destinations, 7039 routes (6591 active, 0 holddown, 0 hidden)

10.4.40.0/24 *[Static/30] 00:40:53
P a g e 19 | 22
> via st0.2175
[Static/35] 1d 18:40:25
> via st0.3175
WHY THE INTERCONNECT AREA TUNNELS WERE CREATED?
In the event that the tunnel 9 and tunnel 10 are DOWN for the branch. Branch will travel from tunnel 7 to reach 10.98.x.x/16.
Now the destination of 10.98.x.x/16 is accessible through the st0.224(PTCL) and st0.225(MULTI) which were residing in AREA
0.0.0.0(INTER-AREA). Meanwhile another branch is advertising the 10.98.x.x/16 as an INTRA-AREA route. OSPF protocol dictates
that the INTRA-AREA routes are preferred over INTER-AREA routes.
So this branch would have to travel to another branch in order to get to 10.98.x.x/16. In order to mitigate this problem,
additional tunnels from SRX5400 KHI to SRX5400 LHR were made. These tunnels were made part of the respective areas. After
these tunnels were initialized in their respective areas, the branches were following the below path:
BRANCH  SRX 5400 (KHI)  INTERLINK OF THAT PARTICULAR AREA (ST0.5/ST0.1) SRX 5400(LHR)  NEXUS 7K LHR
DESTINATION
Branch > traceroute 10.98.12.1 source 10.8.21.1 no-resolve

traceroute to 10.98.12.1 (10.98.12.1) from 10.8.21.1, 30 hops max, 40 byte packets
10.128.4.1 7.031 ms 5.780 ms 5.369 ms SRX 5400 P2MP TUNNEL
10.128.102.65 22.876 ms 22.088 ms 22.158 ms INTERLINK ST0.504
172.31.3.65 23.700 ms * * NEXUS 7K LHR
* 10.98.12.1 23.327 ms * DESTINATION
OSPF – BRANCH END CONFIGURATION:
set protocols ospf area 0.0.0.101 nssa

set protocols ospf area 0.0.0.101 interface st0.7 metric 180
set protocols ospf area 0.0.0.101 interface ge-0/0/0.0 passive
P a g e 20 | 22
set protocols ospf area 0.0.0.101 interface ge-0/0/0.0 metric 1
At branch end OSPF has been configured in the area. The non-backbone area is configured to be NSSA, only allowing intra-Area
routes and external routes’ distribution as type 7.
ST0.7 and ST0.8 are terminating at HO with cost 180 and 190 respectively.
ST0.9 and ST0.10 are terminating at DR with cost 200 and 210 respectively.
Internal LAN interface is made passive to avoid formation of OSPF adjacency through it.
OSPF – FIREWALL END CONFIGURATION:
HO SITE – SRX5400
GREEN-VR
set routing-instances GREEN-VR protocols ospf area 0.0.0.101 interface st0.1011 interface-type p2mp
set routing-instances GREEN-VR protocols ospf area 0.0.0.101 interface st0.1011 metric 180
set routing-instances GREEN-VR protocols ospf area 0.0.0.101 interface st0.1011 dynamic-neighbors
set routing-instances GREEN-VR protocols ospf area 0.0.0.101 interface st0.501 interface-type p2p
Metric 50 is configured for ST0.501 (through MULTINET) and 55 is configured for ST0.101 (through PTCL.)
BLUE-VR
set routing-instances BLUE-VR protocols ospf area 0.0.0.0 interface reth1.0 interface-type p2p
DR SITE – SRX5400
P a g e 21 | 22
GREEN-VR
Metric 55 is configured for ST0.501 (through MULTINET) and 60 is configured for ST0.101 (through PTCL)
BLUE-VR
P a g e 22 | 22

Branch Connectivity Overview: VPN and OSPF Configuration

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Branch Connectivity Overview: VPN and OSPF Configuration

Uploaded by

Copyright:

Available Formats

Connectivity Overview of Branch Connectivity:

This connectivity is segregated in two step.

set policy-options policy-statement GREEN-to-BLUE term 1 from instance GREEN-VR

set routing-instances BLUE-VR routing-options instance-import GREEN-to-BLUE

 As configured, the metric has changed to 300.

GREEN TO BLUE – DR SIDE:

set policy-options policy-statement GREEN-to-BLUE term 1 from instance GREEN-VR

set routing-instances BLUE-VR routing-options instance-import GREEN-to-BLUE

set policy-options policy-statement BLUE-TO-GREEN term 1 from instance BLUE-VR

set routing-instances GREEN-VR routing-options instance-import BLUE-TO-GREEN

set policy-options policy-statement BLUE-TO-GREEN term 1 from instance BLUE-VR

set routing-instances GREEN-VR routing-options instance-import BLUE-TO-GREEN

We have two export policies implemented at both HO and DR site.

set routing-instances GREEN-VR protocols ospf export To-Branch

TO-BRANCH – FOR DEFAULT ROUTE -DR SITE:

set policy-options policy-statement To-Branch term 1 from route-filter 0.0.0.0/0 exact

set routing-instances GREEN-VR protocols ospf export To-Branch

vendor.arwentech1@UBL-PR-AGG-FW-B> show ospf database instance GREEN-VR nssa

OSPF database, Area 0.0.0.101

BRANCH END – DEFAULT ROUTE:

DEF. ROUTE EXIT METRIC CALCULATION

HO ST0.7 200 (20 + 180)

FAILOVER SCENARIOS - DEFAULT ROUTE -BRANCH END:

In the table below, failover scenarios are discussed:

TO-BRANCH – FOR 10.98.0.0/16 -DR SITE:

set policy-options policy-statement To-Branch term 2 from route-filter 10.98.0.0/16 exact

set routing-instances GREEN-VR protocols ospf export To-Branch

vendor.arwentech1@UBL-PR-AGG-FW-B> show ospf database instance GREEN-VR nssa

OSPF database, Area 0.0.0.101

FAILOVER SCENARIOS -10.98.0.0/16 ROUTE - BRANCH END:

BRANCH END – 10.98.0.0/16 ROUTE:

Branch-Router> show route 10.98.77.2

EXIT METRIC CALCULATION ROUTE

ST0.9 220 (20 + 200) DR

set policy-options policy-statement From-Branch term 1 from protocol ospf

set routing-instances BLUE-VR protocols ospf export From-Branch

FROM BRANCH–DR SIDE:

set policy-options policy-statement From-Branch term 1 from route-filter 10.1.0.0/16 exact

set routing-instances BLUE-VR protocols ospf export From-Branch

We have run the following command: “show ip route 10.5.50.1”

BLUE-VR OSPF DATABASE

 Same metric of 221 is being learnt at NEXUS 7K – DR as E2.

STATIC BRANCH –DR SIDE:

GREEN VR – DR SRX5400 BLUE VR – DR SRX 5400

BRANCHES OPERATING USING STATIC ROUTING:

vendor.arwentech1@UBL-PR-AGG-FW-B> show route table GREEN-VR.inet.0 10.4.40.1

GREEN-VR.inet.0: 6969 destinations, 8089 routes (6969 active, 0 holddown, 0 hidden)

10.4.40.0/24 *[Static/20] 2w6d 04:20:19

vendor.arwentech1@UBL-DR-AGG-FW-A> show route table GREEN-VR.inet.0 10.4.40.1

GREEN-VR.inet.0: 6591 destinations, 7039 routes (6591 active, 0 holddown, 0 hidden)

10.4.40.0/24 *[Static/30] 00:40:53

WHY THE INTERCONNECT AREA TUNNELS WERE CREATED?

Branch > traceroute 10.98.12.1 source 10.8.21.1 no-resolve

OSPF – BRANCH END CONFIGURATION:

set protocols ospf area 0.0.0.101 nssa

OSPF – FIREWALL END CONFIGURATION:

You might also like