cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1956
Views
45
Helpful
4
Replies

FR with OSPF & EIGRP

snarayanaraju
Level 4
Level 4

Hi Experts

It may sound very basic, But I am not find the convincing answer in the Internet. Finally i sought your help

Let us start the argument with the below points

1. OSPF & EIGRP both use multicast address to find the neighbours and form adjacencies.

2. NBMA network donot support Broadcast / Multicast natively.

If this is the case,

In NBMA Network like Frame Relay, why OSPF is alone having multiple options like NON-BROADCAST, POINT-TO-POINT, BROADCAST,POINT-TO-MULTIPOINT but where as EIGRP donot have these confusion and straight away forms the neighbour relation.

show ip ospf interface

Serial0/0 is up, line protocol is up

Internet Address 131.1.14.4/24, Area 4

Process ID 1, Router ID 4.4.4.4, Network Type NON_BROADCAST, Cost: 64

Another Interesting point is I have configured an Interface with encapsulation framrelay and OSPF is configured in the network and in the output of "show int ser 0/0" command I am seeing Network Type as "NON_BROADCAST". But when i ping 224.0.0.9 I am getting reply from the peer routers as

Reply to request 0 from 4.4.4.4, 8 ms

I expected that reply will not come as the interface is a NON_BROADCAST.

Can you help me what is the actual reasons for OSPF network types and why I am able to ping the Multicast IP even though the interface is NON_BROADCAST

Thanks in advance

sairam

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hello again,

For the problem with multiaccess network with a partial neighbor reachability I have just described, it is actually more beneficial to use the point-to-multipoint approach and to advertise a link between each pair of routers on a multiaccess segment if they can successfully hear their Hello packets. No "pseudonode" representing the network fill be advertised (if it were, we would not be able to say in OSPF that the spokes are not able to communicate directly). The memory requirements are increased but the topology table now accurately reflects the actual reachability of neighbors within the network.

So much to the first aspect - to the modelling of the network in the topological database. The second point was related to the multicast/broadcast capabilities of the underlying Layer2 technology.

One of the major functions of routing protocols is to dynamically detect present and future neighbors if possible, without apriori knowing their address. OSPF uses the multicast address 224.0.0.5 to send and listen for Hello packets to dynamically discover neighbors. For an OSPF router, it simply means sending an IP packet to the destination address 224.0.0.5 and it is up to the network technology to replicate that multicast. We call these networks broadcast networks. The multicasts are also used to send routing information to multiple neighbors at once.

Now, again, this works in a LAN environment such as Ethernet. However, virtual-circuit based technologies such as ATM, X.25 or Frame Relay are not natively capable of replicating a multicast/broadcast and sending it automatically through a number of VCs. That is why we call them non-broadcast networks. In these networks, you do not have the luxury of automatically discovering OSPF neighbors, and instead, you have to preconfigure their addresses manually. The communication between such neighbors will be unicast-only.

Now, routers are actually able to cheat a little here. Even though a Frame Relay is a non-broadcast technology, the IP/DLCI mappings may have the 'broadcast' flag set that simply tells the router to send a copy of each outgoing multicast/broadcast packet through that DLCI. For the Frame Relay, it is a packet like all others, however, your router has done the hard work of replicating the multicast on all PVCs.

Now, when you combine these two aspects, you will come to a number of combinations:

1.) Broadcast MultiAccess (BMA) - this is the usual type for Ethernet. Here, the routers are discovered automatically using multicasts and the network itself is modelled as a pseudonode, decreasing the memory footprint

2.) Non-Broadcast Multi-Access (NBMA) - this is the default network type for Frame Relay interfaces. The neighbors must be defined statically (OSPF will not even try to send a multicast packet out an interface of this network type!), however, the network will be modelled using a pseudonode. Actually, this network type is not so appropriate for most Frame Relay networks because in most cases, they are not fully meshed and the problem with such deployments has been discussed in my earlier post. Even an intermittent or inadvertent failure of a single PVC in a Frame Relay network that was originally fully meshed will make this network partial-meshed with all negative impacts.

3.) Point-to-Point - this is the default for Frame-Relay point-to-point subinterfaces. The neighbor is discovered automatically and the link between the two routers on the PVC is modelled as a direct connection of those two routers. No pseudonode is used. The 'broadcast' has no meaning here because of the point-to-point nature.

4.) Point-to-Multipoint Broadcast - this network type must be configured manually. Neighbors will be discovered automatically (using the 'broadcast' flag in IP/DLCI mappings on Frame Relay) and the connections will be modelled by direct links. No pseudonode will be used.

Continuation follows...

View solution in original post

4 Replies 4

Edison Ortiz
Hall of Fame
Hall of Fame

sairam,

Each protocol have unique characteristics and with OSPF you have the concept of the Designated Router/Backup Designated Router. You have the option on OSPF to run with or without DR/BDR by manipulating the OSPF network type on interfaces. This concept does not exist while using EIGRP.

While you find EIGRP easier to deploy and configure - it does not offer the scalability that OSPF offers in large networks.

As for the 2nd query, the interface automatically joins a multicast address of 224.0.0.9 when OSPF is enabled on such interface. You are receiving a reply from the interface itself not the remote device (4.4.4.4 is your local router isn't it?)

HTH,

__

Edison.

Peter Paluch
Cisco Employee
Cisco Employee

Sairam,

This will require quite a bit of explaining so the following posts are going to be theoretical and quite large.

The logic behind OSPF network types follows from two main aspects: first, how to represent a multiaccess network in a topological database, and second, what multicast/broadcast delivery options does a particular Layer2 technology have.

A multiaccess network allows multiple endpoints to be a part of a single network. From a router's perspective, all neighbors on a single multiaccess network are directly reachable via a single interface. For instance, the Ethernet is a typical example of a multiaccess network - behind a single interface, many neighboring routers are directly reachable. The Frame Relay can also be set up as a multiaccess network if you assign multiple DLCIs to a single interface.

In the Ethernet, each member of an Ethernet segment can talk to all other members directly, by simply sending them a frame. Now the question is how to make a topological model of such a network. The ability of each router to talk to all its other neighbors directly is equivalent to an idea of each router being connected via a dedicated link to each other. Therefore, one possible approach is for each router to advertise a link to each its neighbor on a multiaccess segment. This approach is known in OSPF as the point-to-multipoint network type. However, it is not memory efficient, because modelling a single multiaccess segment with N routers on it requires generating and storing N*(N-1) link records for that segment in the topological database of each router in the area.

Therefore, for networks such as Ethernet, a different approach is used. Instead of each router on a multiaccess segment announcing a link to each other, the multiaccess segment itself is modelled as a "router" (or more precisely, a node) that interconnects all members on that segment. For a graphical representation, see this image:

http://www.cisco.com/image/gif/paws/49627/pseodonode.gif

Actually, this picture is taken from an IS-IS article but the idea is precisely the same in OSPF. This approach is significantly more memory effective, as each routers advertises only a single link to the network, instead of advertising (N-1) links to its neighbors. This mode is known in OSPF as multiaccess (not talking about broadcast/nonbroadcast yet).

Now, the multiaccess type of network has a very important property. It assumes in forward that each router is able to talk to all its neighbors directly. This is true in networks such as Ethernet, ATM or X.25 where the connection between any pair of routers is either implicit (as in Ethernet) or can be easily set up on demand (SVCs in ATM). However, there are networks that provide only partial connectivity despite being configured as multiaccess. A hub-and-spoke Frame Relay is a perfect example. Only the hub router has PVCs to each spoke router. Spoke routers do not have PVCs interconnecting them so they can not talk to each other directly, even despite being in the same IP network. Representing this topology using the nonbroadcast approach will lead to problems because the network will be represented as fully connected, disregarding the actual (non)existence of PVCs between the routers (the OSPF does not really see PVCs so it can not take into account which PVCs really exist and which do not). The problem will display itself in the routing table: for each network behind a spoke, the next-hop address of that network will be IP address on the Frame Relay interface of that spoke. Now, because on a different spoke you do not have a PVC going to that spoke, you also do not have the IP/DLCI mapping for the next-hop address and the spoke network will effectively be unreachable until you manually define proper DLCI mappings on all spokes.

Continuation follows...

Peter Paluch
Cisco Employee
Cisco Employee

Hello again,

For the problem with multiaccess network with a partial neighbor reachability I have just described, it is actually more beneficial to use the point-to-multipoint approach and to advertise a link between each pair of routers on a multiaccess segment if they can successfully hear their Hello packets. No "pseudonode" representing the network fill be advertised (if it were, we would not be able to say in OSPF that the spokes are not able to communicate directly). The memory requirements are increased but the topology table now accurately reflects the actual reachability of neighbors within the network.

So much to the first aspect - to the modelling of the network in the topological database. The second point was related to the multicast/broadcast capabilities of the underlying Layer2 technology.

One of the major functions of routing protocols is to dynamically detect present and future neighbors if possible, without apriori knowing their address. OSPF uses the multicast address 224.0.0.5 to send and listen for Hello packets to dynamically discover neighbors. For an OSPF router, it simply means sending an IP packet to the destination address 224.0.0.5 and it is up to the network technology to replicate that multicast. We call these networks broadcast networks. The multicasts are also used to send routing information to multiple neighbors at once.

Now, again, this works in a LAN environment such as Ethernet. However, virtual-circuit based technologies such as ATM, X.25 or Frame Relay are not natively capable of replicating a multicast/broadcast and sending it automatically through a number of VCs. That is why we call them non-broadcast networks. In these networks, you do not have the luxury of automatically discovering OSPF neighbors, and instead, you have to preconfigure their addresses manually. The communication between such neighbors will be unicast-only.

Now, routers are actually able to cheat a little here. Even though a Frame Relay is a non-broadcast technology, the IP/DLCI mappings may have the 'broadcast' flag set that simply tells the router to send a copy of each outgoing multicast/broadcast packet through that DLCI. For the Frame Relay, it is a packet like all others, however, your router has done the hard work of replicating the multicast on all PVCs.

Now, when you combine these two aspects, you will come to a number of combinations:

1.) Broadcast MultiAccess (BMA) - this is the usual type for Ethernet. Here, the routers are discovered automatically using multicasts and the network itself is modelled as a pseudonode, decreasing the memory footprint

2.) Non-Broadcast Multi-Access (NBMA) - this is the default network type for Frame Relay interfaces. The neighbors must be defined statically (OSPF will not even try to send a multicast packet out an interface of this network type!), however, the network will be modelled using a pseudonode. Actually, this network type is not so appropriate for most Frame Relay networks because in most cases, they are not fully meshed and the problem with such deployments has been discussed in my earlier post. Even an intermittent or inadvertent failure of a single PVC in a Frame Relay network that was originally fully meshed will make this network partial-meshed with all negative impacts.

3.) Point-to-Point - this is the default for Frame-Relay point-to-point subinterfaces. The neighbor is discovered automatically and the link between the two routers on the PVC is modelled as a direct connection of those two routers. No pseudonode is used. The 'broadcast' has no meaning here because of the point-to-point nature.

4.) Point-to-Multipoint Broadcast - this network type must be configured manually. Neighbors will be discovered automatically (using the 'broadcast' flag in IP/DLCI mappings on Frame Relay) and the connections will be modelled by direct links. No pseudonode will be used.

Continuation follows...

Peter Paluch
Cisco Employee
Cisco Employee

Hi again,

This is the last post.

5.) Point-to-Multipoint Non-Broadcast - a rarely used network type. Neighbors must be set up manually, the network will be modelled by direct links without using a pseudonode.

If we were to talk about network types not from the viewpoint of the principles behind but perhaps from the viewpoint of applicability, it would go as follows:

* The Broadcast Multi-Access network is ideal for usual Ethernet deployments.

* The Non-Broadcast Multi-Access was originally created for ATM and X.25 networks where the full connectivity between neighbors could always be achieved by simply asking the network to provide a switched virtual circuit between appropriate routers. While this network type can be used for Frame Relay deployments, it is not originally envisioned for such network and will require additional configuration (IP/DLCI mappings, setting OSPF priority on spokes to 0).

* The Point-to-Multipoint network type is ideal for Frame Relay deployments.

* The Point-to-Point network type is automatically used on point-to-point interfaces like HDLC, PPP or point-to-point FR subinterfaces.

So to summarize all this, the OSPF must represent the network topology and inter-router reachability somehow. The creators of OSPF wanted it to be able to run on different types of network technologies and therefore they have created a couple of network types that define how are neighbors discovered and how is their interconnection represented in the topology database. Right because of the detail that OSPF knows about the network, as opposed to the EIGRP that is a distance-vector procotol, it is a consequence that the OSPF needs to distinguish between network types in far more detail.

The EIGRP basically works "out-of-box" on Frame Relay networks because its behavior is very similar to the point-to-multipoint approach in OSPF. And if you try it in OSPF you'll also see that after setting the network type to point-to-multipoint, even the OSPF works out of the box :)

Best regards,

Peter

P.S.: I apologize to everybody for the size and the count of my posts in this thread.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco