How to exclude the default route (all-nets) from being exported to/from OSPF process

Last modified on 15 Dec, 2022. Revision 7
A short guide on how to exclude the default (all-nets / 0.0.0.0/0) route from being exported to/from OSPF process in this particular scenario
Up to date for
cOS Core 14.00.07
Supported since
cOS Core 11.x
Status OK



Introduction

This guide will discuss the configuration setting that excludes the default route 0.0.0.0/0 (also known as all-nets) from being exported to/from a given OSPF process running on cOS Core firewalls.
The setting will be discussed and described based on a given use case scenario.
**

Use case requirement

The network architect of company X that uses cOS Core firewall appliances, wants to dynamically advertise all the routes of a specific routing table named (Datacenter_Services_RT) within the Data center site ‘which contains 200 routes’ towards all branch sites as per the Figure-1 below:


The routing requirement the architect has studied is as the following:OSPF process running on Datacenter firewall node must advertise all current and future introduced routes within datacenter’s routing table toward all OSPF neighbor processes running under Branch firewalls.

OSPF process running on Branch firewall nodes must export the learned Datacenter routes towards routing table of the branch site.

All branch firewalls must access the internet only via their respective ISP connections and not through the Data center site, hence the OSPF process under Datacenter site should NOT advertise the default route 0.0.0.0/0 towards the branch firewalls, so this default route won’t override the static default route defined under each respective branch routing table.

Solution

Since there are many routes within datacenter firewall’s routing table to be advertised by OSPF process, and the administrator would also like to advertise all future introduced datacenter routes, it is then not efficient/scalable solution to individually select network prefixes (routes) ‘within the defined routing rules’ to be exported from the routing table towards Datacenter’s OSPF process.

To address this issue, assume that there is a ‘Routing rule’ already defined under the Datacenter firewall node to catch routes from Datacenter ‘routing table’ to be exported to the OSPF process as per the Figure-2 below:


The administrator can configure the ‘…Or is within:’ setting of the defined ‘Routing rule’ with the ‘0.0.0.1-255.255.255.255’ value.
This network range value includes all possible IPv4 address values except the default route value 0.0.0.0/0. In this case, the routing rule will filter out default route ‘0.0.0.0/0’ when catching routes from Datacenter’s routing table, to be exported towards the OSPF process.

As a result, the OSPF process running under Datacenter site will advertise all routes ‘except the default route’ towards the neighbor OSPF processes running under branch sites, which fulfills the routing requirement.

Alternatively, same logic can be applied under branch firewalls instead. In this case the administrator would need to refer to the ‘Routing rule’ defined in these branch firewalls to catch routes from OSPF process to be exported towards the corresponding branch routing table and set the same network range value ‘0.0.0.1-255.255.255.255’ for the ‘…Or is within:’ setting.



Related articles

Setup of a Layer-3 bridge over IPsec in cOS Core
12 Apr, 2023 core proxyarp arp ipsec routing
cOS Core IKEv2 split tunneling with Windows and local user database.
28 Mar, 2023 ikev2 windows vpn routing splittunneling
Problem with auto-created Core routes
22 Mar, 2021 core ipsec routing
Setting up OSPF with IPsec in cOS Core
16 Apr, 2024 core routing ospf ipsec
Using /31 network masks in cOS Core (RFC-3021)
1 Jun, 2022 core routing management
The meaning of the Default_Access_Rule log entry
7 Nov, 2022 core arp log routing
Troubleshooting cOS Core rules/routes with ping simulation
17 Mar, 2023 core routing rules ping icmp cli
Is Statless (FwdFast) faster than a normal IP policy?
27 Jan, 2021 core stateless routing brokenlink
Route failover with IPsec tunnels in cOS Core
13 Feb, 2023 ipsec core routing failover
Public network transparency using cOS Core Proxy ARP instead of subnetting
18 Apr, 2023 core routing transparentmode proxyarp