| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
The feature called Dynamic Routing is implemented in cOS Core using the Open Shortest Path First (OSPF) architecture.
This section begins by looking generally at what dynamic routing is and how it can be implemented. It then goes on to look at how OSPF can provide dynamic routing followed by a description of how a simple OSPF network can be set up.
Before looking at OSPF in detail this section will discuss generally the concept of Dynamic routing and what type of dynamic routing OSPF provides. It introduces important concepts in dynamic routing and in OSPF.
Differences to Static Routing
Dynamic routing is different to static routing in that a routing network device is capable of adapting to changes of network topology automatically.Dynamic routing involves first learning about all the directly connected networks and then getting further routing information from other connected routers specifying which networks they are connected to. All this routing information is then processed and the most suitable routes for both locally connected and remotely connected destinations are added into local routing tables.
Dynamic routing responds to routing updates dynamically but has some disadvantages in that it can be more susceptible to certain problems such as routing loops. One of two types of algorithms are generally used to implement the dynamic routing mechanism:
A Distance Vector (DV) algorithm.
A Link State (LS) algorithm.
How a router decides the optimal or "best" route and shares updated information with other routers depends on the type of algorithm used. The two algorithm types will be discussed next.
Distance Vector Algorithms
A Distance vector algorithm is a decentralized routing algorithm that computes the best path in a distributed way.Each router in a network computes the "costs" of its own attached links, and shares routing information only with its neighboring routers. Each router determines the least-cost path to a destination by iterative computation and also using information exchanged with its neighbors.
Routing Information Protocol (RIP) is a well-known DV algorithm for router information exchange and operates by sending regular update messages and reflecting routing changes in routing tables. Path determination is based on the "length" of the path which is the number of intermediate routers (also known as "hops") to the destination.
After updating its own routing table, the router immediately begins transmitting its entire routing table to neighboring routers to inform them of changes.
Link State Algorithms
In contrast to DV algorithms, Link State (LS) algorithms enable routers to keep routing tables that reflect the topology of the entire network.Each router broadcasts its attached links and link costs to all other routers in the network. When a router receives these broadcasts it runs the LS algorithm and calculates its own set of least-cost paths. Any change of the link state will be sent everywhere in the network, so that all routers keep the same routing table information and have a consistent view of the network.
Advantages of Link State Algorithms
Due to the fact that the global link state information is maintained everywhere in a network, LS algorithms, like that used in OSPF, offer a high degree of configuration control and scalability. Changes result in broadcasts of just the updated information to other routers which means faster convergence and less possibility of routing loops. OSPF can also function within a hierarchy, whereas RIP has no knowledge of sub-network addressing.The OSPF Solution
Open Shortest Path First (OSPF) is a widely used protocol based on an LS algorithm. Dynamic routing is implemented in cOS Core using OSPF.An OSPF enabled router first identifies the routers and sub-networks that are directly connected to it and then broadcasts the information to all the other routers. Each router uses the information it receives to add the OSPF learned routes to its routing table.
With this larger picture, each OSPF router can identify the networks and routers that lead to a given destination IP and therefore the best route. Routers using OSPF then only broadcast updates to inform others of any route changes instead of broadcasting the entire routing table.
OSPF depends on various metrics for path determination, including hops, bandwidth, load and delay. OSPF can also provide a high level of control over the routing process since its parameters can be finely tuned.
A Simple OSPF Scenario
The simple network topology illustrated below provides an excellent example of what OSPF can achieve. Here we have two Clavister firewalls A and B connected together and configured to be in the same OSPF area (the concept of area will be explained later).OSPF allows firewall A to know that to reach network Y, traffic needs to be sent to firewall B. Instead of having to manually insert this routing information into the routing tables of A, OSPF allows B's routing table information to be automatically shared with A.
In the same way, OSPF allows firewall B to automatically become aware that network X is attached to firewall A.
Under OSPF, this exchange of routing information is completely automatic.
OSPF Provides Route Redundancy
If we now take the above scenario and add a third firewall called C then we have a situation where all three firewalls are aware, through OSPF, of what networks are attached to the other firewalls. This is illustrated below.In addition, we now have route redundancy between any two of the firewalls. For example, if the direct link between A and C fails then OSPF allows both firewalls to know immediately that there is an alternate route between them via firewall B.
For instance, traffic from network X which is destined for network Z will be routed automatically through firewall B.
From the administrator's point of view, only the routes for directly connected networks need to be configured on each firewall. OSPF automatically provides the required routing information to find networks connected to other firewalls, even if traffic needs to transit several other firewalls to reach its destination.
![[Tip]](images/tip.png) |
Tip: Ring topologies always provide alternate routes |
|---|---|
|
When designing the topology of a network that implements OSPF, arranging Clavister firewalls in a circular ring means that any firewall always has two possible routes to any other. Should any one inter-firewall connection fail, an alternative path always exists. |
Routing metrics are the criteria that a routing algorithm will use to compute the "best" route to a destination. A routing protocol relies on one or several metrics to evaluate links across a network and to determine the optimal path. The principal metrics used include:
Overview
Open Shortest Path First (OSPF) is a routing protocol developed for IP networks by the Internet Engineering Task Force (IETF). The cOS Core OSPF implementation is based upon RFC-2328, with compatibility to RFC-1583.OSPF functions by routing IP packets based only on the destination IP address found in the IP packet header. IP packets are routed "as is", in other words they are not encapsulated in any further protocol headers as they transit the Autonomous System (AS).
The Autonomous System
The term Autonomous System refers to a single network or group of networks with a single, clearly defined routing policy controlled by a common administrator. It forms the top level of a tree structure which describes the various OSPF components.In cOS Core, an AS corresponds to an OSPF Router object. This must be defined first when setting up OSPF. In most scenarios only one OSPF router is required to be defined and it must be defined separately on each Clavister firewall involved in the OSPF network. This cOS Core object is described further in Section 4.7.3.1, OSPF Router Process.
OSPF is a dynamic routing protocol as it quickly detects topological changes in the AS (such as router interface failures) and calculates new loop-free routes to destinations.
Link-state Routing
OSPF is a form of link-state routing (LS) that sends Link-state Advertisements (LSAs) to all other routers within the same area. Each router maintains a database, known as a Link-state Database, which maps the topology of the autonomous system (AS). Using this database, each router constructs a tree of shortest paths to other routers with itself as the root. This shortest-path tree yields the best route to each destination in the AS.Authentication.
All OSPF protocol exchanges can, if required, be authenticated. This means that only routers with the correct authentication can join an AS. Different authentication schemes can be used and with cOS Core the scheme can be either a passphrase or an MD5 digest.It is possible to configure separate authentication methods for each AS.
OSPF Areas
An OSPF Area consists of networks and hosts within an AS that have been grouped together. Routers that are only within an area are called internal routers. All interfaces on internal routers are directly connected to networks within the area.The topology of an area is hidden from the rest of the AS. This information hiding reduces the amount of routing traffic exchanged. Also, routing within the area is determined only by the area's own topology, lending the area protection from bad routing data. An area is a generalization of an IP subnetted network.
In cOS Core, areas are defined by OSPF Area objects and are added to the AS which is itself defined by an OSPF Router object. There can be more than one area within an AS so multiple OSPF Area objects could be added to a single OSPF Router. In most cases, one is enough and it should be defined separately on each Clavister firewall which will be part of the OSPF network.
This cOS Core object is described further in Section 4.7.3.2, OSPF Area.
OSPF Area Components
A summary of OSPF components related to an area is given below:Area Border Routers are routers that have interfaces connected to more than one area. These maintain a separate topological database for each area to which they have an interface.
Routers that exchange routing information with routers in other Autonomous Systems are called Autonomous System Boundary Routers. They advertise externally learned routes throughout the Autonomous System.
All OSPF networks need to have at least the Backbone Area which is the OSPF area with an ID of 0. This is the area that other related areas should be connected to. The backbone ensures routing information is distributed between connected areas. When an area is not directly connected to the backbone it needs a virtual link to it.
OSPF networks should be designed by beginning with the backbone.
Stub areas are areas through which or into which AS external advertisements are not flooded. When an area is configured as a stub area, the router will automatically advertise a default route so that routers in the stub area can reach destinations outside the area.
Transit areas are used to pass traffic from an area that is not directly connected to the backbone area.
The Designated Router
Each OSPF broadcast network has a single Designated Router (DR) and a single Backup Designated Router. The routers use OSPF Hello messages to elect the DR and BDR for the network based on the priorities advertised by all the routers. If there is already a DR on the network, the router will accept that one, regardless of its own router priority.With cOS Core, the DR and the BDR are automatically assigned.
Neighbors
Routers that are in the same area become neighbors in that area. Neighbors are elected by the use of Hello messages. These are sent out periodically on each interface using IP multicast. Routers become neighbors as soon as they see themselves listed in a neighbor's Hello message. In this way, a two way communication is guaranteed.The following Neighbor States are defined:
This is the initial state of the neighbor relationship.
When a Hello message is received from a neighbor, but does NOT include the Router ID of the firewall in it, the neighbor will be placed in the Init state.
As soon as the neighbor in question receives a Hello message it will know the sending router's Router ID and will send a Hello message with that included. The state of the neighbors will change to the 2-way state.
In this state the communication between the router and the neighbor is bidirectional.
On Point-to-Point and Point-to-Multipoint OSPF interfaces, the state will be changed to Full. On Broadcast interfaces, only the DR/BDR will advance to the Full state with their neighbors, all the remaining neighbors will remain in the 2-Way state.
Preparing to build adjacency.
Routers are exchanging Data Descriptors.
Routers are exchanging LSAs.
This is the normal state of an adjacency between a router and the DR/BDR.
Aggregates
OSPF Aggregation is used to combine groups of routes with common addresses into a single entry in the routing table. This is commonly used to minimize the routing table.To set this feature up in cOS Core, see Section 4.7.3.5, OSPF Aggregates.
Virtual Links
Virtual links are used for the following scenarios:A. Linking an area that does not have a direct connection to the backbone area.
B. Linking backbone areas when the backbone is partitioned.
The two uses are discussed next.
A. Linking areas without direct connection to the backbone
The backbone area always needs to be the center of all other areas. In some rare cases where it is impossible to have an area physically connected to the backbone, a Virtual Link is used. Virtual links can provide an area with a logical path to the backbone area.This virtual link is established between two Area Border Routers (ABRs) that are on one common area, with one of the ABRs connected to the backbone area. In the example below two routers are connected to the same area (Area 1) but just one of them, fw1, is connected physically to the backbone area.
In the above example, a Virtual Link is configured between fw1 and fw2 on Area 1 as it is used as the transit area. In this configuration only the Router ID has to be configured. The diagram shows that fw2 needs to have a Virtual Link to fw1 with Router ID 192.168.1.1 and vice versa. These virtual links need to be configured in Area 1.
B. Linking a Partitioned Backbone
OSPF allows for linking a partitioned backbone using a virtual link. The virtual link should be configured between two separate ABRs that touch the backbone from each side and have a common area in between.The virtual link is configured between fw1 and fw2 on Area 1 as it is used as the transit area. In the configuration, only the Router ID has to be configured, as in the example above show fw2 need to have a virtual link to fw1 with the Router ID 192.168.1.1 and vice versa. These virtual links need to be configured in Area 1.
To set this feature up in cOS Core, see Section 4.7.3.6, OSPF VLinks.
OSPF High Availability Support
There are some limitations in High Availability support for OSPF that should be noted:Both the active and the inactive part of an HA cluster will run separate OSPF processes, although the inactive part will make sure that it is not the preferred choice for routing. The HA master and slave will not form adjacency with each other and are not allowed to become DR/BDR on broadcast networks. This is done by forcing the router priority to 0.
For OSPF HA support to work correctly, the Clavister firewall needs to have a broadcast interface with at least ONE neighbor for ALL areas that the firewall is attached to. In essence, the inactive part of the cluster needs a neighbor to get the link state database from.
It should also be noted that is not possible to put an HA cluster on the same broadcast network without any other neighbors (they will not form adjacency with each other because of the router priority 0). However, it may be possible, depending on the scenario, to set up a point to point link between them instead. Special care must also be taken when setting up a virtual link to an firewall in an HA cluster. The endpoint setting up a link to the HA firewall must set up 3 separate links: one to the shared, one to the master and one to the slave router ID of the firewall.
Using OSPF with cOS Core
When using OSPF with cOS Core, the scenario will be that we have two or more Clavister firewalls connected together in some way. OSPF allows any of these firewalls to be able to correctly route traffic to a destination network connected to another firewall without having a route in its routing tables for the destination.The key aspect of an OSPF setup is that connected firewalls will share the information in their routing tables so that traffic entering an interface on one of the firewalls can be automatically routed so that it exits the interface on another gateway which is attached to the correct destination network.
Another important aspect is that the firewalls monitor the connections between each other and route traffic by an alternate connection if one is available. A network topology can therefore be designed to be fault tolerant. If a connection between two firewalls fails then any alternate route that also reaches the destination will be used.
This section looks at the cOS Core objects that need to be configured for OSPF routing. Defining these objects creates the OSPF network. The objects should be defined on each Clavister firewall that is part of the OSPF network and should describe the same network.
An illustration of the relationship between cOS Core OSPF objects is shown below.
This object defines the autonomous system (AS) which is the top level of the OSPF network. A similar Router Process object should be defined on each firewall which is part of the OSPF network.
General Parameters
Specifies a symbolic name for the OSPF AS.
Specifies the IP address that is used to identify the router in a AS. If no Router ID is configured, the firewall computes the Router ID based on the highest IP address of any interface participating in the OSPF AS.
This is used in an HA cluster and is the ID for this firewall and not the cluster.
![[Note]](images/note.png) |
Note |
|---|---|
| When running OSPF on a HA Cluster there is a need for a private master and private slave Router ID as well as the shared Router ID. |
Set the reference bandwidth that is used when calculating the default interface cost for routes.
If bandwidth is used instead of specifying a metric on an OSPF Interface, the cost is calculated using the following formula:
cost = reference bandwidth / bandwidth
Enable this if the Clavister firewall will be used in an environment that consists of routers that only support RFC-1583.
Debug
The debug options provides a troubleshooting tool by enabling the generation of additional OSPF log events. These are described more fully in Section 4.7.7, OSPF Troubleshooting.
Authentication
The primary purpose of OSPF authentication is to make sure that the correct OSPF router processes are talking to each and it is therefore mostly used when there are multiple OSPF AS'. OSPF supports the following authentication options:
No authentication is used for OSPF protocol exchanges.
A simple password is used to authenticate all the OSPF protocol exchanges.
MD5 authentication consists of a key ID and 128-bit key. When MD5 digest is used the specified key is used to produce the 128-bit MD5 digest.
This does NOT mean that the OSPF packets are encrypted. If the OSPF traffic needs to be encrypted then they must be sent using a VPN. For example, using IPsec. Sending OSPF packets through an IPsec tunnel is discussed further in Section 4.7.5, Setting Up OSPF.
![[Important]](images/important.png) |
Note: Authentication must be the same on all routers |
|---|---|
|
If a passphrase or MD5 authentication is configured for OSPF, the passphrase or authentication key must be the same on all OSPF Routers in that Autonomous System. In other words, the OSPF authentication method must be replicated on all firewalls. |
Advanced
Time Settings
Specifies the minimum time, in seconds, between two SPF calculations. The default time is 10 seconds. A value of 0 means that there is no delay. Note however that SPF can potentially be a CPU demanding process, so in a big network it may not be a good idea to run it too frequently.
Specifies the delay time, in seconds, between when OSPF receives a topology change and when it starts an SPF calculation. The default time is 5 seconds. A value of 0 means that there is no delay. Note however that SPF can potentially be a CPU demanding process, so in a big network it might not be a good idea to run it too often.
This specifies the time in seconds at which interval the OSPF LSAs are collected into a group and refreshed. It is more optimal to group many LSAs and process them at the same time, instead of running them one and one.
This specifies the time in seconds that the routing table will be kept unchanged after a reconfiguration of OSPF entries or a HA failover.
Memory Settings
Maximum amount in Kilobytes of RAM that the OSPF AS process are allowed to use, if no value is specified the default is 1% of installed RAM. Specifying 0 indicates that the OSPF AS process is allowed to use all available ram in the firewall.
The Autonomous System (AS) is divided into smaller parts called an Area, this section explains how to configure areas. An area collects together OSPF interfaces, neighbors, aggregates and virtual links.
An OSPF Area is a child of the OSPF Router Process and there can be many area objects defined under a single router process. In most simple networking scenarios, a single area is sufficient. Like the router process object, a similar area object should be defined on all the firewalls which will be part of the OSPF network.
General Parameters
Specifies the name of the OSPF Area.
Specifies the area id. If 0.0.0.0 is specified then this is the backbone area.
There can only be one backbone area and it forms the central portion of an AS. Routing information that is exchanged between different areas always transits the backbone area.
Enable this option if the area is a stub area.
It is possible to configure if the firewall should become the default router for the stub area, and with what metric.
Import Filter
The import filter is used to filter what can be imported in the OSPF AS from either external sources (like the main routing table or a policy based routing table) or inside the OSPF area.Specifies the network addresses allowed to be imported into this OSPF area from external routing sources.
Specifies the network addresses allowed to be imported from other routers inside the OSPF area.
This section describes how to configure an OSPF Interface object. OSPF interface objects are children of OSPF areas. Unlike areas, they are not similar on each firewall in the OSPF network. The purpose of an OSPF interface object is to describe a specific interface which will be part of an OSPF network.
|
Note: Different interface types can be used with OSPF interfaces |
|---|---|
|
Note that an OSPF Interface does not always correspond to a physical interface although this is the most common usage. Other types of interfaces, such as a VLAN, could instead be associated with an OSPF Interface. |
General Parameters
Specifies which interface on the firewall will be used for this OSPF interface.
Specifies the IPv4 network address for this OSPF interface. If is not specified it defaults to the network assigned to the underlying cOS Core interface.
This network is automatically exported to the OSPF AS and does not require a Dynamic Routing Rule.
This can be one of the following:
Auto - Tries to automatically detect interface type. This can be used for physical interfaces.
Broadcast - The Broadcast interface type is an interface that has native Layer 2 broadcast/multicast capabilities. The typical example of a broadcast/multicast network is an ordinary physical Ethernet interface.
When broadcast is used, OSPF will send OSPF Hello packets to the IP multicast address 224.0.0.5. Those packets will be heard by all other the OSPF routers on the network. For this reason, no configuration of OSPF Neighbor objects is required for the discovery of neighboring routers.
Point-to-Point - Point-to-Point is used for direct links which involve only two routers (in other words, two firewalls). A typical example of this is a VPN tunnel which is used to transfer OSPF traffic between two firewalls. The neighbor address of such a link is configured by defining an OSPF Neighbor object.
Using VPN tunnels is discussed further in Section 4.7.5, Setting Up OSPF.
Point-to-Multipoint - The Point-to-Multipoint interface type is a collection of Point-to-Point networks, where there is more than one router in a link that does not have OSI Layer 2 broadcast/multicast capabilities.
Specifies the metric for this OSPF interface. This represents the "cost" of sending packets over this interface. This cost is inversely proportional to the bandwidth of the interface.
If the metric is not specified, the bandwidth is specified instead. If the bandwidth is known then this can be specified directly instead of the metric.
Authentication
All OSPF protocol exchanges can be authenticated using a simple password or MD5 cryptographic hashes.
If Use Default for Router Process is enabled then the values configured in the router process properties are used. If this is not enabled then the following options are available:
Advanced
Unless an interface is being used by the OSPF router process to connect to another OSPF router, this option should be enabled. In the Web Interface or InControl the option is called No OSPF routers connected to this interface.
When enabled, no OSPF traffic will be generated on the interface.
Specifies the number of seconds between Hello packets sent on the interface.
If not Hello packets are received from a neighbor within this interval then that neighbor router will be considered to be out of operation.
Specifies the number of seconds between retransmissions of LSAs to neighbors on this interface.
Specifies the estimated transmit delay for the interface. This value represents the maximum time it takes to forward a LSA packet through the router.
Specifies the number of seconds between the interface brought up and the election of the DR and BDR. This value should be higher than the hello interval.
Specifies the router priority, a higher number increases this router's chance of becoming a DR or a BDR. If 0 is specified then this router will not be eligible in the DR/BDR election.
|
Note |
|---|---|
|
An HA cluster will always have 0 as router priority, and can never be used as a DR or BDR. |
Sometimes there is a need to include networks into the OSPF router process, without running OSPF on the interface connected to that network. This is done by enabling the Passive option: No OSPF routers connected to this interface ("Passive").
This is an alternative to using a Dynamic Routing Policy to import static routes into the OSPF router process.
If the Ignore received OSPF MTU restrictions is enabled, OSPF MTU mismatches will be allowed.
The Ethernet interfaces that are also OSPF interfaces must operate in promiscuous mode for OSPF to function. This mode means that traffic with a destination MAC address that does not match the Ethernet interface's MAC address will be sent to cOS Core and not discarded by the interface. Promiscuous mode is enabled automatically by cOS Core and the administrator does not need to worry about doing this.If the administrator enters a CLI command ifstat <ifname>, the Receive Mode status line will show the value Promiscuous next to it instead of Normal to indicate the mode has changed. This is discussed further in Section 3.4.2, Ethernet Interfaces.
In some scenarios, the neighboring OSPF router to the firewall needs to be explicitly defined. For example, when the connection is not between physical interfaces.
The most common situation for using this is when a VPN tunnel is used to connect two neighbors and we need to tell cOS Core that the OSPF connection needs to be made through the tunnel. This type of VPN usage with IPsec tunnels is described further in Section 4.7.5, Setting Up OSPF.
Configuration in cOS Core
cOS Core OSPF Neighbor objects are created within an OSPF Area and each object has the following property parameters:Specifies which OSPF interface the neighbor is located on.
The IP Address of the neighbor. This is the IP Address of the neighbors OSPF interface connecting to this router. For VPN tunnels this will be the IP address of the tunnel's remote end.
Specifies the metric to this neighbor.
OSPF Aggregation is used to combine groups of routes with common addresses into a single entry in the routing table. The following are the advantages of aggregation:
If advertised, aggregation will decrease the size of the routing table in the firewall (a primary function of the feature).
If not advertised the aggregated networks will be hidden.
OSPF related traffic is reduced.
Configuration in cOS Core
To aggregate routes, cOS Core OSPF Aggregate objects are created for an OSPF Area. Each of these objects has the following parameters:The network, consisting of the smaller routers.
If the aggregation should be advertised or not.
A Usage Example
In most, simple OSPF scenarios, OSPF Aggregate objects will not be needed. OSPF aggregation is only used when the Clavister firewall is acting as an Area Border Router (ABR) which is linking two or more OSPF areas. The diagram below illustrates a typical example of how aggregation would be used.Here, the three routes on Area 0 can be collapsed into one by setting up an OSPF Aggregate object for the network 192.168.0.0/24 on Area 1.
All areas in an OSPF AS must be physically connected to the backbone area (the area with ID 0). In some cases this is not possible and in that case a Virtual Link (VLink) can be used to connect to the backbone through a non-backbone area.
cOS Core OSPF VLink objects are created within an OSPF Area and each object has the following parameters:
General Parameters
Symbolic name of the virtual link.
The Router ID of the router on the other side of the virtual link.
Authentication
Use the values configured in the AS properties page.
|
Note: Linking partitioned backbones |
|---|---|
|
If the backbone area is partitioned, a virtual link is used to connect the different parts. |
In most, simple OSPF scenarios, OSPF VLink objects will not be needed.
This section examines Dynamic Routing Rules. These rules determine which routes can be exported to an OSPF AS from the local routing tables and which can be imported into the local routing tables from the AS.
The Final OSPF Setup Step is Creating Dynamic Routing Rules
After the OSPF structure is created, the final step is always to create a Dynamic Routing Rule on each firewall which allows the routing information that the OSPF AS delivers from remote firewalls to be added to the local routing tables.Dynamic routing rules are discussed here in the context of OSPF, but can also be used in other contexts.
The Reasons for Dynamic Routing Rules
In a dynamic routing environment, it is important for routers to be able to regulate to what extent they will participate in the routing exchange. It is not feasible to accept or trust all received routing information, and it might be crucial to avoid parts of the routing database getting published to other routers.For this reason, Dynamic Routing Rules are used to regulate the flow of routing information.
These rules filter either statically configured or OSPF learned routes according to parameters like the origin of the routes, destination, metric and so on. The matched routes can be controlled by actions to be either exported to OSPF processes or to be added to one or more routing tables.
Usage with OSPF
Dynamic Routing Rules are used with OSPF to achieve the following:Allowing the import of routes from the OSPF AS into local routing tables.
Allowing the export of routes from a local routing tables to the OSPF AS.
Allowing the export of routes from one OSPF AS to another OSPF AS.
|
Note |
|---|---|
|
The last usage of joining asynchronous systems together is rarely encountered except in very large networks. |
OSPF Requires at Least an Import Rule
By default, cOS Core will not import or export any routes. For OSPF to function, it is therefore mandatory to define at least one dynamic routing rule which will be an Import rule.This Import rule specifies the local OSPF Router Process object. This enables the external routes made available in the OSPF AS to be imported into the local routing tables.
Specifying a Filter
Dynamic routing rules allow a filter to be specified which narrows the routes that are imported based on the network reached. In most cases, the Or is within option should be specified as all-nets so that no filter is applied to this route.When to Use Export Rules
Although an Import rule is needed to import routes from the OSPF AS, the opposite is not true. The export of routes to networks that are part of OSPF Interface objects are automatic.A dynamic routing export rule must be created to explicitly export the route to the OSPF AS.
Preventing Import/Export of the all-nets Route
By specifying a value of 0.0.0.1-255.255.255.255 for the Or is within option in routing rules, the all-nets (0.0.0.0/0) route can be excluded from import/export.Preventing import/export of all-nets routes is discussed further in an article in the Clavister Knowledge Base at the following link:
https://kb.clavister.com/324736100
Dynamic Routing Rule Objects
The diagram below shows the relationship between the cOS Core dynamic routing rule objects.This object defines a dynamic routing rule.
General Parameters
Specifies a symbolic name for the rule.
Specifies the from which OSPF AS (in other words, an OSPF Router Process) the route should be imported from into either a routing table or another AS.
Specifies from which routing table a route should be imported into the OSPF AS or copied into another routing table.
Specifies if the rule has to have a match to a certain destination interface.
Destination Network
Specifies if the network needs to exactly match a specific network.
Specifies if the network needs to be within a specific network.
More Parameters
Specifies what the next hop (in other words, router) needs to be for this rule to be triggered.
Specifies an interval that the metric of the routers needs to be in between.
Specifies if the rule should filter on Router ID.
Specifies if the rule should filter on the OSPF Router Type.
Specifies an interval that the tag of the routers needs to be in between.
This object defines an OSPF action.
General Parameters
Specifies into which OSPF AS the route change should be imported.
If needed, specifies the IP to route via.
Specifies a tag for this route. This tag can be used in other routers for filtering.
Specifies what kind of external route type. Specify 1 if OSPF should regard external routes as type 1 OSPF routes. Type 2 is the most significant cost of a route.
Increases the metric of an imported route by this value.
Limits the metrics for these routes to a minimum and maximum value. If a route has a higher or lower value than specified then it will be set to the specified value.
A Routing Action is used to manipulate and export routing changes to one or more local routing tables.
Specifies into which routing table the route changes to the OSPF AS should be imported.
Increases the metric by this value.
Increases the Type 2 router's metric by this value.
Limits the metrics for these routes to a minimum and maximum value. If a route has a higher value than specified then it will be set to the specified value.
Allows the override of the static routes.
Allows the override of the default route.
Setting up OSPF can seem complicated because of the large number of configuration possibilities that OSPF offers. However, in many cases a simple OSPF solution using a minimum of cOS Core objects is needed and setup can be straightforward.
Let us examine again the simple scenario described earlier with just two Clavister firewalls.
In this example we connect together the two firewalls with OSPF so they can share the routes in their routing tables. Both will be inside a single OSPF area which will be part of a single OSPF autonomous system (AS). If unfamiliar with these OSPF concepts, please refer to earlier sections for further explanation.
Beginning with just one of these firewalls, the cOS Core setup steps are as follows:
1. Create an OSPF Router object
Create OSPF Router Process object in cOS Core. This will represent an OSPF Autonomous Area (AS) which is the highest level in the OSPF hierarchy. Give the object an appropriate name. The Router ID can be left blank since this will be assigned automatically by cOS Core.
2. Add an OSPF Area to the OSPF Router
Within the OSPF Router Process created in the previous step, add a new OSPF Area object. Assign an appropriate name and use the value 0.0.0.0 for the Area ID.
An AS can have multiple areas but in many cases only one is needed. The ID 0.0.0.0 identifies this area as the backbone area which forms the central portion of the AS.
3. Add OSPF Interfaces to the OSPF Area
Within the OSPF Area created in the previous step, add a new OSPF Interface for each physical interface that will be part of the area.
The OSPF Interface object needs the following parameters specified in its properties:
Interface - the physical interface which will be part of the OSPF area.
Network - the network on the interface that will be part of the area.
This does not need to be specified and if it is not, the network assigned to the physical interface is used. For example if lan is the interface then lan_net will be the default network.
Interface Type - this would normally be Auto so that the correct type is automatically selected.
The Passive option No OSPF routers connected to this interface must be enabled if the physical interface does not connect directly to another OSPF Router (in other words, with another Clavister firewall that acts as an OSPF router). For example, the interface may only be connected to a network of clients, in which case the option would be enabled.
The option must be disabled if the physical interface is connected to another firewall which is set up as an OSPF Router. In this example, the physical interface connected to the other firewall would have this option disabled.
4. Add a Dynamic Routing Rule
Finally, a Dynamic Routing Rule needs to be defined to deploy the OSPF network. This involves two steps:
A Dynamic Routing Policy Rule object is added. This rule should be an Import rule that enables the option From OSPF Process so that the previously defined OSPF Router Process object is selected. What we are doing is saying that we want to import all routes from the OSPF AS.
In addition, the optional Or is within filter parameter for the destination network must be set to be all-nets. We could use a narrower filter for the destination network but in this case we want all networks.
Within the Dynamic Routing Policy Rule just added, we now add a Routing Action object. Here we add the routing table into the Selected list which will receive the routing information from OSPF.
In the typical case this will be the routing table called main.
There is no need to have a Dynamic Routing Policy Rule which exports the local routing table into the AS since this is done automatically for OSPF Interface objects.
The exception to this is if a route involves an ISP gateway (in other words, a router hop). In this case the route MUST be explicitly exported. The most frequent case when this is necessary is for the all-nets route to the external Internet where the gateway is the ISP's router. Doing this is discussed in the next step.
5. Add a Dynamic Routing Rule for all-nets
Optionally, a Dynamic Routing Rule needs to be defined if any routes except the OSPF Interface routes are to be exported. This involves the following steps
A Dynamic Routing Policy Rule object is added. This rule should be an Export rule that enables the option From Routing Table with the main routing table moved to the Selected list.
In addition, the optional Or is within filter parameter for the destination network must be set to be all-nets. This means all routes will be exported.
Within the Dynamic Routing Policy Rule just added, we now add an OSPF Action object. Here set the Export to process option to be the OSPF Router Process which represents the OSPF AS.
6. Repeat these steps on the other firewall
Now repeat steps 1 to 5 for the other firewall that will be part of the OSPF AS and area. The OSPF Router and OSPF Area objects will be identical on each. The OSPF Interface objects will be different depending on which interfaces and networks will be included in the OSPF system.
If more than two firewalls will be part of the same OSPF area then all of them should be configured similarly.
OSPF Routing Information Exchange Begins Automatically
As the new configurations are created in the above steps and then deployed, OSPF will automatically start and begin exchanging routing information. Since OSPF is a dynamic and distributed system, it does not matter in which order the configurations of the individual firewalls are deployed.When the physical link is plugged in between two interfaces on two different firewalls and those interfaces are configured with OSPF Router Process objects, OSPF will begin exchanging routing information.
Confirming OSPF Deployment
It is now possible to check that OSPF is operating and that routing information is exchanged.This can be done by examining the routing tables. Routes that have been imported into the routing tables though OSPF are indicated with the letter "O" to the left of the route description. For example, the routes command might give the following output:
Device:/> routes
Flags Network Iface Gateway Local IP Metric
----- --------------- ----------- --------------- ---------- ------
192.168.1.0/24 lan 0
172.16.0.0/16 wan 0
O 192.168.2.0/24 wan 172.16.2.1 1Here, the route for 192.168.2.0/24 has been imported via OSPF and that network can be found on the WAN interface with the gateway of 172.16.2.1. The gateway in this case is of course the firewall to which the traffic should be sent. That firewall may or may not be attached to the destination network but OSPF has determined that that is the optimum route to reach it.
The CLI command ospf can also be used to indicate OSPF status. The options for this command are fully described in the CLI Reference Guide.
Sending OSPF Traffic Through a VPN Tunnel
In some cases, the link between two Clavister firewalls which are configured with OSPF Router Process objects may be insecure. For example, over the Internet.In this case, we can secure the link by setting up a VPN tunnel, such as an IPsec tunnel, between the two firewalls and telling OSPF to use this tunnel for the exchange of OSPF information.
Note that setting up OSPF over IPsec is also discussed in an article in the Clavister Knowledge Base at the following link:
https://kb.clavister.com/324735930
Consider the set up illustrated below and and assume that IPsec will be used for implementing the tunnel.
To create this setup we need to perform the normal OSPF steps described above but with the following additional steps:
1. Set up an IPsec tunnel
First set up an IPsec tunnel in the normal way between the two firewalls A and B. The IPsec setup options are explained in Section 10.2, VPN Quick Start.
This IPsec tunnel is now treated like any other interface when configuring OSPF in cOS Core.
2. Choose a random internal IP network
For each firewall, we need to choose a random IP network using internal, private IPv4 addresses. For example, for firewall A we could use the network 192.168.55.0/24.
This network is used just as a convenience with OSPF setup and will never be associated with a real physical network.
3. Define an OSPF Interface for the tunnel
Define an OSPF Interface object which has the IPsec tunnel for the Interface parameter. Specify the Type parameter to be point-to-point and the Network parameter to be the network chosen in the previous step, 192.168.55.0/24.
This OSPF Interface tells cOS Core that any OPSF related connections to addresses within the network 192.168.55.0/24 should be routed into the IPsec tunnel.
4. Define an OSPF Neighbor
Next, we must explicitly tell OSPF how to find the neighboring OSPF router. Do this by defining an OSPF Neighbor object. This consists of a pairing of the IPsec tunnel (which is treated like an interface) and the IP address of the router at the other end of the tunnel.
For the IPv4 address of the router, we simply use any single IP address from the network 192.168.55.0/24. For example, 192.168.55.1.
When cOS Core sets up OSPF, it will look at this OSPF Neighbor object and will try to send OSPF messages to the IPv4 address 192.168.55.1. The OSPF Interface object defined in the previous step tells cOS Core that OSPF related traffic to this IP address should be routed into the IPsec tunnel.
5. Set the Local IP of the tunnel endpoint
To finish the setup for firewall A there needs to be two changes made to the IPsec tunnel setup on firewall B. These are:
In the IPsec tunnel properties, the Local Network for the tunnel needs to be set to all-nets. This setting acts as a filter for what traffic is allowed into the tunnel and all-nets will allow all traffic into the tunnel.
In the routing section of the IPsec properties, the Specify address manually option needs to be enabled and the IPv4 address in this example of 192.168.55.1 needs to be entered (in the CLI, OriginatorType is set to manual and the OriginatorIP is 192.168.55.1). This sets the tunnel endpoint IP to be 192.168.55.1 so that all OSPF traffic will be sent to firewall A with this source IP.
The result of doing this is to "core route" OSPF traffic coming from firewall A. In other words, the traffic is destined for cOS Core.
6. Repeat the steps for the other firewall
What has been done so far is to allow OSPF traffic to flow from A to B. The steps above need to be repeated as a mirror image for firewall B using the same IPsec tunnel. The same random internal IP network for OSPF setup should be used on both A and B.
|
Tip: Non-OSPF traffic can also use the tunnel |
|---|---|
|
A VPN tunnel can carry both OSPF traffic as well as other types of traffic. There is no requirement to dedicate a tunnel to OSPF traffic. |
This section goes through the detailed setup steps for the simple OSPF scenario illustrated below.
Here, two identical Clavister firewalls called A and B are joined together directly via their If3 interfaces. Each has a network of hosts attached to its If1 interface. On one side, If1_net is the IPv4 network 10.4.0.0/16 and on the other side it is the IPv4 network 192.168.0.0/24.
The goal is to configure OSPF on both firewalls so routing information is automatically exchanged and traffic can be correctly routed between the 10.4.0.0/16 network and the 192.168.0.0/24 network. The IP rule set entries that are needed to allow such traffic to flow are not included in this example.
Example 4.10. Creating an OSPF Router Process
First the Autonomous System (AS) must be defined on both firewalls.
On firewall A, create an OSPF Router Process object. Assume the object name will be as_0.
Command-Line Interface
Device:/> add OSPFProcess as_0InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Now, repeat this for firewall B, using the same OSPF Router Process object name of as_0.
Example 4.11. Add an OSPF Area
Now add an OSPF Area object to the OSPF Router Process object as_0 on firewall A. This area will be the OSPF backbone area and will therefore have the ID 0.0.0.0. Assume the name for the area object will be area_0.
Command-Line Interface
First, change the CLI context to be the OSPFProcess object created above:
Device:/> cc OSPFProcess as_0Now, add the area:
Device:/as_0> add OSPFArea area_0 AreaID=0.0.0.0This new OSPFArea object can be displayed with the command:
Device:/as_0> show
OSPFArea/
Name Area ID Comments
---- ------- --------
! area_1 0.0.0.0 <empty>
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Now, repeat this for firewall B, using the same OSPF Area object name of area_0.
Example 4.12. Add OSPF Interface Objects
For firewall A, add OSPF Interface objects for each physical interface that is to be part of the OSPF area called area_0.
Command-Line Interface
Assume the context is still the OSPFProcess called as_0 from the last example. Now, change the context to be the OSPFArea that was created previously:
Device:/as_0> cc area_0Next, add the OSPFInterface object:
Device:/as_0/area_0> add OSPFInterface If1 Passive=YesEnabling the Passive option means that this interface is not connected to another OSPF router. Finally, return to the default CLI context:
Device:/as_0/area_0>ccDevice:/>
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Just selecting the Interface means that the Network defaults to the network bound to that interface. In this case If1_net.
This should be repeated for all interfaces that will be part of the OSPF area. In this case, the interface If3 must also be added as an OSPFInterface but the Passive property should be left at its default value of enabled since this interface is connected to another router.
firewall B, should then be set up in the same way.
Example 4.13. Import Routes from an OSPF AS into the Main Routing Table
In this example, the routes received using OSPF will be added into the main routing table. To do this, a Dynamic Routing Policy Rule first needs to be created. In this example, the rule is called ImportOSPFRoutes.
The rule must specify from what OSPF AS the routes should be imported. In this example, the OSPF AS configured above, with the name as_0, is used.
Depending on the routing topology, it may be preferable to just import certain routes using the Destination Interface/Destination Network filters, but in this scenario all routes that are within the all-nets network object are allowed.
The steps are first performed for firewall A.
Command-Line Interface
Device:/> add DynamicRoutingRule
OSPFProcess=as_0
Name=ImportOSPFRoutes
DestinationNetworkIn=all-netsInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Now, create a Dynamic Routing Action that will import routes into the routing table. The destination routing table that the routes should be added to is main.
Command-Line Interface
First, change the CLI context to be the DynamicRoutingRule just added for import:
Device:/> cc DynamicRoutingRule ImportOSPFRoutesNext, add a DynamicRoutingRuleAddRoute object:
Device:/1(ImportOSPFRoutes)> add DynamicRoutingRuleAddRoute
Destination=main
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
The same procedure should be repeated for firewall B.
Example 4.14. Exporting the Routes into an OSPF AS
In this example, routes from the main routing table will be exported into an OSPF AS named as_0. This must be done explicitly because routes are not exported automatically.
The exception to this are the routes for the OSPF interface networks which are exported automatically (in this example If1_net and If3_net).
The steps are first performed for firewall A.
First, add a new Dynamic Routing Policy Rule.
Command-Line Interface
Device:/> add DynamicRoutingRule
OSPFProcess=as_0
Name=ExportDefRoute
DestinationNetworkIn=all-nets
DestinationInterface=If3
From=RTable
RoutingTable=mainInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Next, create an OSPF Action that will export the filtered route to the specified OSPF AS:
Command-Line Interface
First, change the CLI context to be the DynamicRoutingRule just added for export:
Device:/> cc DynamicRoutingRule ExportDefRouteNext, add a DynamicRoutingRuleExportOSPF object:
Device:/2(ExportDefRoute)> add DynamicRoutingRuleExportOSPF
ExportToProcess=as_0
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
The same procedure should be repeated for firewall B.
There are two special ways of troubleshooting OSPF issues:
These are discussed next.
Additional OSPF Log Event Messages
By default, a range of basic log event messages are generated by OSPF operation within cOS Core. For example, if the OSPFProcess object running under cOS Core is called my_ospf_proc, normal log generation would be enabled with the CLI command:Device:/> set OSPFProcess my_ospf_proc LogEnabled=YesThe following properties can be enabled to provide additional OSPF log messages for troubleshooting and/or monitoring purposes:
DebugPacket - Log general packet parsing events.
DebugHello - Log Hello packets.
DebugDDesc - Log database description packets.
DebugExchange - Log exchange packets.
DebugLSA - Log LSA events.
DebugSPF - Log SPF calculation events.
DebugRoute - Log routing table manipulation events.
Each of these properties can be assigned one of the following values:
|
Note: The high setting generates large amounts of data |
|---|---|
|
When using the High setting, the firewall will log a large amount of information, even when just connected to a small AS. Changing the advanced setting Log Send Per Sec Limit may be required. |
Example 4.15. Enabling OSPF Debug Log Events
In this example, the DebugHello and DebugRoute log events will be enabled for the OSPFProcess called my_ospf_proc.
Command-Line Interface
Device:/> set OSPFProcess my_ospf_proc DebugHello=Low DebugRoute=HighInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
In order to see general OSPF activity on a CLI console, the -snoop option can be used:
Device:/> ospf -snoop=onUsually, there is only one OSPFProcess defined for a single firewall and there is therefore no need to specify this explicitly in the command. The snooping processes is turned off with:
Device:/> ospf -snoop=off
A snapshot of the state of any of the different OSPF components can be displayed. For example, if an OSPFInterface object has the name ospf_If1, details about this can be shown with the command:
Device:/> ospf -iface ospf_If1A similar snapshot can be displayed for areas, neighbors, routes and LSAs.
OSPF interface operation can also be selectively halted and restarted. For example, to stop the OSPFInterface called ospf_If1, the CLI command would be:
Device:/> ospf -ifacedown ospf_If1To restart the same interface:
Device:/> ospf -ifaceup ospf_If1
An entire functioning OSPFRouteProcess can also be halted. For example, assuming that there is only one OSPFRouteProcess object defined in the configuration, the CLI command to halt it is:
Device:/> ospf -execute=stopTo start the stopped OSPFRouteProcess:
Device:/> ospf -execute=startTo stop and then start in a single command:
Device:/> ospf -execute=restart
The ospf command options are fully described in the separate cOS Core CLI Reference Guide.
