Can someone please explain that which network type is best to be used with OSPF Frame Relay Interfaces and why?
Searched a lot of stuff on internet but could'nt conclude the choice of a network type with solid/clear reason. It seems that it is the willingness of every network administrator to use any OSPF Network Type across frame relay without much difference in performance.
I suggest you first read this thread:
I tried there to explain, on quite a large scale, the implications behind individual OSPF network types. It may answer your question to a certain degree.
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
I normally prefer p2p using subinterfaces. Assuming we have a hub-and-spoke, it allows for QoS to be easily applied on the subinterfaces. I'm also assuming spokes only have one PVC per physical interface and that the hub's physical interface isn't normally oversubscribed vs. the aggregate of the spokes. I.e. the spoke interfaces are the primary bottleneck.
QoS if often especially important on frame-relay as frame-relay connections are usually of comparatively low bandwidths.
Your post was really very informative. However, I am getting confused in the concept of the Psuedonode. Shoudnt the DR and BDR be the psuedonode instead of the network, which are actually performing the duty of exchanging the Router LSAs from all DRothers?
My first name is Peter but never mind
Shoudnt the DR and BDR be the psuedonode instead of the network, which are actually performing the duty of exchanging the Router LSAs from all DRothers?
The pseudonode is just a virtual object - a data structure - inside the link-state database that stands for a multiaccess network interconnecting several routers. It never exists physically. The concept of pseudonodes reduces the amount of data used by the link-state database and it also reduces the running time of the SPF algorithm.
Once again: the pseudonode is an element of the link-state database that represents a multiaccess network segment. It is not involved in any way with how the LSAs are delivered between routers.
Neither DR nor BDR are a pseudonode - the DR is merely responsible for originating or injecting a pseudonode into the link-state database. In OSPF, the DR is also given an additional responsibility of orchestrating the exchange of LSAs (of all types) on a segment but that is, contrary to the popular belief, just a marginal function. IS-IS does not use the concept of DR as an "LSA dispatcher".
Please accept my opologies for refering you from your second name and thanks for reminding so humbly.
Just have to ask little bit more about OSPF network types and OSPF general behaviour.
I have used Broadcast OSPF Network type across partially meshed frame-relay network. This is giving me strange and weird results which are describe below:
I have used a Hub R2 (Router ID 188.8.131.52) and three Spokes R3, R4 and R5 (with Router IDs 184.108.40.206, 220.127.116.11 and 18.104.22.168).
My Hub's Router ID is the lowest of all. Since each Spoke has a PVC only with the Hub, and each Spoke sees only Hub which has a lower Router ID than itself, therefore, each Spoke becomes a DR.
My Hub becomes a BDR with the Spoke having Highest Router ID R5 and keeping all others as DRothers. This is logical because none of the Spoke is claiming to be a BDR.
Now the question is that with the above scenario, following LSDB exchange shoud occur? As per my understanding, following LSDB exchanges should occur:
1.. Since each spoke claims itself as DR and Hub as BDR, so each spoke should send it's LSDB to Hub (BDR).
2.. Since Hub thinks itself as BDR with R4, therefore it shoud send it's LSDB to R5.
3.. Since Hub thinks R3 and R4 as DROthers and itself as BDR, so it should not send it's LSDB to these.
Now the question is that is it possible that one way LSDB exchange should occur as I have mentioned above?
Also, the LSDB of all the routers is same (I dont know how). However, not all routers have added the routes in their Routing Table.
Can you please explain that if a router has LSAs in its LSDB, what really stops it from adding these to the Routing Table? (Note that I have not used any distribute-list).
If required, i will paste the topology and configs.
Don't worry about my name - I did not take any offense.
Regarding the situation with two DRs on the same network: this behavior is, as you can see, not going to work. But to explain why it does not work, I would need to see the output of the LSDB.
So would you be so kind as to post the output of the show ip ospf database router and show ip ospf database network from one of these routers?
Please find below the topology and the configurations and desired commands output in attchment.
Alright. So, if the OSPF was configured correctly then R2 would become the DR and R3, R4 and R5 would be DRother. The topological database of your network would then contain the following abstraction:
Note that the routers are identified here by their RIDs, and the multiaccess network connecting them together would be the yellowish cloud in the middle, represented by the DR's IP address. In this depiction, the blue routers correspond to individual LSA-1s, the cloud corresponds to the LSA-2, and the arrows signify the interconnection as indicated in LSA-1 and LSA-2. So this would be a correct model of your network as stored in the LSDB of all four routers.
However, your topology is different because each of R3, R4 and R5 considers itself to be DR and to be the one to represent the multiaccess network as well. Therefore, each of these three routers emits its own LSA-2 but because the spoke routers do not see each other, these three LSA-2 contradict each other because in each LSA-2, only R2 and the originating spoke router is indicated as being connected together. In fact, your current LSDB contains the following network model:
Note that instead of one common network interconnecting all these routers together, each of these routers tries to represent the multiaccess segment itself, resulting in three LSA-2, each of them having only a limited view of the overall network topology. Also see how each router is isolated from each other: R3 and R4 can get to the common network (observe the direction of the arrow), and the common network can bring them to R2, but R2 is unable to get anywhere else than to R5. In graph theory on which OSPF is built, we would say that this network is not strongly connected because for any nodes u and v, u!=v, there are no both (u,v) and (v,u) directed paths available.
OSPF specifically verifies that if a transit object X (router or network) in the LSDB points to a transit object Y (router or network), then the object Y must also point back to object X - they must be bidirectionally connected in the LSDB. If not, they are ignored during SPF (see RFC 2328, Section 16.1, step 2b). Here, this requirement is broken. That is the reason why your routing tables are only partial or even empty.
This is one of several pitfalls when running a partially-meshed Frame Relay using the NBMA network type and when not paying attention to the DR elections.
Please feel welcome to ask further. I know that this is not an easy topic to grasp.