cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
567
Views
0
Helpful
2
Replies

OSPF over NBMA network queries

mtsb
Level 1
Level 1

Hi all,

I have few queries on running OSPF on a frame-relay network. Anyone please explain me why so...

1. How to identify a POINT_TO_MULTIPOINT and POINT_TO_MULTIPOINT NONBROADCAST interfaces from "show ip ospf interface s0/0" command. Because for both network types it shows as "POINT_TO_MULTIPOINT" only.


2. If there is a network type mismatch on FR network, say on a hub router it is POINT_TO_MULTIPOINT and on a spoke router it is NON_BROADCAST, neighborship is fine but on hub side no DR/BDR is elected as expected (FULL/ - ) but on the spoke side it chooses itself as DR and hub as BDR (FULL/BDR). Will ospf routing work fine in this scenario?


3. On a FR network without any OSPF and with just inverse arp running, I see remote end IP/DLCI mapping in "show frame map" but in IP routing table why it doesn't show as connected route? Sorry if I sound silly here...


4. If OSPF is running on above network, it shows to reach 10.1.1.3 go via 10.1.1.3 which is little confusing. Can anyone explain a bit more on this?

Thanks,
Madhu

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hi Madhu,

1.) Currently, it seems that there is no way to know from the show ip ospf interface output whether the interface is in PtMP or PtMP/NB mode. You have to have a look at the interface configuration directly.

2.) No, the routing will not work in such case. The reason is given by the inconsistency in the topological database, as both routers see their mutual conection differently. Your hub believes it is connected directly to the spoke router. However, the spoke router believes that it is connected to a multiaccess network, and only this network in turn connects to the hub router. Because of this discrepancy, the OSPF on each router will consider the other to be unreachable along with its networks.

3.) The IP/DLCI mapping is used for Layer2 purposes only (i.e communication of strictly adjacent devices), not for routing purposes, and thus the individual IP addresses from the IP/DLCI table are not inserted into the routing table. The routing table contains only the entry for the entire network (directly connected, of course) in which these particular neighboring IP addresses are located. You also do not see individual IP addresses from the normal ARP table to be individually inserted into the routing table - it is similar with the IP/DLCI mappings here.

4.) This can be seen if you are running the point-to-multipoint OSPF network type on the Frame Relay network. When using PtMP OSPF network type, each router advertises its own interface address with the /32 netmask as an additional network. This address is then used to complete the routing table for incompletely meshed FR networks such as hub-and-spoke, because it helps to explain that 'from a spoke, another spoke can be reached via the hub, not via a direct spoke-to-spoke communication'. The somewhat funny entry you are mentioning is caused simply by each router stating the same about itself: 'I can be reached via myself'. It may appear to be a recursive routing table entry pointing to itself at first, but as you can see, the OSPF also identifies the outgoing interface along with this route, so acually, this route is not recursive although it may appear surprising.

Feel free to ask further.

Best regards,

Peter

View solution in original post

2 Replies 2

Peter Paluch
Cisco Employee
Cisco Employee

Hi Madhu,

1.) Currently, it seems that there is no way to know from the show ip ospf interface output whether the interface is in PtMP or PtMP/NB mode. You have to have a look at the interface configuration directly.

2.) No, the routing will not work in such case. The reason is given by the inconsistency in the topological database, as both routers see their mutual conection differently. Your hub believes it is connected directly to the spoke router. However, the spoke router believes that it is connected to a multiaccess network, and only this network in turn connects to the hub router. Because of this discrepancy, the OSPF on each router will consider the other to be unreachable along with its networks.

3.) The IP/DLCI mapping is used for Layer2 purposes only (i.e communication of strictly adjacent devices), not for routing purposes, and thus the individual IP addresses from the IP/DLCI table are not inserted into the routing table. The routing table contains only the entry for the entire network (directly connected, of course) in which these particular neighboring IP addresses are located. You also do not see individual IP addresses from the normal ARP table to be individually inserted into the routing table - it is similar with the IP/DLCI mappings here.

4.) This can be seen if you are running the point-to-multipoint OSPF network type on the Frame Relay network. When using PtMP OSPF network type, each router advertises its own interface address with the /32 netmask as an additional network. This address is then used to complete the routing table for incompletely meshed FR networks such as hub-and-spoke, because it helps to explain that 'from a spoke, another spoke can be reached via the hub, not via a direct spoke-to-spoke communication'. The somewhat funny entry you are mentioning is caused simply by each router stating the same about itself: 'I can be reached via myself'. It may appear to be a recursive routing table entry pointing to itself at first, but as you can see, the OSPF also identifies the outgoing interface along with this route, so acually, this route is not recursive although it may appear surprising.

Feel free to ask further.

Best regards,

Peter

Hi Peter,

Thanks for your answers. It clarifies my doubts but will dig little more on this area and see if I can understand all the basics fine.

Thanks again,
Madhu

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