Problem solve Get help with specific problems with your technologies, process and projects.

Practical configurations: Extending the OSPF network

Doug Downer continues his series on network configuration with a focus on adding external prefixes such as static routes into your newly created OSPF network and also how to manipulate these routes as they travel across each layer.

Throughout this series, we've looked in depth at the configurations necessary to provide basic connectivity throughout...

the network. By now, you should have a basic understanding of how to configure the essential components from the edge layer to the core. This week, I will focus on adding external prefixes such as static routes into your newly created OSPF network and also how to manipulate these routes as they travel across each layer.

Other tips in this series

Practical configurations, Part 1

Practical configurations, Part 2

Practical configurations, Part 3

Practical configurations, Part 4

External prefixes
To send data from one end of your network to the other, knowledge of both ends must be present in each of your layer 3 networking devices along the path(s). In this series, I've shown you how to configure OSPF on your networking devices, which will allow this "end-to-end" prefix/routing information to be advertised throughout your network.

But what if you wanted to add another network? The concept of routing policy (5.17.2005) is something every engineer should be conscious of -- at least to have the ability to answer this question. An external prefix is a route to a destination, which wasn't learned via the dominant protocol in your network, and was externally inserted into the routing domain. Simply put, to add other networks, you must redistribute the route into your domain. This process creates a route which, by default, is labeled as external and has different properties than an internal route. Recall our network design using the figure below.

Let's pretend for a second that there is a new network requirement which will require you to install new devices in separate locations within your newly created OSPF network (above). The problem is that these devices don't support OSPF -- which of course is the protocol you're using to advertise prefix information throughout your network.

Common situation
This is a common issue in many networks out there, usually associated with installing a firewall, or similar untrusted networking device. The figure below describes the situation

In the figure, FW-1 has a network (172.16.11.0/24) behind it which must have the ability to reach the network behind FW-2 (172.16.10.0/24). Remember that neither device supports OSPF, and each network must be known by every device throughout the path(s) between the two firewalls. There are a couple of ways you can get this prefix into your network. The first is to install a static route on D1 and D4 and re-distribute it into your OSPF domain.

Configure the interfaces to the firewalls
D1(config)#interface g4/1
D1(config-if)#ip address 150.1.1.37 255.255.255.252
D4(config)#interface g4/1
D4(config-if)#ip address 150.1.1.41 255.255.255.252

Configure the static routes
D1(config)#ip route 172.16.11.0 255.255.255.0 150.1.1.38
D4(config)#ip route 172.16.10.0 255.255.255.0 150.1.1.42

I haven't shown it here, but don't forget to configure the static default 0.0.0.0 or similar on the firewalls themselves. Notice I also defined a next hop address for the static route configuration. The other option is to define a physical interface -- which isn't recommended.

Redistribute the static routes into OSPF
D1(config)#router ospf 1
D1(config-router)#redistribute static subnets
D4(config)#router ospf 1
D4(config-router)#redistribute static subnets

Don't forget the subnets keyword!

Manipulation
Once you've inserted these statements in your configuration, you can verify that the individual routes have been redistributed into OSPF correctly by using the command "show ip route" on one of the core routers.

Core-1#show ip route 172.16.11.0

Routing entry for 172.16.11.0/24,
Known via "ospf 1", distance 110, metric 20, type extern 2
Last update from 150.1.1.2 on G0/1, 5d22h ago
Routing Descriptor Blocks:
* 172.16.11.0, from , 5d22h ago, via G0/1
Route metric is 20, traffic share count is 1

O E2 172.16.11.0/24 [110/20] via 150.1.1.2, 1w4d, G0/1

E2 stands for "External-Type-2" OSPF routes. An E2 route has a default metric of 20 in OSPF, regardless of where it originated or where it is in the network. Because the metric determines the path data takes, it might not be a good or feasible plan to allow E2 OSPF routes in your network. External-Type 1 routes, on the other hand, are treated like any other OSPF route. The cost is incremented based from hop to hop, which gives you a much more accurate representation of the path it has taken to reach your router. To change the default OSPF behavior, you can configure your router with the following:

Change the Metric-Type of redistributed routes
D1(config)#router ospf 1
D1(config-router)#redistribute static subnets metric-type 1
D4(config)#router ospf 1
D4(config-router)#redistribute static subnets metric-type 1
You can see the difference in the way the route looks by viewing the IP routing table.

Core-1#show ip route

Routing entry for 172.16.11.0/24,
Known via "ospf 1", distance 110, metric 38, type extern 1
Last update from 150.1.1.2 on G0/1, 5d22h ago
Routing Descriptor Blocks:
* 172.16.11.0, from , 5d22h ago, via G0/1
Route metric is 38, traffic share count is 1

O E1 172.16.11.0/24 [110/38] via 150.1.1.2, 1w4d, G0/1

Hopefully, now you have the complete picture on how to configure your network, verify its operation and manipulate certain protocol behaviors. Keep in mind these concepts are just the tip of the iceberg in terms of routing configuration and manipulation. The key to being able to use advanced methods to accomplish your networking needs is knowledge of the protocols themselves. Knowing about "the bits and the bytes" can help you understand the "why" to your configurations. This concludes the first of many series of practical configurations.


Doug Downer (CCIE #9848) is a Sr. Consultant with Callisma, Inc., a wholly owned subsidiary of SBC Communications. Doug has over seven years experience in the industry and currently provides high-level business and technology consulting for various federal clients in the Washington D.C. area.
This was last published in September 2005

Dig Deeper on Managed services

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchNetworking

SearchUnifiedCommunications

SearchTelecom

SearchSDN

Close