17,453 views
Using OSPF on Juniper Netscreen Firewalls
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 :
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 :
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
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
router-a-> set int e0/0 protocol ospf passive
© 2008 – 2014, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.