...
| Code Block |
|---|
|
/routing ospf interface-template
add networknetworks=192.168.0.0/24 area=backbone_v2
add networknetworks=2001:db8::/64 area=backbone_v3
add networkinterfaces=ether1 area=backbone_v3 |
Routing Table Calculation
Link state database describes the routers and links that interconnect them and are appropriate for forwarding. It also contains the cost (metric) of each link. This metric is used to calculate the shortest path to the destination network.
Each router can advertise a different cost for the router's own link direction, making it possible to have asymmetric links (packets to destination travel over one path, but response travels a different path). Asymmetric paths are not very popular, because it makes it harder to find routing problems.
The Cost in RouterOS is set to 10 on all interfaces by default. Value can be changed in OSPF interface template configuration menu, for example, to add ether2 interface with a cost of 100:
| Code Block |
|---|
|
/routing ospf interface-template
add interfaces=ether2 cost=100 area=backbone_v2 |
The cost of an interface on Cisco routers is inversely proportional to the bandwidth of that interface. A higher bandwidth indicates a lower cost. If similar costs are necessary on RouterOS, then use the following formula:
...
| Section |
|---|
| Column |
|---|
| 
|
| Column |
|---|
Stub area has few restrictions, ASBR routers cannot be internal to the area, stub area cannot be used as transit area for virtual links. The restrictions are made because stub area is mainly configured not to carry external routes.
Let's consider the example above. Area1 is configured as stub area meaning that routers R2 and R3 will not receive any routing information from backbone area except default route. |
|
Totally Stubby Area
Totally stubby area is an extension for stub area. A totally stubby area blocks external routes and summarized (inter-area) routes from going into the area. Only intra-area routes are injected into the area. Totally stubby area is configured as stub area with additional no-summaries flag.
R1:
| Code Block |
|---|
|
/routing ospf areainstance
add name=totally_stubby_area area=v2inst version=2 router-id=1.1.1.12.3.4
/routing ospf area
add name=backbone_v2 area-id=0.0.0.0 instance=v2inst
add name=area1 area-id=1.1.1.1 type=stub
/routing ospf no-summaries |
NSSA
...
interface-template
add networks=10.0.0.0/24 area=backbone_v2
add networks=10.0.1.0/24 area=area1
add networks=10.0.3.0/24 area=area1
|
R2:
| Code Block |
|---|
|
/routing ospf instance
add name=v2inst version=2 router-id=1.2.3.4
/routing ospf area
add name=area1 area-id=1.1.1.1 type=stub
/routing ospf interface-template
add networks=10.0.1.0/24 area=area1 |
R3:
| Code Block |
|---|
|
/routing ospf instance
add name=v2inst version=2 router-id=1.2.3.4
/routing ospf area
add name=area1 area-id=1.1.1.1 type=stub
/routing ospf interface-template
add networks=10.0.3.0/24 area=area1 |
Totally Stubby Area
Totally stubby area is an extension for stub area. A totally stubby area blocks external routes and summarized (inter-area) routes from going into the area. Only intra-area routes are injected into the area. Totally stubby area is configured as stub area with additional no-summaries flag.
| Code Block |
|---|
|
/routing ospf area
add name=totally_stubby_area area-id=1.1.1.1 instance=v2inst type=stub no-summaries |
NSSA
Not-so-stubby area (NSSA) is useful when it is required to inject external routes, but injection of type 5 LSA routes is not required.
| Section |
|---|
| Column |
|---|
|  Image Added
|
| Column |
|---|
Illustration shows two areas (backbone and area1) and RIP connection to the router located in the "area1". We need "area1" to be configured as stub area, but it is also required to inject external RIP routes in the backbone. Area1 should be configured as NSSA in this case. Configuration example does not cover RIP configuration.
|
|
R1:
| Code Block |
|---|
|
/routing ospf instance
add name=v2inst version=2 router-id=1.2.3.4
/routing ospf area
add name=backbone_v2 area-id=0.0.0.0 instance=v2inst
add name=area1 area-id=1.1.1.1 type=nssa
/routing ospf interface-template
add networks=10.0.0.0/24 area=backbone_v2
add networks=10.0.1.0/24 area=area1
|
R2:
| Code Block |
|---|
|
/routing ospf instance
add name=v2inst version=2 router-id=1.2.3.4
/routing ospf area
add name=area1 area-id=1.1.1.1 type=nssa
/routing ospf interface-template
add networks=10.0.1.0/24 area=area1 |
| Note |
|---|
Virtual links cannot be used over NSSA areas. |
Route Summarisation
Route summarisation is consolidation of multiple routes into one single advertisement. It is normally done at the area boundaries (Area Border Routers).
It is better to summarise in the direction to the backbone. That way the backbone receives all the aggregated routes and injects them into other areas already summarised. There are two types of summarization: inter-area and external route summarisation.
Inter-area route summarisation works on area boundaries (ABRs), it does not apply to external routes injected into OSPF via redistribution. By default, ABR creates a summary LSA for each route in a specific area and advertises it in adjacent areas.
Using ranges allows to create only one summary LSA for multiple routes and send only a single advertisement into adjacent areas, or to suppress advertisements altogether.
If a range is configured with the 'advertise' parameter, a single summary LSA is advertised for each range if there are any routes under the range in the specific area. Otherwise (when 'advertise' parameter disabled) no summary LSAs are created and advertised outside area boundaries at all.
Inter-area route summarisation can be configured from OSPF area range menu.
Lets consider that we have two areas backbone and area1, area1 has several /24 routes from 10.0.0.0/16 range and there is no need to flood backbone area with each /24 subnet if it can be summarised. On the router connecting area1 with the backbone we can set up area range:
| Code Block |
|---|
|
/routing ospf area range
add prefix=10.0.0.0/16 area=area1 advertise=yes cost=10 |
| Note |
|---|
For an active range (i.e. one that has at least one OSPF route from the specified area falling under it), a route with type 'blackhole' is created and installed in the routing table. |
External route summarisation can be achieved using routing filters. Let's consider the same example as above except that area1 has redistributed /24 routes from other protocols. To send a single summarised LSA, blackhole route must be added and appropriate routing filter to accept only summarised route:
| Code Block |
|---|
|
/ip route add dst-address=10.0.0.0/16 blackhole
/routing ospf instance
set v2inst out-filter-chain=ospf_out
/routing filter rule
add chain=ospf_out rule="if (dst == 10.0.0.0/16) {accept} else {reject}" |
Virtual Link
As it was mentioned previously all OSPF areas have to be attached to the backbone area, but sometimes physical connection is not possible. To overcome this areas can be attached logically by using virtual links.
There are two common scenarios when virtual links can be used:
- to glue together fragmented backbone area
- to connect remote are without direct connection to the backbone
| Section |
|---|
| Column |
|---|
|  Image Added
|
| Column |
|---|
Partitioned BackboneOSPF allows to link discontinuous parts of the backbone area using virtual links. This might be required when two separate OSPF networks are merged into one large network. Virtual link can be configured between separate ABRs that touch backbone area from each side and have a common area. Additional area could be created to become transit area, when common area does not exist, it is illustrated in the image above. Virtual Links are not required for non-backbone areas, when they get partitioned. OSPF does not actively attempt to repair area partitions, each component simply becomes a separate area, when an area becomes partitioned. The backbone performs routing between the new areas. Some destinations are reachable via intra-area routing, the area partition requires inter-area routing. However, to maintain full routing after the partition, an address range has not to be split across multiple components of the area partition.
|
|
| Section |
|---|
| Column |
|---|
| Image Removed Image Added |
| Column |
|---|
Illustration shows two areas (backbone and area1) and RIP connection to the router located in the "area1". We need "area1" to be configured as stub area, but it is also required to inject external RIP routes in the backbone. Area1 should be configured as NSSA in this case. Configuration example does not cover RIP configuration.
|
| Note |
|---|
Virtual links cannot be used over NSSA areas. |
...
No physical connection to backboneArea may not have physical connection to backbone, virtual link is used to provide logical path to the backbone of the disconnected area. Link has to be established between two ABRs that have common area with one ABR connected to the backbone. We can see that both R1 and R2 routers are ABRs and R1 is connected to backbone area. Area2 will be used as transit area and R1 is the entry point into backbone area. Virtual link has to be configured on both routers.
|
|
Property Reference
/routing/ospf/instance
...
| Property | Description |
|---|
| area-id (IP address; Default: 0.0.0.0) | OSPF area identifier. If the router has networks in more than one area, then an area with area-id=0.0.0.0 (the backbone) must always be present. The backbone always contains all area border routers. The backbone is responsible for distributing routing information between non-backbone areas. The backbone must be contiguous, i.e. there must be no disconnected segments. However, area border routers do not need to be physically connected to the backbone - connection to it may be simulated using a virtual link. |
| default-cost (integer; unset) | Default cost of injected LSAs into the area. If value is not set, then stub area type-3 default LSA will not be originated. |
| instance (name; mandatory) | Name of the OSPF instance this area belongs to. |
| no-summaries () | Flag parameter, if set then area will not flood summary LSAs in the stub area. |
| name (string) | the name of the area | nssa-translate (yes | no | candidate) | The parameter indicates which ABR will be used as a translator from type7 to type5 LSA. Applicable only if area type is NSSA- yes - the router will be always used as a translator
- no - the router will never be used as a translator
- candidate - OSPF elects one of the candidate routers to be a translator
|
| type (default | nssa | stub; Default: default) | The area type. Read more on the area types in the OSPF case studies. |
/routing/ospf/area/range
Prefix ranges are used to aggregate routing information on area boundaries. By default, ABR creates a summary LSA for each route in a specific area and advertises it in adjacent areas.
Using ranges allows to create only one summary LSA for multiple routes and send only a single advertisement into adjacent areas, or to suppress advertisements altogether.
...
| the name of the area |
| nssa-translate (yes | no | candidate) | The parameter indicates which ABR will be used as a translator from type7 to type5 LSA. Applicable only if area type is NSSA- yes - the router will be always used as a translator
- no - the router will never be used as a translator
- candidate - OSPF elects one of the candidate routers to be a translator
|
| type (default | nssa | stub; Default: default) | The area type. Read more on the area types in the OSPF case studies. |
/routing/ospf/area/range
| Property | Description |
|---|
| advertise (yes | no; Default: yes) | Whether to create a summary LSA and advertise it to the adjacent areas. |
| area (name; mandatory) | the OSPF area associated with this range |
| cost (integer [0..4294967295]) | the cost of the summary LSA this range will create default - use the largest cost of all routes used (i.e. routes that fall within this range) |
| prefix (IP prefix; mandatory) | the network prefix of this range |
...
...
/routing/ospf/interface
/routing/ospf/interface-template
...