Using OSPF on Juniper Netscreen Firewalls

Published October 19, 2008 |

Introduction to OSPF

OSPF is a link-state (dynamic) routing protocol that operates within an autonomous system. OSPF falls within the group of Interior Gateway Protocols. Devices that use OSPF will

advertise link state information. The devices generate Link State Advertisements (LSA’s) for directly connected links, and will forward LSAs received from other devices to ensure the integrity of the routing information across the OSPF network. OSPF can use unicast or multicast traffic to ‘flood’ routers with link state changes. It uses the same kind of connectivity for ‘hello’ traffic between neighbors. When OSPF uses multicast, it transmits data to 224.0.0.5 (multicast flooding ). All OSPF enabled devices send and listen to this address.
discover neighbors. When neighbors have been discovered, LSAs can be forwarded to each other. This discovery process is dynamic.
establish a link-state database (LSDB). This database consists of LSA information and is essential for determining the shortest path to a destination in the network.

The OSPF protocol detects link state changes and recalculates a new path to a destination. This process works very fast. By default, a regular OSPF router distributes information about locally connected networks, and can (optionally) redistribute routes to other networks (static routes, routes obtained via other means, etc) via route redistribution. Of course, route redistribution requires some manual configurations.

The technique used to find the shortest path to a destination is based on Dijkstra’s algorithm. This engine uses

router ID’s (unique identification for a router that is OSPF enabled)
the attached networks
neighboring devices (neighbor relationship table = adjancency database)
cost associated with attached networks or neighbors.

The shortest path is calculated based on path costs (often referred to as ‘preference’ in routing tables). In the past, the general rule for determining path costs was using the outcome of dividing 100 by the bandwidth of a link (in Mbit/s). Because nowadays, bandwidth can be higher than 100Mbit, this rule does not really work anymore (after all, you cannot have a cost lower than 1). Of course, you are free to determine the path costs yourself. (so if you want to use a custom cost based on the outcome of 1000 / bandwidth, then that will work too.)

The ‘metric’ field is also used when 2 routes are of the same type (intra-area, inter-area, E1, E2 -> most preferred type listed first)
E1 = External Type 1 : Includes both the external path cost and the sum of internal path costs to the ASBR that advertises the route (cost becomes higher as the destination if further away)
E2 = External Type 2 : the value of which is solely that of the external path cost (cost never changes)

Neighbors and Adjacencies

Two neighboring devices are only considered to be ‘adjacent’ to the OSPF protocol when both devices are able to fully synchronize their LSDBs. Once they are fully synced, they will attempt to remain synced (and will update each other when changes occur).
When two devices are directly connected (point to point connection between 2 devices), they automatically form an adjacency (this includes for example the tunnel interfaces at both ends of a Juniper route based VPN tunnel)
On broadcast networks (Ethernet LAN, no routers between the OSPF routers; OSPF devices can ‘see’ each other via broadcasts), routers form an adjacency with a DR and BDR only. (For more info about DR and BDR : see later) All devices on the segment will build and maintain tables, and update link state changes to their neighbors, but will only exchange the entire database (if required) with DR/BDR. Neighbors/Adjacent routers can talk to each other if they can be reached via multicast (224.0.0.5). Routers that are not directly reachable will still get and receive link state updates from their neighbors/adjacencies. The entire routing table can be compiled based on the information that is gathered and sent out by all devices.
In point-to-multipoint networks, the hub device will replicate update packets for each link.

The entire process of finding neighbors and forming adjacencies happens fully automated. Because this process only relies on Hello packets, it is unsecure. Luckily, you can force MD5 authentication on all OSPF enabled interfaces/routers, so neighbors/adjacent routers are only formed between ‘trusted’ routers. The impact of rogue OSPF enabled routers can be avoided this way. For the Microsoft guru’s amongst us : keep in mind that OSPF is no longer supported in server 2008 (but it is supported in server 2003, as a routing protocol under Routing & Remote Access)

Areas

A collection of OSPF enabled devices that belong to the same global network are combined into an ‘area’. This area is identified by a number, either written as a number or as a dotted decimal. Area Number 0 is used for the backbone network. All other areas connect to this area. You must have an area 0 and all other areas within an Autonomous System must connect to area 0.
Suppose you want to identify your area as area 10, depending on the device, this will be written as area 10, area 0.0.0.10 or are 10.0.0.0 While the dotted decimal number notation looks like an IP address, it really is not an IP address and will not have an impact on IP addresses in your network at all. It is just a number. Each device that should become part of the same area must have the same area number.

Because there may be multiple OSPF area’s (which may or may not be managed by you or someone else), some OSPF devices in the topology have specific functions :

Area border router (ABR) : acts as intermediate router between 2 area’s within the same Autonomous System. It will connect OSPF areas to the backbone area.

Autonomous system border router (ASBR) : acts as intermediate router between multiple Autonomous Systems.

Internal router (IR) : is a router with all links inside an area, that does not act as ABR or ASBR. If one of the links connects to the backbone area, it is also a BR.

Backbone router (BR) : is a router part of the OSPF backbone (area 0). This includes all ABRs, but not all BRs are ABRs (because some IR’s can also be a BR)

Next to the regular areas and the backbone area, OSPF uses 3 more area types :
Stub area : area which does not receive external routes except the default route. This area does receive inter-area routes (which is normal, because these are connected subnets). Stub areas can be useful to route all Internet access ASBRs in Area 0.0.0.0, and if there are multiple paths to other nonzero areas in the OSPF domain. These default routes are advertised as Type 3 LSAs. Other (inter-area) routes are advertised as Type 3 or Type 4 LSAs.

Totally stubby area : area that is essentially the same as a stub area, but it does not receive summary network either. This type of area can be useful for OSPF areas that are behind another area, with no other connections than to that other area and can only connect to that area. This way, the routing table looks simple : all non inter-area routes have to go to the ‘parent’ area anyway, so this way you can limit the routing table to the default route only.

Not-so-stubby area : this is a stub area that can import AS external routes and send them to the backbone (area 0), but cannot receive AS external routes from the backbone or other areas.

Designated Router / Backup Designated Router

Each area has a DR (Designated Router) and a BDR (Backup Designated Router), which are not real routers, but interfaces on routers. (After all, an OSPF enabled router uses one or more interfaces to connect to one or more area’s). So a router can be DR/BDR for multiple area’s at the same time. The DR holds the ‘master’ copy of the LSDB. This is especially important for new routers that join the area, because these new routers will attempt to download the database from the DR. In that case, the new router will get the DB (and sequence numbers) from the DR. Depending on the network layout, routers may only get updates from other routers because 1) OSPF routers use multicast traffic which, by default, doesn’t traverse routers and 2) the topology may not provide direct connections between all routers and the DR/BDR. This is not a problem, the neighbor/adjacent routers will update each other so everything gets distributed correctly.
The BDR offers redundancy in case the DR goes down. As explained above, routers on a broadcast link, will only form adjacencies with DR/BDR.

The DR/BDR election process is based on priorities (configurable), router ID, and/or (in case of the same priorities for multiple routers/interfaces) who answers first during the election phase. When a router with a higher priority than the router that currently holds the DR/BDR role comes online, nothing will happen until a new election is forced. This happens when the DR/BDR becomes unreachable (for 40 seconds, to avoid split brain situations). So when a device becomes DR, it will always stay DR until it gets disconnected for a period longer than the wait time (40 seconds), which will avoid network instabilities. When the DR is gone, the BDR automatically becomes DR, and election for a new BDR takes place.
If no priority was configured, the router with the highest router ID will become DR. If priority is set to zero, the device will not become DR/BDR.

OSPF packet exchange

As soon as a OSPF router is configured, it is in ‘init’ state. The OSPF router sends out a hello packet on an interface (each 10 seconds – configurable), towards the 224.0.0.5 multicast address. As soon as another router recognizes the hello packet, it becomes a neighbor of that router. If one of these two routers is a DR/BDR (broadcast lan) the 2 routers become adjacent and will exchange the entire database of link state information. If not, these 2 routers remain in a ‘2-way’ state, thus indicating that they are aware of each other, but don’t exchange information.
This hello packet contains

Area ID
Network number/mask that is assigned to the link
Hello interval
Dead interval
Options (authentication type, e-bit)
Router ID
Router priority
Designated Router
Backup Designated Router

When a router recognizes a hello packet, and becomes a neighbor, both routers are in ‘2-way’ state.
In order to become a neighbor, the following hello packet values must match :

area ID
Network number & mask
Hello interval
Dead interval
Options

If all requirements to become adjacent routers have been met, they will exchange data (DBD, Database Descriptor), which contain the OSPF header, a sequence number and the LSA header. Since the DBD exchange is connection oriented, acknowledgement packets are sent as well (for every received packet, and ACK is sent back). The goal of the DBD packet exchange is to update the OSPF databases (routing table, list of link states) on each router (or the LSDB on DR/BDR routers). When DBDs have been sent, the router changes its state to ‘loading’. At this point, the router can request details about a particular link by using LSR packets (and the adjacent router will respond with a LSU (Link State Update) packet). When the entire database has been exchanged/populated, both devices change their state to ‘full’.

LSA Types

The most common LSA types are

Type 1 : Router LSA : state & cost of router links to the area (intra-area)
Type 2 : Network LSA : sent by DR for multi-access segments with more that one attached router. This LSA describes all routers attached to that segment
Type 3 : Summary LSA : sent by ABRs only, and describes networks within the current AS, but outside of the area (inter-area)
Type 4 : ASBR Summary LSA : sent by ABRs, indicates location of the ASBR
Type 5 : AS External LSA : sent by ASBR, describes destinations outside the current AS (or default route towards the outside SA)
Type 6 : NSSA Externa LSA : Used by not-so-stubby areas to import external routers into a stub area

Think before you begin : Design your network !

Before configuring the Juniper devices, you need to think about the design (area’s, router ID’s, Priorities, routes that need to be injected, etc) and always keep in mind that OSPF only looks at link states. By default it will distribute the locally connected subnets (connected to interfaces that are OSPF enabled) to the other OSPF devices. If you want OSPF to distribute routing entries about connected subnets from non OSPF enabled interfaces, you’ll have to inject these connected subnets into OSPF. (in Windows, you can enable ASBR and it will send out the routes to the connected subnets). The same story is valid for any static routes : they won’t be distributed by default, you’ll have to inject them.

Let’s assume the following network :

(click on image to enlarge)

So we have 6 networks , 5 routers/Juniper firewalls that are OSPF capable (routers A, B, C, D and E), and 1 legacy firewall (F) that is not capable of running OSPF.

Each LAN interface on the routers are in Trust zone, the WAN interfaces are in a zone called WAN. The LAN interfaces are ethernet0/0, the WAN interfaces are ethernet0/1 (and ethernet0/2 if a second WAN link is used)
Firewall policies are set to allow all traffic between all zones (which is not a requirement, but since we are focussing on OSPF here, we’ll try to use the Juniper devices as a ANY to ANY router instead of a firewall for now. Don’t worry, if you want to set policies – no problem. Multicast traffic between the OSPF neighbor will work even with firewall policies.

Goal : enable OSPF and make sure all networks can communicate, using OSPF as routing distribution mechanism.

The blue boxes indicate the LAN IP addresses of the routers, the red boxes indicate the WAN IP addresses of the routers.

If you would use static routing to set up any to any routes, you would need to do this :

On router A :
create routes to 1.1.2.0/24, 1.1.4.0/24, 1.1.5.0/24 and 2.2.2.0/24 and send traffic to gateway 10.10.10.2
create route to 1.1.3.0/24 and send to gateway 10.10.30.2
and so on…
Bottom line : you’ll end up with many routes, just to provide routing for a more or less simple network.

Now what will our set up look like when we use OSPF ?

Think about it. It may depend on who is managing the routers, and the level of trust you have assigned to individual routers. If you have central management, you can stick to one area. If management is distributed, or if some routers are not really trusted, you create multiple areas.

Best case :

Put all routers in the same area. This could be area 0 if the routers form the backbone of your network. Since there will only one area, there will be no ABR.

Worst case : Create individual areas between all routers. This will work fine as well, but may be a little bit more complicated to setup. You’ll end up with various ABR’s that will distribute routers between areas. Keep in mind, if OSPF is enabled on an interface, the connected subnet on that interface will be distributed automatically, so if your network consists only of connected subnets, everything will work automatically. The advantage of having multiple areas is the fact that you will be able to set filters and block certain updates. Example :

Router A:
LAN = area 1
WAN to B = area 2
WAN to C = area 3

Router B :
LAN = area 10
WAN to A = area 2
WAN to D = area 11

Router C :
LAN = area 20
WAN to A = area 3

Router D:
LAN = area 30
WAN to B = area 11
WAN to E = area 21

Router E:
LAN = area 40
WAN to D : area 21

Configure OSPF

In this blog post, I’ll explain how to set up the ‘best case’ setup. If you are starting with OSPF, this will be hard enough.
We’ll put all routers in area 0, enable OSPF on all interfaces, add a static route on router E towards the network behind the non-OSPF aware router; and use static route injection into OSPF to distribute this network into the rest of the routing table. We’ll start with setting up the OSPF configurations first, and when this is working fine, we’ll have a look at the static route redistribution/injection.

General checklist for setting up OSPF on a Juniper screenOS firewall :

Create loopback interfaces that will host the router ID IP address (just to make sure these interfaces never go down and OSPF can communicate even if an interface is down)
Set router IDs on all routers that will be enabled for OSPF
Enable OSPF protocol on the router
Create OSPF areas
Assign interfaces to areas
Enable OSPF on interfaces
Set up redistribution if required

Router A

ethernet0/0 = LAN
ethernet0/1 = WAN to router B
ethernet0/2 = WAN to router C

## create loopback interface to be used as router ID
set zone WAN
set interface loopback.1 zone WAN set interface loopback.1 ip 10.10.10.254/32 ## ## set router ID set vrouter trust-vr router-id 10.10.10.254 ## ## enable OSPF set vrouter trust-vr protocol ospf set vrouter trust-vr protocol ospf enable ## ## create all OSPF areas that will be used on this router set vrouter trust-vr protocol ospf area 0 ## ## assign interface to area set interface ethernet0/0 protocol ospf area 0 set interface ethernet0/1 protocol ospf area 0 set interface ethernet0/2 protocol ospf area 0 ## ## enable ospf on interface set interface ethernet0/0 protocol ospf enable set interface ethernet0/1 protocol ospf enable set interface ethernet0/2 protocol ospf enable

Router B

ethernet0/0 = LAN
ethernet0/1 = WAN to router A

ethernet0/2 = WAN to router C

## create loopback interface to be used as router ID
set zone WAN set interface loopback.1 zone WAN set interface loopback.1 ip 10.10.10.253/32 ## ## set router ID set vrouter trust-vr router-id 10.10.10.253 ## ## enable OSPF set vrouter trust-vr protocol ospf set vrouter trust-vr protocol ospf enable ## ## create all OSPF areas that will be used on this router set vrouter trust-vr protocol ospf area 0 ## ## assign interface to area set interface ethernet0/0 protocol ospf area 0 set interface ethernet0/1 protocol ospf area 0 set interface ethernet0/2 protocol ospf area 0 ## ## enable ospf on interface set interface ethernet0/0 protocol ospf enable set interface ethernet0/1 protocol ospf enable set interface ethernet0/2 protocol ospf enable

Before you continue, look at the section ‘verify that everything is working’ to verify that router A and router B are now in state ‘Full’ and are exchanging routes.

Router C

ethernet0/0 = LAN

ethernet0/1 = WAN to Router A

## create loopback interface to be used as router ID
set zone WAN
set interface loopback.1 zone WAN
set interface loopback.1 ip 10.10.30.254/32
##
## set router ID
set vrouter trust-vr router-id 10.10.30.254
##
## enable OSPF
set vrouter trust-vr protocol ospf
set vrouter trust-vr protocol ospf enable
##
## create all OSPF areas that will be used on this router
set vrouter trust-vr protocol ospf area 0
##
## assign interface to area
set interface ethernet0/0 protocol ospf area 0
set interface ethernet0/1 protocol ospf area 0 
#
## enable ospf on interface
set interface ethernet0/0 protocol ospf enable
set interface ethernet0/1 protocol ospf enable

Router D

ethernet0/0 = LAN
ethernet0/1 = WAN to router B

ethernet0/2 = WAN to router E

## create loopback interface to be used as router ID
set zone WAN
set interface loopback.1 zone WAN
set interface loopback.1 ip 10.10.20.253/32
##
## set router ID
set vrouter trust-vr router-id 10.10.20.253
##
## enable OSPF
set vrouter trust-vr protocol ospf
set vrouter trust-vr protocol ospf enable
##
## create all OSPF areas that will be used on this router
set vrouter trust-vr protocol ospf area 0
##
## assign interface to area
set interface ethernet0/0 protocol ospf area 0
set interface ethernet0/1 protocol ospf area 0 
set interface ethernet0/2 protocol ospf area 0 
##
## enable ospf on interface
set interface ethernet0/0 protocol ospf enable
set interface ethernet0/1 protocol ospf enable
set interface ethernet0/2 protocol ospf enable

Router E

Since router F doesn’t speak OSPF, we won’t enable OSPF on the interface between E and F. This clearly has a security advantage, however it has a drawback too. The result is that that connected network 1.1.5.0/24 will not get distributed into the OSPF area. So we will have to inject it (see next chapter)

ethernet0/0 = LAN to F : don’t enable OSPF

ethernet0/1 = WAN to Router D

## create loopback interface to be used as router ID
set zone WAN
set interface loopback.1 zone WAN
set interface loopback.1 ip 10.10.40.254/32
##
## set router ID
set vrouter trust-vr router-id 10.10.40.254
##
## enable OSPF
set vrouter trust-vr protocol ospf
set vrouter trust-vr protocol ospf enable
##
## create all OSPF areas that will be used on this router
set vrouter trust-vr protocol ospf area 0
##
## assign interface to area
set interface ethernet0/1 protocol ospf area 0 
#
## enable ospf on interface
set interface ethernet0/1 protocol ospf enable

Router F (non-OSPF)

You can either create a static route to all other networks and send them to router E; or you can just set the default route to router E. Since we don’t have any other connects from router F, we’ll set the default route to router E.

router-f-> set route 0.0.0.0/0 gate 1.1.5.1

Verify that everything is working

First of all, make sure OSPF is properly configured on the routers :

As soon as you have configured the first 2 juniper devices (router-a and router-b), routes are already being distributed. If you would look at the routing table on router A, right after setting up router A and router B, you would see :

router-a-> get route protocol ospf IPv4 Dest-Routes for <untrust-vr> (0 entries) -------------------------------------------------------------------------------- H: Host C: Connected S: Static A: Auto-Exported I: Imported R: RIP P: Permanent D: Auto-Discovered iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1 E2: OSPF external type 2 IPv4 Dest-Routes for <trust-vr> (2 entries) -------------------------------------------------------------------------------- ID IP-Prefix Interface Gateway P Pref Mtr Vsys -------------------------------------------------------------------------------- * 6 1.1.2.0/24 eth0/1 10.10.10.2 O 60 1 Root
* 7 10.10.20.0/24 eth0/1 10.10.10.2 O 60 1 Root

Router A now contains 2 new routes that have been discovered via OSPF : 1.1.2.0/24 (which is connected to ethernet0/0 on router B) and 10.10.20.0/24 (connected to ethernet0/2 on router B and refers to the network between router B and router D). The network between router A and router B is not displayed because it is a connected network between router A and B, so there was no reason to distribute this via OSPF.

In both cases, the gateway points to 10.10.10.2, which is the WAN interface on router B.

If you would look at the OSPF parameters of router A, eth0/1 (WAN interface to router B), you would see this :

router-a-> get int e0/1 proto ospf

VR: trust-vr RouterId: 10.10.10.254
----------------------------------
Interface: ethernet0/1
IpAddr: 10.10.10.1/24, OSPF: enabled, Router: enabled
Type: Broadcast  Area: 0.0.0.0  Priority: 1  Cost: 1  Passive: No
Transit delay: 1s  Retransmit interval: 8s  Hello interval: 10s
Router Dead interval: 40s  Authentication-Type: None
Ignore-MTU: no Reduce-flooding: no 
State: Designated Router  DR: 10.10.10.1(self)  BDR: 10.10.10.2
Neighbors:
        RtrId: 10.10.10.253 IpAddr: 10.10.10.254 Pri: 1 State: Full

As you can see, router A and B are in state ‘Full’ which means that they have fully exchanged their OSPF data. Router A was the first router to be OSPF enabled, so it has become Designated Router. Router B was the second one to be OSPF enabled and it now acts as Backup Designated Router

As you continue to setup the other routers, the number of routes grow. After setting up all OSPF routers, the routing table should now contain all subnets that are directly attached to the interfaces that are OSPF enabled.

The only network that still remains unreachable is network 2.2.2.0/24, because it is behind a non OSPF enabled device. Network 1.1.5.0/24 is not part of the routing table either, because it is connected to the interface on router E that is not OSPF enabled.

The next chapters will explain how we can take advantage of OSPF, 1 static route and route redistribution to get these 2 issues fixed.

Inject the static route on Router E into the OSPF area

First, create a static route on Router E and send traffic for the 2.2.2.0/24 network towards router F :

router-e> set route 2.2.2.0/24 gate 1.1.5.2

Next, since router E is OSPF enabled, you can inject this static route into the OSPF area so it will be distributed to all other routers in the area.

This is how this works :

– Create an access list and route map

– Set the injected network type (OSPF External type 1 or OSPF External type 2). Type 1 : preference indicates sum of the preferences to the target network. Type 2 : preference doesn’t change

– Tell ospf to redistribute the route map and choose the type of protocol that needs to be redistributed

router-e-> set vrouter trust-vr
router-e(trust-vr)-> set access-list 1 permit ip 2.2.2.0/24 10
router-e(trust-vr)-> set route-map name InjectStaticNetworks permit 10
router-e(trust-vr/InjectStaticNetworks-10)-> set match ip 1
router-e(trust-vr/InjectStaticNetworks-10)-> set metric 20
router-e(trust-vr/InjectStaticNetworks-10)-> set metric-type type-1
router-e(trust-vr/InjectStaticNetworks-10)-> exit
router-e(trust-vr)-> set protocol ospf redistribute route-map InjectStaticNetworks protocol static 
router-e(trust-vr)-> exit

The example above indicates that I have created an access list that permits the use of network 2.2.2.0/24. Of course, if you want to redistribute all static routes, you could also have used
set access-list 1 permit ip 0.0.0.0/0 10

You can also assign tags to your static routes and then match the route-map to the tags (instead of having to specify the networks twice :

router-e-> set route 2.2.2.0/24 gate 1.1.5.2 tag 100

router-e-> set vrouter "trust-vr"
router-e(trust-vr)->set route-map name "InjectStaticNetworks" permit 10
router-e(trust-vr/InjectStaticNetworks)-> set match tag 100
router-e(trust-vr/InjectStaticNetworks)-> exit
router-e(trust-vr)-> exit

Inject a connected subnet (from the non-OSPF enabled interface) on Router E into the OSPF area

If you want to inject a connected subnet (e.g. from an interface that is not OSPF enabled), you can set the protocol to ‘connected’. Since we did not enable OSPF on the router-e interface that connects to F, a route to this subnet is not part of the OSPF distribution.

This is how this can be solved :

router-e-> set vrouter trust-vr
router-e(trust-vr)-> set access-list 2 permit ip 1.1.5.0/24 10
router-e(trust-vr)-> set route-map name InjectConnectedNetworks permit 10
router-e(trust-vr/InjectConnectedNetworks-10)-> set match ip 2
router-e(trust-vr/InjectConnectedNetworks-10)-> set metric 20
router-e(trust-vr/InjectConnectedNetworks-10)-> set metric-type type-1
router-e(trust-vr/InjectConnectedNetworks-10)-> exit
router-e(trust-vr)-> set protocol ospf redistribute route-map InjectConnectedNetworks protocol connected 
router-e(trust-vr)-> exit

That’s it – wait a couple of seconds and the new route should become visible on all routers in the OSPF area

Inject from other sources

This is the full list of sources that can be used when injecting information into ospf :

BGP : Match BGP routes.

Connected : Match connected routes.

Discovered : Match discovered routes.

Imported : Match imported routes.

RIP : Match RIP routes.

Static : Match static routes.

Redistribute the default route

You do not need to create a route-map to distribute the default route :

router-a-> set vrouter "trust-vr"
router-a(trust-vr)-> set protocol ospf
router-a(trust-vr/ospf)-> set advertise-def-route metric 1 metric-type 1
router-a(trust-vr/ospf)-> exit
router-a(trust-vr)-> exit

Stub area

An alternative way to set up the OSPF environment from the example above is to put router A and C in area 0 and to put the other routers in a stub area. This way, the routing table will look a lot more simple.

Router A and C will get the routes from the stub area, and the routers on the stub area will have a default route and a summary of the routes from routers A and C.

Of course, since the network connected to routers A and C cannot easily be summarized (using a unique supernet definition), the number of route entries for those networks will be the same.

The configuration of routers A and C will be the same, except for the interface ethernet0/2 on router A (which connects to router B), which will be part of the stub area as well

To set up a stub area, you must configure all interfaces as stub :

router-a-> set vrouter "trust-vr"
router-a(trust-vr)-> set protocol ospf
router-a(trust-vr/ospf)-> set area 3 stub
router-a(trust-vr/ospf)-> exit
router-a(trust-vr)-> exit
router-a->set int eth0/2 proto ospf area 3
router-a->set int eth0/2 proto ospf enable


router-b-> set vrouter "trust-vr"
router-b(trust-vr)-> set protocol ospf
router-b(trust-vr/ospf)-> set area 3 stub
router-b(trust-vr/ospf)-> exit
router-b(trust-vr)-> exit
router-b->set int eth0/0 proto ospf area 3 
router-b->set int eth0/0 proto ospf enable
router-b->set int eth0/1 proto ospf area 3
router-b->set int eth0/1 proto ospf enable
router-b->set int eth0/2 proto ospf area 3 
router-b->set int eth0/2 proto ospf enable
 

router-d-> set vrouter "trust-vr" 
router-d(trust-vr)-> set protocol ospf 
router-d(trust-vr/ospf)-> set area 3 stub 
router-d(trust-vr/ospf)-> exit 
router-d(trust-vr)-> exit
router-d->set int eth0/0 proto ospf area 3 
router-d->set int eth0/0 proto ospf enable 
router-d->set int eth0/1 proto ospf area 3 
router-d->set int eth0/1 proto ospf enable
router-d->set int eth0/2 proto ospf area 3 
router-d->set int eth0/2 proto ospf enable
 

router-e-> set vrouter "trust-vr" 
router-e(trust-vr)-> set protocol ospf 
router-e(trust-vr/ospf)-> set area 3 stub 
router-e(trust-vr/ospf)-> exit 
router-e(trust-vr)-> exit 
router-e->set int eth0/1 proto ospf area 3 
router-e->set int eth0/1 proto ospf enable

That’s it. Router A has now become a ABR (because it sits between area 0 and area 3, which is the stub area). Again, in this example, the use of a stub area would not change a lot to the routing table, because the networks in area 0 cannot easily be summarized. The use of a totally stubby area would be more efficient here, because that way, the routers on the stub area would only see a default route to area 0, which is ok in this scenario

Totally stubby area

A totally stubby area has essentially the same setup as a stub area, but on the ABR, you must suppress the use of summary LSA’s. In my example, router A is the ABR (eth0/2), so you can use this single command to convert the stub area into a totally stubby area :

router-a-> set vr trust-vr protocol ospf area 3 no-summary

All other routers in area 3 do not need to be changed. The ABR will take remove all summary LSAs from the LSDB and replace them with a default route.

Some other useful commands

router-a-> get vrouter trust-vr protocol ospf
router-a-> get vrouter trust-vr protocol ospf database
router-a-> get vrouter trust-vr protocol ospf area 0

router-a-> debug ospf ?
adj                  debug adcacency formation, teardown
all                  all ospf debug
ase                  imported routes debug
basic                basic debug
error                error message debug
hello                hello packet debug
illegal              illegal debug
import               debug redistributing routes into OSPF
lsa                  print lsa debugs
nbr                  neighbor debug
receive              receive packets debug
route                ospf route addition, deletion
snmp                 snmp messages
spf                  spf debug
task                 task blocking debug
transmit             transmit packets debug
trap                 trap debug

Securing OSPF

Define a list of approved neighbors

Suppose you want to restrict the OSPF neighbors for your OSPF router to 2 IP addresses, then you can use an access-list to accomplish this :

router-a-> set vrouter "trust-vr"
router-a(trust-vr)-> set access-list 5 permit ip 10.10.10.2/32 10
router-a(trust-vr)-> set access-list 5 permit ip 10.10.10.3/32 20
router-a(trust-vr)-> exit
router-a-> set int e0/1 protocol ospf neighbor-list 5

Enable md5 authentication

If you want to use md5 authentication between your OSPF routers, then use the following command on each OSPF enabled interface :

router-a-> set interface e0/0 protocol ospf authentication md5 ThisIsMyMD5Password

Use passive interfaces

This feature will force the interface to not send out hello packets, but will still distribute its routing information (including the information from secondary addresses on that interface)

router-a-> set int e0/0 protocol ospf passive

Posted in 001_Security, Juniper, Networking | Tagged abr, access-list, area, area 0.0.0.0, asbr, designated, dijkstra, injection, Juniper, lsa, lsdb, netscreen, not-so-stubby, open shortest path first, ospf, redistribute, redistribution, route-map, screenos, stub

Corelan Cybersecurity Research

:: Knowledge is not an object, it's a flow ::