You need to look into OSPF network types a little more. The default network type for frame when not point-to-point is nonbroadcast. This means there will be a DR/BDR elected but no dynamic discovery of neighbours. So far so good, you've disabled DR election for your hub routers but I have a strange feeling they can only be a neighbour with the DR if they are not participating in the election process.
To be honest, if you're going for a hub and spoke design why not use point-to-multipoint as your network type, or seeing as though you have a full mesh, use broadcast as your network type. If you want to manually configure neighbours you can use point-to-multipoint nonbroadcast.
Others may have a better idea of why what you are attempting doesn't work but from a design point it doesn't make sense with a full mesh.
If you wish to simulate a partial mesh you can disable inarp and do static mapping.
Yes, I realize broadcast or point-to-multipoint would be the apropriate network type for this, but to be honest I intially noticed this in a partial mesh lab I was working on (trying to form neighborships with routers in the partial mesh that had PVCs connecting them) and didn't want to convolute this post.
Also this comment has me confused: "I have a strange feeling they can only be a neighbour with the DR if they are not participating in the election process."
The problem comes when I try to create neighborships with NON DRs which are directly connected and pingable via PVCs. Should these routers not be in the two-way state?
Sorry for the very vague statment, you would think, having just passed my ROUTE exam that this stuff would still be fresh.
For a proper neighbourship to form, each statically defined neighbour must see itself in hello's recieved from the other neighbours.
Also check to see if your dynamic frame relay maps include broadcasts, I presume they do as you have a proper relationship with the DR.
"Two-way: There is bi-directional communication with a neighbor. The router has seen itself in the Hello packets coming from a neighbor. At the end of this stage the DR and BDR election would have been done. At the end of the 2way stage, routers will decide whether to proceed in building an adjacency or not. The decision is based on whether one of the routers is a DR or BDR or the link is a point-to-point or a virtual link."
Perhaps for some reason the neighbour statements are sending the wrong details so that the recieved hello's don't contain the right router id?
You could do a debug ip ospf adj to see if there is anything it is complaining about.
Checking the link you gave me this verifies what I asked before:
"On broadcast media and non-broadcast multiaccess networks, a router becomes full only with the designated router (DR) and the backup designated router (BDR); it stays in the 2-way state with all other neighbors."
So to exlain my latest actual topology:
I have 5 routers: R1, R2, R7, R9, R10
R7 is the DR (priority 3)
R9 is the BDR (priority 2)
All other routers have a priority of 0
There are PVCs connecting all routers using INARP - EXECPT R2 and R10 making this a partial mesh
After entering the "neighbor 10.100.100.2" command on R1 and running some debugs heres what I get as explained before:
[R1 IP: 10.100.100.1 - router-id: 18.104.22.168]
[R2 IP: 10.100.100.2 - router-id: 22.214.171.124]
*Mar 1 00:46:05.535: OSPF: Sending poll to 0.0.0.0 address 10.100.100.2 on Serial0/3
*Mar 1 00:46:05.535: OSPF: Send hello to 10.100.100.2 area 0 on Serial0/3 from 10.100.100.1
show ip ospf ne:
Neighbor ID Pri State Dead Time Address Interface
N/A 0 ATTEMPT/DROTHER - 10.100.100.2 Serial0/3
126.96.36.199 3 FULL/DR 00:01:34 10.100.100.7 Serial0/3
188.8.131.52 2 FULL/BDR 00:01:43 10.100.100.9 Serial0/3
*Mar 1 01:00:36.103: OSPF: Rcv hello from 184.108.40.206 area 0 from Serial0/3 10.100.100.1
show ip ospf ne:
Neighbor ID Pri State Dead Time Address Interface
220.127.116.11 0 INIT/DROTHER 00:01:19 10.100.100.1 Serial0/
18.104.22.168 3 FULL/DR 00:01:43 10.100.100.7 Serial0/3
22.214.171.124 2 FULL/BDR 00:01:52 10.100.100.9 Serial0/3
So its seems R1 is sending R2 hellos, but R2 is not responding. These routers do have a PVC connecting them and can ping each other.
I am using dynampis as well, but I have a feeling there is some important protocol stuff going on here I don't understand thats the cause of this.
-To add doing a show "fram map" on both routers shows all thier dynamic mappings allow broadcasts.
I would guess that the hellos are getting from R1 to R2 but are being rejected by R2?
Also I note that R1 has a state of ATTEMPT which according to my TSHOOT book is after a router sends a unicast hello which would make sense if you had statically defined your neighbours.
Going back to your original post:
- statically defining a neighbour only on one side would result in that side sending a unicast hello to the defined neighbour.
- The sending neighbour would go to the ATTEMPT state (so far so good)
- The receiving neighbour would go to the INIT state upon receving the hello (so far so good)
- At this point the receiving neighbour does not respond.
So what you are seeing in the neighbour states matches exactly with the receiving neighbour not responding to a unicast hello.
Do you have a symetric neighbour statement on both ends?
Is your network type set to require static neighbours? e.g. nonbroadcast
Does all your neighbour criteria match? Hello timer, Dead timer, Area, Area type, subnet (including mask) and authentication?
Does the neighbourship work when you change the network type to something that does dynamic neighbour discovery (broadcast/point-to-multipoint)?
That's all that I can think of right now.
Ryan has given you a good start point in his last post. In addition, please verify the neighbor relationships on all routers with the "sh ip ospf nei" command. You mention you have connection with all routers via PVC except R2 and R10. However, in the outputs you provided it shows that even R1 and R2 are not connecting. I suspect because the priority on R1 = R2 = R10 = 0, you will not be able to form neighbor adjacencies between these routers. They will only be able to form neighbor adjacencies with R7 (DR) and R9 (BDR). I see from the output it looks as though you have a single subnet for all routers 10.100.100.0/24, with the router number equal to the last octet. Can you post some configs (text files) for each router. This may help us understand exactly wehat is going on.
I will lab this up when I get to work and see what I get.
Thanks for all your replies. I'll posted the configs when I get home, but I have a question about this:
"I suspect because the priority on R1 = R2 = R10 = 0, you will not be able to form neighbor adjacencies between these routers."
I think Ryan was saying the same thing before. If both of the routers priority is 0 neither one will be the DR, BUT I didn't think this would have any bearing on them forming a neighborship or at least getting to the two-way state with each other- its not like the master/slave relationship can't form, they would just compare IPs if their priority is the same.
Like say I plug a bunch of routers into a switch and set the priority of all of them to 0 except for 1, that one router will be the DR for all routers. The routers' neighborships with non DR routers will be stuck in two-way (which I'm told is exceptable in this scenario). This is why I said maybe I'm missing something, because I thought if I essentially have the same thing over a NBMA frame cloud (adding the necessary neighbor commands) shouldn't I be able to form two-way neighborships between non-DR/BDR routers?
And if I don't set the routers I want to be non-DRs priority to 0 than that could lead to issues where the wrong router is elected DR right? Like if two non-DR routers reboot and "find" each other before they get any hellos from the desired DR they'll elect one of themselves DR- big problem.
Also when you ask "Do you have a symmetric neighbour statement on both ends?"- I thought I only had to configure the neighbour statement from one side.
Ben & Ryan,
I suspect the priority may be a problem. Reason behind my thoughts, the default network type for OSPF is NBMA, and you have a DR/BDR selection. Which means all routers for adjacencies with the DR/BDR. However, you were trying to form an adjacency between two DROTHERS, which may not be possible. I still would like to see some configs of atleast the serial interfaces and ospf for each router. I did lab this up at work last (simulator) and I had nop problem bringing up the FR network (did that first) The config on the serial interface where very basic.
ip add 192.168.1.1 255.255.255.0
this was on all routers ( note IP add were .1, .2, .3, .4, and .5 all /24 prefix)
The default for the FR links on physical interface (no subinterfaces used) is Cisco's proprietary P2M (broadcast). This can be seen in the output of the "sh frame-relay map" command. Inverse-ARP is enabled by default, and all PVCs will come up. I could ping from R1 to all other routers serial interface.
When I enabled OSPF, I only had neighbor adjacency between R4 (BDR) and R5 (DR), due to the Router-Id R4 = 126.96.36.199 and R5 = 188.8.131.52. The others would not form. In my simulator I am limited on the debug commands, so could not look deeper into this. Remember with OSPF over NBMA, you need to fix either with the "neighbor" command under the OSPF routing process or use "ip ospf network point-to-mulipoint" under the serial interfaces. Again my simulator would not take the neighbor commands (this is being phased out in favor of the ospf network commands). When I put the "ip ospf network point-to-multipoint" command under the interfaces all was good. When you do this there will be no DR/BDR selection, and all adjacencies will form to "FULL" state. I am at home now, but will post the configs when I get back to work tonight. The network type for the interface should change to P2M. Can be verified with the "sh ip ospf int s0" command. My simulator still showed them as P2P (default for serial ports).
Again, your router configs would really help. I created a little frame-relay network with five routers (R1 - R5), but I want to make sure I set up my frame-relay network the way you did, or at least as close to what you have.
Look forward to your replies.
Thanks Ben, I will take a closer look when I get to work in the next couple of hours. I did notice that R7 is empty (no file). Also, can you provide a quick connection map R1 S0/3 to FRS x/x and so forth. This will make it easier than trying to go through all the mappings to see which router connects to which port on the FRS. Thanks.
I went through the configs and well had a little trouble identifying which DLCIs you were using for connection to each of the routers as some numbers were used more than once. In addition, I noticed you did not have all the DLCIs set up for full mesh capability. So, I created a little DLCI matrix for you. Use the following DLCI matrix below for your configs. Make sure that layer 2 (Frame Relay) comes up first. Then enable OSPF. The changes needed for each router can be found below as well.
From / To R1 R2 R7 R9 R10
102 103 104 105 R2 201 203 204 205 R7 301 302 304 305 R9 401 402 403 405 R10 501 502 503 504
**Use if inverse-ARP is enabled**
frame-relay interface-dlci 102
frame-relay interface-dlci 103
frame-relay interface-dlci 104
frame-relay interface-dlci 105
frame-relay interface-dlci 201
frame-relay interface-dlci 203
frame-relay interface-dlci 204
frame-relay interface-dlci 205
frame-relay interface-dlci 301
frame-relay interface-dlci 302
frame-relay interface-dlci 304
frame-relay interface-dlci 305
frame-relay interface-dlci 401
frame-relay interface-dlci 402
frame-relay interface-dlci 403
frame-relay interface-dlci 405
frame-relay interface-dlci 501
frame-relay interface-dlci 502
frame-relay interface-dlci 503
frame-relay interface-dlci 504
description CONNECTION TO R7
frame-relay route 301 interface serial0/1 103
frame-relay route 302 interface serial0/2 203
frame-relay route 304 interface serial0/3 403
frame-relay route 305 interface serial1/0 503
description CONNECTION TO R1
frame-relay route 102 interface serial0/2 201
frame-relay route 103 interface serial0/0 301
frame-relay route 104 interface serial0/3 401
frame-relay route 105 interface serial1/0 501
description CONNECTION TO R2
frame-relay route 201 interface serial0/1 102
frame-relay route 203 interface serial0/0 302
frame-relay route 204 interface serial0/3 402
frame-relay route 205 interface serial1/0 502
description CONNECTION TO R9
frame-relay route 401 interface serial0/1 104
frame-relay route 402 interface serial0/2 204
frame-relay route 403 interface serial0/0 304
frame-relay route 405 interface serial1/0 504
description CONNECTION TO R10
frame-relay route 501 interface serial0/1 105
frame-relay route 502 interface serial0/2 205
frame-relay route 503 interface serial0/0 305
frame-relay route 504 interface serial0/3 405
**If inverse-ARP is disabled you need to use the frame-relay map command. Also, you need to change the ospf network type with the ip ospf network command. Below is an alternate configuration for the routers. The FR switch config stays the same as above.
ip ospf network broadcast
frame-relay map ip 10.100.100.2 102 broadcast
frame-relay map ip 10.100.100.7 103 broadcast
frame-relay map ip 10.100.100.9 104 broadcast
frame-relay map ip 10.100.100.10 105 broadcast
ip ospf network broadcast
frame-relay map ip 10.100.100.1 201 broadcast
frame-relay map ip 10.100.100.7 203 broadcast
frame-relay map ip 10.100.100.9 204 broadcast
frame-relay map ip 10.100.100.10 205 broadcast
ip ospf network broadcast
frame-relay map ip 10.100.100.1 301 broadcast
frame-relay map ip 10.100.100.2 302 broadcast
frame-relay map ip 10.100.100.9 304 broadcast
frame-relay map ip 10.100.100.10 305 broadcast
ip ospf network broadcast
frame-relay map ip 10.100.100.1 401 broadcast
frame-relay map ip 10.100.100.2 402 broadcast
frame-relay map ip 10.100.100.7 403 broadcast
frame-relay map ip 10.100.100.10 405 broadcast
ip ospf network broadcast
frame-relay map ip 10.100.100.1 501 broadcast
frame-relay map ip 10.100.100.2 502 broadcast
frame-relay map ip 10.100.100.7 503 broadcast
frame-relay map ip 10.100.100.9 504 broadcast
The alternate example above I found while researching OSPF over Frame Relay.
Many of the documents I came across used the "frame-relay map" command rather than the "frame-relay interface dlci" command. Here are a few of those links:
Running OSPF in NBMA and Broadcast mode over Frame Relay
OSPF over Frame Relay subinterfaces
RFC on running OSPF over Frame Relay Networks
Ah sorry about the R7 config. I'll post it again. This wasn't supposed to be a full mesh though. I don't remember the exact setup, but heres essentially how I assigned DLCIs:
For the DR and BDR routers (I'll say R1 + R2 for this example, but my actual config was different)
R1: 103,104,105, 200(DLCI to R2)
R2: 203,204,205, 200(DLCI to R1)
R3: 103,203, 500(DLCI to R4)
R4: 104,204, 500(DLCI to R3)
I like to use the same DLCI numbers for each side of the link because it makes it easier for me to remember/configure. The fact that I statically assigned DLCIs was pretty unnecessary cause I'm not using sub-interfaces and now that I think about it I'm not sure why I did that. But all the "frame-relay interface dlci" command does is statically assign a DLCI to an interface . The "frame-relay map" is, at least how I think I would want to use in this example, how to tell a router to go through one router to get to another one. Like in the example I just gave in this post if I wanted R5 to talk to R4 I would have to type "fram map ip R4s_IP_ADDRESS 105 broadcast" for R5 to use its DLCI to R1 (the hub) to get to R4. I don't need to use it between routers directly connected via a PVC because INARP will take care of that mapping for me. So what about the two routers directly connected via PVCs like R3 and R4 in this example- could/should they be neighbors (two-way state)?
I played with the priority of two DROTHERs in a similar setup and was able to get them to the two-state but it kept going down on one side because according to the router the dead timer kept expiring (the hello and dead timers were the same I checked). Isn't that weird? I'm beginning to think this whole thing I'm trying to do is weird and stupid and pointless.
This is my reasoning and the source of my confusion: In a NBMA frame-relay star topology with a DR or DR+BDR where the DROTHERs are not directly connected to each other I thought you would only want them to form neighborships with the DR and BDR and not with each other. Then I thought if it was a partial mesh network where some DROTHERs did have PVCs to each other they should be neighbors in the two-way state so I've been trying to force these routers into the two-way state.
Thanks for the links- I'm reading the RFC now. Maybe my idea of how this should work is just dead wrong.
I Just wanted to update this thread, finish my thought- and also this thread.
I thought that an NBMA network worked similarily to a lan network, with respect to neighborships, in that all routers on the same segment would have neighborships (full with DR, 2-way with DROTHERS) with every "directly connected" OSPF router- and on a NBMA network I assumed two routers linked via a PVC would be the same as to routers on the same lan subnet- mmmm WRONG!
In the RFC link I got this awsomely resolute answer to my question:
"Other than the Designated Router (DR) and the
backup Designated Router (BDR), each router maintains only two
adjacencies, one each with the DR and BDR, regardless of the size of
the NBMA network."
So thats the end of that chapter. I think in my own confusion needlessly confused an already confusing concept, but in the process I learned a lot. Thanks for the help!