{"id":998,"date":"2008-10-19T02:18:40","date_gmt":"2008-10-19T00:18:40","guid":{"rendered":"http:\/\/www.corelan.be:8800\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/"},"modified":"2008-10-19T02:18:40","modified_gmt":"2008-10-19T00:18:40","slug":"using-ospf-on-juniper-netscreen-firewalls","status":"publish","type":"post","link":"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/","title":{"rendered":"Using OSPF on Juniper Netscreen Firewalls"},"content":{"rendered":"<h3>Introduction to OSPF<\/h3>\n<p><a href=\"http:\/\/en.wikipedia.org\/wiki\/Open_Shortest_Path_First\" target=\"_blank\">OSPF<\/a> 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<\/p>\n<ul>\n<li>advertise link state information. The devices generate Link State Advertisements (LSA\u2019s) 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 \u2018flood\u2019 routers with link state changes. It uses the same kind of connectivity for \u2018hello\u2019 traffic between neighbors.&#160; When OSPF uses multicast, it transmits data to 224.0.0.5&#160; (multicast flooding ). All OSPF enabled devices send and listen to this address. <\/li>\n<li>discover neighbors.&#160; When neighbors have been discovered, LSAs can be forwarded to each other. This discovery process is dynamic. <\/li>\n<li>establish a link-state database (LSDB).&#160; This database consists of LSA information and is essential for determining the shortest path to a destination in the network. <\/li>\n<\/ul>\n<p>The OSPF protocol detects link state changes and recalculates a new path to a destination. This process works very fast.&#160; 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.<\/p>\n<p>The technique used to find the shortest path to a destination is based on <a href=\"http:\/\/en.wikipedia.org\/wiki\/Dijkstra%27s_algorithm\" target=\"_blank\">Dijkstra\u2019s algorithm<\/a>. This engine uses<\/p>\n<ul>\n<li>router ID's (unique identification for a router that is OSPF enabled) <\/li>\n<li>the attached networks <\/li>\n<li>neighboring devices&#160; (neighbor relationship table = adjancency database) <\/li>\n<li>cost associated with attached networks or neighbors. <\/li>\n<\/ul>\n<p>The shortest path is calculated based on path costs (often referred to as \u2018preference\u2019 in routing tables).&#160; 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).&#160; 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.)<\/p>\n<p>The \u2018metric\u2019 field is also used when 2 routes are of the same type (intra-area, inter-area, E1, E2&#160; -&gt; most preferred type listed first)    <br \/>E1 = External Type 1 : Includes both the external path cost and the <em>sum <\/em>of internal path costs to the ASBR that advertises the route (cost becomes higher as the destination if further away)     <br \/>E2 = External Type 2 : the value of which is solely that of the external path cost (cost never changes)<\/p>\n<p>&#160;<\/p>\n<h3>Neighbors and Adjacencies<\/h3>\n<p>Two neighboring devices are only considered to be \u2018adjacent\u2019 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).    <br \/>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)     <br \/>On broadcast networks (Ethernet LAN, no routers between the OSPF routers; OSPF devices can \u2018see\u2019 each other via broadcasts), routers form an adjacency with a DR and BDR only. (For more info about DR and BDR : see later)&#160;&#160; 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.&#160; The entire routing table can be compiled based on the information that is gathered and sent out by all devices.     <br \/>In point-to-multipoint networks, the hub device will replicate update packets for each link. <\/p>\n<p>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 \u2018trusted\u2019 routers.&#160; The impact of rogue OSPF enabled routers can be avoided this way.&#160; For the Microsoft guru\u2019s 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 &amp; Remote Access)<\/p>\n<p>&#160;<\/p>\n<h3>Areas<\/h3>\n<p>A collection of OSPF enabled devices that belong to the same global network are combined into an \u2018area\u2019.&#160; This area is identified by a number, either written as a number or as a dotted decimal.&#160; Area Number 0 is used for the backbone network. All other areas connect to this area.&#160; You must have an area 0 and all other areas within an Autonomous System must connect to area 0.    <br \/>Suppose you want to identify your area as area 10, depending on the device, this will be written as&#160; area 10, area 0.0.0.10 or are 10.0.0.0&#160;&#160;&#160; 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.&#160;&#160; Each device that should become part of the same area must have the same area number.<\/p>\n<p>Because there may be multiple OSPF area\u2019s (which may or may not be managed by you or someone else), some OSPF devices in the topology have specific functions :<\/p>\n<li>Area border router (ABR) : acts as intermediate router between 2 area\u2019s within the same Autonomous System. It will connect OSPF areas to the backbone area. <\/li>\n<li>Autonomous system border router (ASBR) : acts as intermediate router between multiple Autonomous Systems. <\/li>\n<li>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.\n<p>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\u2019s can also be a BR) <\/p>\n<p>Next to the regular areas and the backbone area, OSPF uses 3 more area types :      <br \/>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).&#160; 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.&#160; <\/p>\n<p>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.&#160; This way, the routing table looks simple : all non inter-area routes have to go to the \u2018parent\u2019 area anyway, so this way you can limit the routing table to the default route only.<\/p>\n<p>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.<\/p>\n<p>&#160;<\/p>\n<h3>Designated Router \/ Backup Designated Router<\/h3>\n<p>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\u2019s). So a router can be DR\/BDR for multiple area\u2019s at the same time.&#160; The DR holds the \u2018master\u2019 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\u2019t traverse routers&#160;&#160; and 2) the topology may not provide direct connections between all routers and the DR\/BDR.&#160; This is not a problem, the neighbor\/adjacent routers will update each other so everything gets distributed correctly.      <br \/>The BDR offers redundancy in case the DR goes down.&#160; As explained above, routers on a broadcast link, will only form adjacencies with DR\/BDR. <\/p>\n<p>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.&#160; When the DR is gone, the BDR automatically becomes DR, and election for a new BDR takes place.      <br \/>If no priority was configured, the router with the highest router ID will become DR.&#160; If priority is set to zero, the device will not become DR\/BDR.<\/p>\n<p>&#160;<\/p>\n<p>&#160;<\/p>\n<h3>OSPF packet exchange<\/h3>\n<p>As soon as a OSPF router is configured, it is in \u2018init\u2019 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.&#160; 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.&#160; If not, these 2 routers remain in a \u20182-way\u2019 state, thus indicating that they are aware of each other, but don\u2019t exchange information.      <br \/>This hello packet contains<\/p>\n<ul>\n<li>Area ID <\/li>\n<li>Network number\/mask that is assigned to the link <\/li>\n<li>Hello interval <\/li>\n<li>Dead interval <\/li>\n<li>Options (authentication type, e-bit) <\/li>\n<li>Router ID <\/li>\n<li>Router priority <\/li>\n<li>Designated Router <\/li>\n<li>Backup Designated Router <\/li>\n<\/ul>\n<p>When a router recognizes a hello packet, and becomes a neighbor, both routers are in \u20182-way' state.&#160; <br \/>In order to become a neighbor, the following hello packet values must match :<\/p>\n<ul>\n<li>area ID <\/li>\n<li>Network number &amp; mask <\/li>\n<li>Hello interval <\/li>\n<li>Dead interval <\/li>\n<li>Options <\/li>\n<\/ul>\n<p>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).&#160; 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).&#160; When DBDs have been sent, the router changes its state to \u2018loading\u2019.&#160; 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).&#160; When the entire database has been exchanged\/populated, both devices change their state to \u2018full\u2019.<\/p>\n<p>&#160;<\/p>\n<p>&#160;<\/p>\n<h3>LSA Types<\/h3>\n<p>The most common LSA types are<\/p>\n<ul>\n<li>Type 1 : Router LSA : state &amp; cost of router links to the area (intra-area) <\/li>\n<li>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 <\/li>\n<li>Type 3 : Summary LSA : sent by ABRs only, and describes networks within the current AS, but outside of the area (inter-area) <\/li>\n<li>Type 4 : ASBR Summary LSA : sent by ABRs, indicates location of the ASBR <\/li>\n<li>Type 5 : AS External LSA : sent by ASBR, describes destinations outside the current AS (or default route towards the outside SA) <\/li>\n<li>Type 6 : NSSA Externa LSA : Used by not-so-stubby areas to import external routers into a stub area <\/li>\n<\/ul>\n<p>&#160;<\/p>\n<p>&#160;<\/p>\n<h3>Think before you begin : Design your network !<\/h3>\n<p>Before configuring the Juniper devices, you need to think about the design (area\u2019s, router ID\u2019s, 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.&#160; If you want OSPF to distribute routing entries about connected subnets from non OSPF enabled interfaces, you\u2019ll 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\u2019t be distributed by default, you\u2019ll have to inject them.<\/p>\n<p>Let\u2019s assume the following network :<\/p>\n<p><a href=\"\/wp-content\/uploads\/2008\/10\/ospf-diagram.png\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" title=\"ospf_diagram\" style=\"border-top-width: 0px; display: inline; border-left-width: 0px; border-bottom-width: 0px; border-right-width: 0px\" height=\"576\" alt=\"ospf_diagram\" src=\"\/wp-content\/uploads\/2008\/10\/ospf-diagram-thumb.png\" width=\"538\" border=\"0\" \/><\/a>&#160; <br \/><em>(click on image to enlarge)<\/em><\/p>\n<p>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.<\/p>\n<p>Each LAN interface on the routers are in Trust zone, the WAN interfaces are in a zone called WAN.&#160; The LAN interfaces are ethernet0\/0, the WAN interfaces are ethernet0\/1 (and ethernet0\/2 if a second WAN link is used)      <br \/>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\u2019ll try to use the Juniper devices as a ANY to ANY router instead of a firewall for now.&#160; Don\u2019t worry, if you want to set policies \u2013 no problem.&#160; Multicast traffic between the OSPF neighbor will work even with firewall policies.<\/p>\n<p>Goal : enable OSPF and make sure all networks can communicate, using OSPF as routing distribution mechanism.<\/p>\n<p>The blue boxes indicate the LAN IP addresses of the routers, the red boxes indicate the WAN IP addresses of the routers.<\/p>\n<p>If you would use static routing to set up any to any routes, you would need to do this :<\/p>\n<p>On router A :      <br \/>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       <br \/>create route to 1.1.3.0\/24 and send to gateway 10.10.30.2       <br \/>and so on\u2026&#160; <br \/>Bottom line : you\u2019ll end up with many routes, just to provide routing for a more or less simple network.&#160; <\/p>\n<p>Now what will our set up look like when we use OSPF ?<\/p>\n<p>Think about it.&#160; 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&#160; create multiple areas.<\/p>\n<p>Best case :<\/p>\n<p>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.<\/p>\n<p>Worst case : Create individual areas between all routers. This will work fine as well, but may be a little bit more complicated to setup.&#160; You\u2019ll end up with various ABR\u2019s that will distribute routers between areas.&#160; 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.&#160; The advantage of having multiple areas is the fact that you will be able to set filters and block certain updates.&#160; Example :<\/p>\n<p><u>Router A:<\/u>       <br \/>LAN = area 1       <br \/>WAN to B = area 2       <br \/>WAN to C = area 3<\/p>\n<p><u>Router B :<\/u>       <br \/>LAN = area 10       <br \/>WAN to A = area 2       <br \/>WAN to D = area 11<\/p>\n<p><u>Router C :<\/u>       <br \/>LAN = area 20       <br \/>WAN to A = area 3<\/p>\n<p><u>Router D:<\/u>       <br \/>LAN = area 30       <br \/>WAN to B = area 11       <br \/>WAN to E = area 21<\/p>\n<p><u>Router E:<\/u>       <br \/>LAN = area 40       <br \/>WAN to D : area 21 <\/p>\n<p>&#160;<\/p>\n<p><\/p>\n<h3>Configure OSPF<\/h3>\n<p>In this blog post, I\u2019ll explain how to set up the \u2018best case\u2019 setup. If you are starting with OSPF, this will be hard enough.&#160; <br \/>We\u2019ll 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\u2019ll start with setting up the OSPF configurations first, and when this is working fine, we\u2019ll have a look at the static route redistribution\/injection.<\/p>\n<p>General checklist for setting up OSPF on a Juniper screenOS firewall : <\/p>\n<ul>\n<li>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) <\/li>\n<li>Set router IDs on all routers that will be enabled for OSPF <\/li>\n<li>Enable OSPF protocol on the router <\/li>\n<li>Create OSPF areas <\/li>\n<li>Assign interfaces to areas <\/li>\n<li>Enable OSPF on interfaces <\/li>\n<li>Set up redistribution if required <\/li>\n<\/ul>\n<p><\/p>\n<h5><u>Router A<\/u><\/h5>\n<p>ethernet0\/0 = LAN&#160; <br \/>ethernet0\/1 = WAN to router B       <br \/>ethernet0\/2 = WAN to router C <\/p>\n<\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\"><p>## create loopback interface to be used as router ID<br \/>set zone WAN<br \/>set interface loopback.1 zone WAN\nset interface loopback.1 ip 10.10.10.254\/32\n##\n## set router ID\nset vrouter trust-vr router-id 10.10.10.254\n##\n## enable OSPF\nset vrouter trust-vr protocol ospf\nset vrouter trust-vr protocol ospf enable\n##\n## create all OSPF areas that will be used on this router\nset vrouter trust-vr protocol ospf area 0\n##\n## assign interface to area\nset interface ethernet0\/0 protocol ospf area 0\nset interface ethernet0\/1 protocol ospf area 0 \nset interface ethernet0\/2 protocol ospf area 0 \n##\n## enable ospf on interface\nset interface ethernet0\/0 protocol ospf enable\nset interface ethernet0\/1 protocol ospf enable\nset interface ethernet0\/2 protocol ospf enable<\/p><\/pre>\n<\/p>\n<\/p>\n<p>\n    <br \/><u>Router B<\/u><\/p>\n<p>ethernet0\/0 = LAN&#160; <br \/>ethernet0\/1 = WAN to router A <\/p>\n<p>ethernet0\/2 = WAN to router C&#160;&#160; <\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\"><p>## create loopback interface to be used as router ID<br \/>set zone WAN\nset interface loopback.1 zone WAN\nset interface loopback.1 ip 10.10.10.253\/32\n##\n## set router ID\nset vrouter trust-vr router-id 10.10.10.253\n##\n## enable OSPF\nset vrouter trust-vr protocol ospf\nset vrouter trust-vr protocol ospf enable\n##\n## create all OSPF areas that will be used on this router\nset vrouter trust-vr protocol ospf area 0\n##\n## assign interface to area\nset interface ethernet0\/0 protocol ospf area 0\nset interface ethernet0\/1 protocol ospf area 0 \nset interface ethernet0\/2 protocol ospf area 0 \n##\n## enable ospf on interface\nset interface ethernet0\/0 protocol ospf enable\nset interface ethernet0\/1 protocol ospf enable\nset interface ethernet0\/2 protocol ospf enable<\/p><\/pre>\n<\/p>\n<p>Before you continue, look at the section \u2018verify that everything is working\u2019 to verify that router A and router B are now in state \u2018Full\u2019 and are exchanging routes. <\/p>\n<p>\n    <br \/><u>Router C<\/u><\/p>\n<p>ethernet0\/0 = LAN<br \/>\n    <br \/>ethernet0\/1 = WAN to Router A <\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">## create loopback interface to be used as router ID<br \/>set zone WAN\nset interface loopback.1 zone WAN\nset interface loopback.1 ip 10.10.30.254\/32\n##\n## set router ID\nset vrouter trust-vr router-id 10.10.30.254\n##\n## enable OSPF\nset vrouter trust-vr protocol ospf\nset vrouter trust-vr protocol ospf enable\n##\n## create all OSPF areas that will be used on this router\nset vrouter trust-vr protocol ospf area 0\n##\n## assign interface to area\nset interface ethernet0\/0 protocol ospf area 0\nset interface ethernet0\/1 protocol ospf area 0 \n#\n## enable ospf on interface\nset interface ethernet0\/0 protocol ospf enable\nset interface ethernet0\/1 protocol ospf enable<\/pre>\n<\/p>\n<p>&#160;<\/p>\n<p><u>Router D<\/u><\/p>\n<p>ethernet0\/0 = LAN&#160; <br \/>ethernet0\/1 = WAN to router B <\/p>\n<p>ethernet0\/2 = WAN to router E&#160;&#160; <\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">## create loopback interface to be used as router ID<br \/>set zone WAN\nset interface loopback.1 zone WAN\nset interface loopback.1 ip 10.10.20.253\/32\n##\n## set router ID\nset vrouter trust-vr router-id 10.10.20.253\n##\n## enable OSPF\nset vrouter trust-vr protocol ospf\nset vrouter trust-vr protocol ospf enable\n##\n## create all OSPF areas that will be used on this router\nset vrouter trust-vr protocol ospf area 0\n##\n## assign interface to area\nset interface ethernet0\/0 protocol ospf area 0\nset interface ethernet0\/1 protocol ospf area 0 \nset interface ethernet0\/2 protocol ospf area 0 \n##\n## enable ospf on interface\nset interface ethernet0\/0 protocol ospf enable\nset interface ethernet0\/1 protocol ospf enable\nset interface ethernet0\/2 protocol ospf enable<\/pre>\n<\/p>\n<p>\n    <br \/>&#160;<\/p>\n<p><u>Router E<\/u><\/p>\n<p>Since router F doesn\u2019t speak OSPF, we won\u2019t enable OSPF on the interface between E and F.&#160; 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.&#160; So we will have to inject it (see next chapter) <\/p>\n<p>ethernet0\/0 = LAN to F : don\u2019t enable OSPF <\/p>\n<p>ethernet0\/1 = WAN to Router D<\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">## create loopback interface to be used as router ID<br \/>set zone WAN\nset interface loopback.1 zone WAN\nset interface loopback.1 ip 10.10.40.254\/32\n##\n## set router ID\nset vrouter trust-vr router-id 10.10.40.254\n##\n## enable OSPF\nset vrouter trust-vr protocol ospf\nset vrouter trust-vr protocol ospf enable\n##\n## create all OSPF areas that will be used on this router\nset vrouter trust-vr protocol ospf area 0\n##\n## assign interface to area\nset interface ethernet0\/1 protocol ospf area 0 \n#\n## enable ospf on interface\nset interface ethernet0\/1 protocol ospf enable<\/pre>\n<\/p>\n<p>\n    <br \/>&#160;<\/p>\n<p><u>Router F<\/u> (non-OSPF) <\/p>\n<p>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\u2019t have any other connects from router F, we\u2019ll set the default route to router E.<\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-f-<span style=\"color: #0000ff\">&gt;<\/span> set route 0.0.0.0\/0 gate 1.1.5.1 <\/pre>\n<\/p>\n<p>&#160; <\/p>\n<p>\n    <\/p>\n<h3>Verify that everything is working<\/h3>\n<p>First of all, make sure OSPF is properly configured on the routers : <\/p>\n<p>As soon as you have configured the first 2 juniper devices (router-a and router-b), routes are already being distributed.&#160; If you would look at the routing table on router A, right after setting up router A and router B, you would see : <\/p>\n<p><\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\"><p><font color=\"#000000\"><span style=\"color: #0000ff\">router-a-&gt;<\/span> get route protocol ospf\n\nIPv4 Dest-Routes for <\/font><span style=\"color: #0000ff\">&lt;<\/span><span style=\"color: #800000\">untrust-vr<\/span><span style=\"color: #0000ff\">&gt;<\/span> (0 entries)\n--------------------------------------------------------------------------------\nH: Host C: Connected S: Static A: Auto-Exported\nI: Imported R: RIP P: Permanent D: Auto-Discovered\niB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1\nE2: OSPF external type 2\n\n\nIPv4 Dest-Routes for <span style=\"color: #0000ff\">&lt;<\/span><span style=\"color: #800000\">trust-vr<\/span><span style=\"color: #0000ff\">&gt;<\/span> (2 entries)\n--------------------------------------------------------------------------------\n   ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys\n--------------------------------------------------------------------------------\n*  6&#160;&#160;&#160; 1.1.2.0\/24            eth0\/1        10.10.10.2 O   60      1     Root<br \/>*  7&#160;&#160;&#160; 10.10.20.0\/24         eth0\/1        10.10.10.2 O   60      1     Root<br \/><\/p><\/pre>\n<\/p>\n<p>\n    <br \/>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. <\/p>\n<p>In both cases, the gateway points to 10.10.10.2, which is the WAN interface on router B.&#160; <\/p>\n<p>If you would look at the OSPF parameters of router A, eth0\/1 (WAN interface to router B), you would see this : <\/p>\n<p><\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-a-<span style=\"color: #0000ff\">&gt;<\/span> get int e0\/1 proto ospf\n\nVR: trust-vr RouterId: 10.10.10.254\n----------------------------------\nInterface: ethernet0\/1\nIpAddr: 10.10.10.1\/24, OSPF: enabled, Router: enabled\nType: Broadcast  Area: 0.0.0.0  Priority: 1  Cost: 1  Passive: No\nTransit delay: 1s  Retransmit interval: 8s  Hello interval: 10s\nRouter Dead interval: 40s  Authentication-Type: None\nIgnore-MTU: no Reduce-flooding: no \nState: Designated Router  DR: 10.10.10.1(self)  BDR: 10.10.10.2\nNeighbors:\n        RtrId: 10.10.10.253 IpAddr: 10.10.10.254 Pri: 1 State: Full<\/pre>\n<\/p>\n<p>As you can see, router A and B are in state \u2018Full\u2019 which means that they have fully exchanged their OSPF data.&#160; 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 <\/p>\n<p>As you continue to setup the other routers, the number of routes grow.&#160; 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. <\/p>\n<p>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. <\/p>\n<p>The next chapters will explain how we can take advantage of OSPF, 1 static route and route redistribution to get these 2 issues fixed. <\/p>\n<p><\/p>\n<p><\/p>\n<h3>Inject the static route on Router E into the OSPF area<\/h3>\n<p>First, create a static route on Router E and send traffic for the 2.2.2.0\/24 network towards router F : <\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-e<span style=\"color: #0000ff\">&gt;<\/span> set route 2.2.2.0\/24 gate 1.1.5.2<\/pre>\n<\/p>\n<p>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.<br \/>\n    <br \/>This is how this works : <\/p>\n<p>- Create an access list and route map <\/p>\n<p>- 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.&#160; Type 2 : preference doesn\u2019t change <\/p>\n<p>- Tell ospf to redistribute the route map and choose the type of protocol that needs to be redistributed<\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-e-<span style=\"color: #0000ff\">&gt;<\/span> set vrouter trust-vr\nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set access-list 1 permit ip 2.2.2.0\/24 10\nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set route-map name InjectStaticNetworks permit 10\nrouter-e(trust-vr\/InjectStaticNetworks-10)-<span style=\"color: #0000ff\">&gt;<\/span> set match ip 1\nrouter-e(trust-vr\/InjectStaticNetworks-10)-<span style=\"color: #0000ff\">&gt;<\/span> set metric 20\nrouter-e(trust-vr\/InjectStaticNetworks-10)-<span style=\"color: #0000ff\">&gt;<\/span> set metric-type type-1\nrouter-e(trust-vr\/InjectStaticNetworks-10)-<span style=\"color: #0000ff\">&gt;<\/span> exit\nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set protocol ospf redistribute route-map InjectStaticNetworks protocol static \nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> exit<\/pre>\n<\/p>\n<p>The example above indicates that I have created an access list that permits the use of network 2.2.2.0\/24.&#160; Of course, if you want to redistribute all static routes, you could also have used&#160; <br \/>set access-list 1 permit ip 0.0.0.0\/0 10 <\/p>\n<p>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 : <\/p>\n<p><\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-e-<span style=\"color: #0000ff\">&gt;<\/span> set route 2.2.2.0\/24 gate 1.1.5.2 tag 100\n\nrouter-e-<span style=\"color: #0000ff\">&gt;<\/span> set vrouter &quot;trust-vr&quot;\nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span>set route-map name &quot;InjectStaticNetworks&quot; permit 10\nrouter-e(trust-vr\/InjectStaticNetworks)-<span style=\"color: #0000ff\">&gt;<\/span> set match tag 100\nrouter-e(trust-vr\/InjectStaticNetworks)-<span style=\"color: #0000ff\">&gt;<\/span> exit\nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> exit<\/pre>\n<\/p>\n<p>\n    <\/p>\n<\/p>\n<h3>Inject a connected subnet (from the non-OSPF enabled interface) on Router E into the OSPF area <\/h3>\n<p>If you want to inject a connected subnet (e.g. from an interface that is not OSPF enabled), you can set the protocol to \u2018connected\u2019.&#160; 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.<br \/>\n    <br \/>This is how this can be solved :<\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-e-<span style=\"color: #0000ff\">&gt;<\/span> set vrouter trust-vr\nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set access-list 2 permit ip 1.1.5.0\/24 10\nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set route-map name InjectConnectedNetworks permit 10\nrouter-e(trust-vr\/InjectConnectedNetworks-10)-<span style=\"color: #0000ff\">&gt;<\/span> set match ip 2\nrouter-e(trust-vr\/InjectConnectedNetworks-10)-<span style=\"color: #0000ff\">&gt;<\/span> set metric 20\nrouter-e(trust-vr\/InjectConnectedNetworks-10)-<span style=\"color: #0000ff\">&gt;<\/span> set metric-type type-1\nrouter-e(trust-vr\/InjectConnectedNetworks-10)-<span style=\"color: #0000ff\">&gt;<\/span> exit\nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set protocol ospf redistribute route-map InjectConnectedNetworks protocol connected \nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> exit<\/pre>\n<\/p>\n<p>That\u2019s it \u2013 wait a couple of seconds and the new route should become visible on all routers in the OSPF area<\/p>\n<p>&#160;<\/p>\n<p>&#160;<\/p>\n<h3>Inject from other sources<\/h3>\n<p>\n    <br \/>This is the full list of sources that can be used when injecting information into ospf :<\/p>\n<\/p>\n<dt>\n<p>BGP : Match BGP routes.<br \/>\n      <br \/>Connected : Match connected routes. <\/p>\n<p>Discovered : Match discovered routes. <\/p>\n<p>Imported : Match imported routes. <\/p>\n<p>RIP : Match RIP routes. <\/p>\n<p>Static : Match static routes. <\/p>\n<p>&#160;<\/p>\n<h3>Redistribute the default route<\/h3>\n<p>\n      <br \/>You do not need to create a route-map to distribute the default route :<\/p>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-a-<span style=\"color: #0000ff\">&gt;<\/span> set vrouter &quot;trust-vr&quot;\nrouter-a(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set protocol ospf\nrouter-a(trust-vr\/ospf)-<span style=\"color: #0000ff\">&gt;<\/span> set advertise-def-route metric 1 metric-type 1\nrouter-a(trust-vr\/ospf)-<span style=\"color: #0000ff\">&gt;<\/span> exit\nrouter-a(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> exit<\/pre>\n<\/p>\n<p>&#160;<\/p>\n<p>\n      <\/p>\n<h3>Stub area<\/h3>\n<p>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.<br \/>\n      <br \/>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. <\/p>\n<p>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.<\/p>\n<p>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<\/p>\n<p>To set up a stub area, you must configure all interfaces as stub :<\/p>\n<div>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\"><p>router-a-<span style=\"color: #0000ff\">&gt;<\/span> set vrouter &quot;trust-vr&quot;\nrouter-a(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set protocol ospf\nrouter-a(trust-vr\/ospf)-<span style=\"color: #0000ff\">&gt;<\/span> set area 3 stub\nrouter-a(trust-vr\/ospf)-<span style=\"color: #0000ff\">&gt;<\/span> exit\nrouter-a(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> exit\nrouter-a-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/2 proto ospf area 3\nrouter-a-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/2 proto ospf enable\n\n\nrouter-b-<span style=\"color: #0000ff\">&gt;<\/span> set vrouter &quot;trust-vr&quot;\nrouter-b(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set protocol ospf\nrouter-b(trust-vr\/ospf)-<span style=\"color: #0000ff\">&gt;<\/span> set area 3 stub\nrouter-b(trust-vr\/ospf)-<span style=\"color: #0000ff\">&gt;<\/span> exit\nrouter-b(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> exit\nrouter-b-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/0 proto ospf area 3 \nrouter-b-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/0 proto ospf enable\nrouter-b-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/1 proto ospf area 3\nrouter-b-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/1 proto ospf enable\nrouter-b-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/2 proto ospf area 3 \nrouter-b-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/2 proto ospf enable<\/p><p>&#160;<\/p>\n\n<p>router-d-<span style=\"color: #0000ff\">&gt;<\/span> set vrouter &quot;trust-vr&quot; \nrouter-d(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set protocol ospf \nrouter-d(trust-vr\/ospf)-<span style=\"color: #0000ff\">&gt;<\/span> set area 3 stub \nrouter-d(trust-vr\/ospf)-<span style=\"color: #0000ff\">&gt;<\/span> exit \nrouter-d(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> exit\nrouter-d-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/0 proto ospf area 3 \nrouter-d-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/0 proto ospf enable \nrouter-d-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/1 proto ospf area 3 \nrouter-d-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/1 proto ospf enable\nrouter-d-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/2 proto ospf area 3 \nrouter-d-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/2 proto ospf enable<\/p><p>&#160;<\/p>\n\n<p>router-e-<span style=\"color: #0000ff\">&gt;<\/span> set vrouter &quot;trust-vr&quot; \nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set protocol ospf \nrouter-e(trust-vr\/ospf)-<span style=\"color: #0000ff\">&gt;<\/span> set area 3 stub \nrouter-e(trust-vr\/ospf)-<span style=\"color: #0000ff\">&gt;<\/span> exit \nrouter-e(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> exit \nrouter-e-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/1 proto ospf area 3 \nrouter-e-<span style=\"color: #0000ff\">&gt;<\/span>set int eth0\/1 proto ospf enable<\/p><\/pre>\n<\/p><\/div>\n<p>That\u2019s it.&#160; Router A has now become a ABR (because it sits between area 0 and area 3, which is the stub area).&#160; 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.&#160; 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<\/p>\n<p>&#160;<\/p>\n<p>&#160;<\/p>\n<h3><\/h3>\n<h3>Totally stubby area<\/h3>\n<p>&#160;<\/p>\n<p>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\u2019s. 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 :<\/p>\n<div>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-a-<span style=\"color: #0000ff\">&gt;<\/span> set vr trust-vr protocol ospf area 3 no-summary<\/pre>\n<\/p><\/div>\n<p>All other routers in area 3 do not need to be changed.&#160; The ABR will take remove all summary LSAs from the LSDB and replace them with a default route. <\/p>\n<p>&#160;<\/p>\n<h3>Some other useful commands<\/h3>\n<\/p>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-a-<span style=\"color: #0000ff\">&gt;<\/span> get vrouter trust-vr protocol ospf\nrouter-a-<span style=\"color: #0000ff\">&gt;<\/span> get vrouter trust-vr protocol ospf database\nrouter-a-<span style=\"color: #0000ff\">&gt;<\/span> get vrouter trust-vr protocol ospf area 0\n\nrouter-a-<span style=\"color: #0000ff\">&gt;<\/span> debug ospf ?\nadj                  debug adcacency formation, teardown\nall                  all ospf debug\nase                  imported routes debug\nbasic                basic debug\nerror                error message debug\nhello                hello packet debug\nillegal              illegal debug\nimport               debug redistributing routes into OSPF\nlsa                  print lsa debugs\nnbr                  neighbor debug\nreceive              receive packets debug\nroute                ospf route addition, deletion\nsnmp                 snmp messages\nspf                  spf debug\ntask                 task blocking debug\ntransmit             transmit packets debug\ntrap                 trap debug<\/pre>\n<\/p>\n<p>&#160;<\/p>\n<p>&#160;<\/p>\n<h3>Securing OSPF<\/h3>\n<p>\n      <\/p>\n<h4>Define a list of approved neighbors<\/h4>\n<div>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 :<\/div>\n<div>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-a-<span style=\"color: #0000ff\">&gt;<\/span> set vrouter &quot;trust-vr&quot;\nrouter-a(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set access-list 5 permit ip 10.10.10.2\/32 10\nrouter-a(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> set access-list 5 permit ip 10.10.10.3\/32 20\nrouter-a(trust-vr)-<span style=\"color: #0000ff\">&gt;<\/span> exit\nrouter-a-<span style=\"color: #0000ff\">&gt;<\/span> set int e0\/1 protocol ospf neighbor-list 5<\/pre>\n<\/p><\/div>\n<p>&#160;<\/p>\n<h4>Enable md5 authentication<\/h4>\n<p>If you want to use md5 authentication between your OSPF routers, then use the following command on each OSPF enabled interface :<\/p>\n<div>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-a-<span style=\"color: #0000ff\">&gt;<\/span> set interface e0\/0 protocol ospf authentication md5 ThisIsMyMD5Password<\/pre>\n<\/p><\/div>\n<h4>\n      <br \/>Use passive interfaces<\/h4>\n<div>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)<\/div>\n<div>\n<pre style=\"padding-right: 0px; padding-left: 0px; font-size: 8pt; padding-bottom: 0px; margin: 0em; overflow: visible; width: 100%; color: black; border-top-style: none; line-height: 12pt; padding-top: 0px; font-family: consolas, &#39;Courier New&#39;, courier, monospace; border-right-style: none; border-left-style: none; background-color: #f4f4f4; border-bottom-style: none\">router-a-<span style=\"color: #0000ff\">&gt;<\/span> set int e0\/0 protocol ospf passive<\/pre>\n<\/p><\/div>\n<\/p>\n<\/p>\n<p>\n      <\/p>\n<p>&#160;<\/p>\n<\/p>\n<\/p>\n<\/dt>\n<\/li>\n","protected":false},"excerpt":{"rendered":"<p>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\u2019s) for directly connected links, and will forward LSAs received from other devices to ensure &hellip; <a href=\"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> \"Using OSPF on Juniper Netscreen Firewalls\"<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[554,164,127],"tags":[3742,3735],"class_list":["post-998","post","type-post","status-publish","format-standard","hentry","category-juniper","category-networking","category-security","tag-networking","tag-juniper-netscreen-screenos"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.5 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Using OSPF on Juniper Netscreen Firewalls - Corelan | Exploit Development &amp; Vulnerability Research<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Using OSPF on Juniper Netscreen Firewalls - Corelan | Exploit Development &amp; Vulnerability Research\" \/>\n<meta property=\"og:description\" content=\"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\u2019s) for directly connected links, and will forward LSAs received from other devices to ensure &hellip; Continue reading &quot;Using OSPF on Juniper Netscreen Firewalls&quot;\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/\" \/>\n<meta property=\"og:site_name\" content=\"Corelan | Exploit Development &amp; Vulnerability Research\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/corelanconsulting\" \/>\n<meta property=\"article:published_time\" content=\"2008-10-19T00:18:40+00:00\" \/>\n<meta name=\"author\" content=\"corelanc0d3r\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@corelanc0d3r\" \/>\n<meta name=\"twitter:site\" content=\"@corelanc0d3r\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"TechArticle\",\"@id\":\"https:\\\/\\\/www.corelan.be\\\/index.php\\\/2008\\\/10\\\/19\\\/using-ospf-on-juniper-netscreen-firewalls\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.corelan.be\\\/index.php\\\/2008\\\/10\\\/19\\\/using-ospf-on-juniper-netscreen-firewalls\\\/\"},\"author\":{\"name\":\"corelanc0d3r\",\"@id\":\"https:\\\/\\\/www.corelan.be\\\/#\\\/schema\\\/person\\\/3be5542b9b0a0787893db83a5ad68e8f\"},\"headline\":\"Using OSPF on Juniper Netscreen Firewalls\",\"datePublished\":\"2008-10-19T00:18:40+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.corelan.be\\\/index.php\\\/2008\\\/10\\\/19\\\/using-ospf-on-juniper-netscreen-firewalls\\\/\"},\"wordCount\":4055,\"publisher\":{\"@id\":\"https:\\\/\\\/www.corelan.be\\\/#organization\"},\"keywords\":[\"networking\",\"juniper netscreen screenos\"],\"articleSection\":[\"Juniper\",\"Networking\",\"Security\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.corelan.be\\\/index.php\\\/2008\\\/10\\\/19\\\/using-ospf-on-juniper-netscreen-firewalls\\\/\",\"url\":\"https:\\\/\\\/www.corelan.be\\\/index.php\\\/2008\\\/10\\\/19\\\/using-ospf-on-juniper-netscreen-firewalls\\\/\",\"name\":\"Using OSPF on Juniper Netscreen Firewalls - Corelan | Exploit Development &amp; Vulnerability Research\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.corelan.be\\\/#website\"},\"datePublished\":\"2008-10-19T00:18:40+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.corelan.be\\\/index.php\\\/2008\\\/10\\\/19\\\/using-ospf-on-juniper-netscreen-firewalls\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.corelan.be\\\/index.php\\\/2008\\\/10\\\/19\\\/using-ospf-on-juniper-netscreen-firewalls\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.corelan.be\\\/index.php\\\/2008\\\/10\\\/19\\\/using-ospf-on-juniper-netscreen-firewalls\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.corelan.be\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Using OSPF on Juniper Netscreen Firewalls\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.corelan.be\\\/#website\",\"url\":\"https:\\\/\\\/www.corelan.be\\\/\",\"name\":\"Corelan CyberSecurity Research\",\"description\":\"Corelan publishes in-depth tutorials on exploit development, Windows exploitation, vulnerability research, heap internals, reverse engineering and security tooling used by professionals worldwide.\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.corelan.be\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.corelan.be\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.corelan.be\\\/#organization\",\"name\":\"Corelan CyberSecurity Research\",\"url\":\"https:\\\/\\\/www.corelan.be\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.corelan.be\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.corelan.be\\\/wp-content\\\/uploads\\\/2026\\\/03\\\/corelanlogo2_small-20.png\",\"contentUrl\":\"https:\\\/\\\/www.corelan.be\\\/wp-content\\\/uploads\\\/2026\\\/03\\\/corelanlogo2_small-20.png\",\"width\":200,\"height\":200,\"caption\":\"Corelan CyberSecurity Research\"},\"image\":{\"@id\":\"https:\\\/\\\/www.corelan.be\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/corelanconsulting\",\"https:\\\/\\\/x.com\\\/corelanc0d3r\",\"https:\\\/\\\/x.com\\\/corelanconsulting\",\"https:\\\/\\\/instagram.com\\\/corelanconsult\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.corelan.be\\\/#\\\/schema\\\/person\\\/3be5542b9b0a0787893db83a5ad68e8f\",\"name\":\"corelanc0d3r\",\"pronouns\":\"he\\\/him\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/3783bed6acd72d7fa5bb2387d88acbb9a3403e7cada60b2037e1cbb74ad451f9?s=96&d=mm&r=x\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/3783bed6acd72d7fa5bb2387d88acbb9a3403e7cada60b2037e1cbb74ad451f9?s=96&d=mm&r=x\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/3783bed6acd72d7fa5bb2387d88acbb9a3403e7cada60b2037e1cbb74ad451f9?s=96&d=mm&r=x\",\"caption\":\"corelanc0d3r\"},\"description\":\"Peter Van Eeckhoutte is the founder of Corelan and a globally recognized expert in exploit development and vulnerability research. With over two decades in IT security, he built Corelan into a respected platform for deep technical research, hands-on training, and knowledge sharing. Known for his influential exploit development tutorials, tools, and real-world training, Peter combines a strong research mindset with a passion for education\u2014helping security professionals understand not just how exploits work, but why.\",\"sameAs\":[\"https:\\\/\\\/www.corelan-training.com\",\"https:\\\/\\\/instagram.com\\\/corelanc0d3r\",\"https:\\\/\\\/www.linkedin.com\\\/in\\\/petervaneeckhoutte\\\/\",\"https:\\\/\\\/x.com\\\/corelanc0d3r\"],\"url\":\"https:\\\/\\\/www.corelan.be\\\/index.php\\\/author\\\/admin0\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Using OSPF on Juniper Netscreen Firewalls - Corelan | Exploit Development &amp; Vulnerability Research","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/","og_locale":"en_US","og_type":"article","og_title":"Using OSPF on Juniper Netscreen Firewalls - Corelan | Exploit Development &amp; Vulnerability Research","og_description":"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\u2019s) for directly connected links, and will forward LSAs received from other devices to ensure &hellip; Continue reading \"Using OSPF on Juniper Netscreen Firewalls\"","og_url":"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/","og_site_name":"Corelan | Exploit Development &amp; Vulnerability Research","article_publisher":"https:\/\/www.facebook.com\/corelanconsulting","article_published_time":"2008-10-19T00:18:40+00:00","author":"corelanc0d3r","twitter_card":"summary_large_image","twitter_creator":"@corelanc0d3r","twitter_site":"@corelanc0d3r","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"TechArticle","@id":"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/#article","isPartOf":{"@id":"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/"},"author":{"name":"corelanc0d3r","@id":"https:\/\/www.corelan.be\/#\/schema\/person\/3be5542b9b0a0787893db83a5ad68e8f"},"headline":"Using OSPF on Juniper Netscreen Firewalls","datePublished":"2008-10-19T00:18:40+00:00","mainEntityOfPage":{"@id":"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/"},"wordCount":4055,"publisher":{"@id":"https:\/\/www.corelan.be\/#organization"},"keywords":["networking","juniper netscreen screenos"],"articleSection":["Juniper","Networking","Security"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/","url":"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/","name":"Using OSPF on Juniper Netscreen Firewalls - Corelan | Exploit Development &amp; Vulnerability Research","isPartOf":{"@id":"https:\/\/www.corelan.be\/#website"},"datePublished":"2008-10-19T00:18:40+00:00","breadcrumb":{"@id":"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.corelan.be\/index.php\/2008\/10\/19\/using-ospf-on-juniper-netscreen-firewalls\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.corelan.be\/"},{"@type":"ListItem","position":2,"name":"Using OSPF on Juniper Netscreen Firewalls"}]},{"@type":"WebSite","@id":"https:\/\/www.corelan.be\/#website","url":"https:\/\/www.corelan.be\/","name":"Corelan CyberSecurity Research","description":"Corelan publishes in-depth tutorials on exploit development, Windows exploitation, vulnerability research, heap internals, reverse engineering and security tooling used by professionals worldwide.","publisher":{"@id":"https:\/\/www.corelan.be\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.corelan.be\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.corelan.be\/#organization","name":"Corelan CyberSecurity Research","url":"https:\/\/www.corelan.be\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.corelan.be\/#\/schema\/logo\/image\/","url":"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/corelanlogo2_small-20.png","contentUrl":"https:\/\/www.corelan.be\/wp-content\/uploads\/2026\/03\/corelanlogo2_small-20.png","width":200,"height":200,"caption":"Corelan CyberSecurity Research"},"image":{"@id":"https:\/\/www.corelan.be\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/corelanconsulting","https:\/\/x.com\/corelanc0d3r","https:\/\/x.com\/corelanconsulting","https:\/\/instagram.com\/corelanconsult"]},{"@type":"Person","@id":"https:\/\/www.corelan.be\/#\/schema\/person\/3be5542b9b0a0787893db83a5ad68e8f","name":"corelanc0d3r","pronouns":"he\/him","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/3783bed6acd72d7fa5bb2387d88acbb9a3403e7cada60b2037e1cbb74ad451f9?s=96&d=mm&r=x","url":"https:\/\/secure.gravatar.com\/avatar\/3783bed6acd72d7fa5bb2387d88acbb9a3403e7cada60b2037e1cbb74ad451f9?s=96&d=mm&r=x","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/3783bed6acd72d7fa5bb2387d88acbb9a3403e7cada60b2037e1cbb74ad451f9?s=96&d=mm&r=x","caption":"corelanc0d3r"},"description":"Peter Van Eeckhoutte is the founder of Corelan and a globally recognized expert in exploit development and vulnerability research. With over two decades in IT security, he built Corelan into a respected platform for deep technical research, hands-on training, and knowledge sharing. Known for his influential exploit development tutorials, tools, and real-world training, Peter combines a strong research mindset with a passion for education\u2014helping security professionals understand not just how exploits work, but why.","sameAs":["https:\/\/www.corelan-training.com","https:\/\/instagram.com\/corelanc0d3r","https:\/\/www.linkedin.com\/in\/petervaneeckhoutte\/","https:\/\/x.com\/corelanc0d3r"],"url":"https:\/\/www.corelan.be\/index.php\/author\/admin0\/"}]}},"views":18095,"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.corelan.be\/index.php\/wp-json\/wp\/v2\/posts\/998","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.corelan.be\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.corelan.be\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.corelan.be\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.corelan.be\/index.php\/wp-json\/wp\/v2\/comments?post=998"}],"version-history":[{"count":0,"href":"https:\/\/www.corelan.be\/index.php\/wp-json\/wp\/v2\/posts\/998\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.corelan.be\/index.php\/wp-json\/wp\/v2\/media?parent=998"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.corelan.be\/index.php\/wp-json\/wp\/v2\/categories?post=998"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.corelan.be\/index.php\/wp-json\/wp\/v2\/tags?post=998"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}