Archives for category: ospf

OSPF is used in numerous networks, it is well documented, well-known and widely tested in many scenarios. When IPv6 came along, good old OSPF which was used for IPv4 (OSPFv2), got a younger brother – OSPFv3. Many networks now run both protocols, one for IPv4 and the other for IPv6. This is getting more and more ridiculous, because OSPFv3 can be used to route IPv4 also.

See how this can be done with Cisco IOS and Juniper JUNOS. Read the rest of this entry »

Advertisements

The default route is the path toward all those networks which have no other matching routes defined. What a boring definition :-(. Let me try again: “The default route will take you to the unexplored areas of the divine Internet!”, or: “Follow the default route to eternity!”. Back to earth, ::/0 represents everything out there (except for the historic IPv4 stuff). Where does the route for ::/0 come from?

I was discussing a few options for generation of the default route in BGP, but did not pay much attention to the origin of the default route. How is this route created and put into the routing table? Read the rest of this entry »

I should use the word “coexistence” instead “versus” in my short talk about BGP versus OSPF. Let us move on with a slightly more technical discussion about the collaboration and coexistence of the two protocols. I will discuss solid grounds first.

In order to be able to “route”, a router must know the next hop for a certain destination. And the next hop must be reachable! It is very important not to forget this basic rules when combining more routing protocols which interact with each other. Let’s have a look into a very basic network topology with an underlying OSPF and iBGP on top of it. Read the rest of this entry »

A very simple question with a tricky answer ;-). How many OSPF areas are in this network?

For OSPF, areas are contiguous segments of networks and routers. One of the golden rules of standard area design is that all OSPF areas must have a connection to the backbone area (area 0). A simple topology that shows area 100 connected to the backbone is depicted below:

split_OSPF_area

How many OSPF areas are there in all? Read the rest of this entry »

I’ve found one of the best answers to the question “What is BGP for?” in one of Philip Smith’s presentations (google for “BGP Best Current Practices”): “What is an IGP not for?”

Internal Routing Protocols (IGPs), like IS-IS and OSPF, are used to maintain infrastructure connectivity. They carry infrastructure addresses and are designed for rapid convergence within reasonably sized and manageable routing domains. On the other hand, BGP is designed primarily as a routing policy tool. External BGP carries Internet prefixes and exchanges them between autonomous systems according to some policy and rules of good behaviour. BGP is also used internally to carry customer prefixes and adds full flexibility to the routing decisions. BGP can handle huge routing tables, but in a somehow stable environment. It is designed to scale with expanding networks but not to respond quickly to topology changes. Read the rest of this entry »

Multiple OSPF processes with mixed network statements can really mess things up! Fortunately, there is a better way to assign an interface into an OSPF area.

I’ve discussed overlapping OSPF network statements in one of my earlier posts. In the a “pre-IPv6-era” we were taught to use network statements in the OSPF stanza to assign the interfaces to a certain OSPF area. This configuration

interface Vlan100
  ip address 10.0.100.1 255.255.255.0
!
router ospf 1
  passive-interface default
  no passive-interface Vlan100
  network 10.0.100.0 0.0.0.255 area 1

…enables OSPF process on the interface Vlan100 and assigns that interface to OSPF area 1.
What happens if one uses multiple and overlapping networks statements in order to assign interfaces into different areas? Read the rest of this entry »

The devil is in the detail.

Recently I’ve taken a part in some OSPFv3 troubleshooting. It was a simple setup and the problem was soon reduced to just two adjacent routers, both running OSPF for IPv6. A simplified schema describes the situation:

schema
Read the rest of this entry »

Most things in networking are not revolutionary. No need to reinvent the wheel.

After many years of continuous growth of your backbone network, you might decide to clean up the mess and renumber the network within one single IP prefix covering the whole area. If OSPF is your choice for the interior routing protocol for IPv4, this is the right time to think again about using the OSPF network statements. A single network statement per router is all you need to make all the backbone interfaces seen by the OSPF process.
Here, for example, all the backbone is covered by a single prefix 10.0.0.0/8:
interface FastEthernet0/0
 ip address 10.1.0.0 255.255.255.254
!
router ospf 4
 passive-interface default
 no passive-interface FastEthernet0/0
 ! all backbone links are derived from 10.0.0.0/8
 network 10.0.0.0 0.255.255.255 area 0
!

What happens if we add another interface within the same global 10.0.0.0/8 to the OSPF, but we are putting it into a different OSPF area. For this exception we have to use a more specific network statement, for example:
interface Vlan991
 ip address 10.4.4.4 255.255.255.254
!
router ospf 4
 ! adding Vlan991 to area 4 with a /32 network statement
 no passive-interface Vlan991
 network 10.4.4.4 0.0.0.0 area 4
!

Will it work or will it cause conflict with the “network 10.0.0.0 0.255.255.255 area 0” statement?
Read the rest of this entry »

Od presenečenja, da se oprema nekega proizvajalca obnaša drugače kot oprema drugega, je do brskanja po RFC-jih le še korak.

V testnem okolju sem na sosednjem usmerjevalniku (router2) nastavil pot do nekega ciljnega IP-naslova tako, da ja ta pot kazala nazaj proti mojemu usmerjevalniku (router1). Presenetilo me je, da moj usmerjevalnik te poti ni prepoznal kot veljavne in je ni vpisal v svojo usmerjevalno tabelo. Naslov OSPF Forward Address za to pot, ki ga je izvedel od soseda, je bil namreč on sam. Zato je razumljivo, da je bila zanj ta pot neveljavna.

Ker se mi zdelo nelogično, da nek usmerjevalnik nastavi Forward Address na nekaj “povsem neuporabnega”, sem najprej preveril, ali enako velja tudi za kakšno drugo vrsto usmerjevalnikov. Na usmerjevalnik router1 sem zato na enak način povezal še usmerjevalnik drugega proizvajalca (router71).


(podrobnejše nastavitve najdete tule)
Read the rest of this entry »