I tried to recreate your scenario, and I tried to issue both the redistribute connected command as well as the redistribute connected subnets command. However, whenever I issued the former, the router automatically added the subnets keyword afterward. I’m not sure why that’s taking place, but that’s another issue.
When I used the redistribute connected subnets command, I found that the connected network of 2.2.2.2/31 was redistributed like so:
R1#show ip route ospf | begin Gateway
Gateway of last resort is not set
2.0.0.0/31 is subnetted, 1 subnets
O E2 2.2.2.2 [110/20] via 192.168.12.2, 00:02:19, GigabitEthernet0/1
Could it be in your case that the problem lies elsewhere? Take a look at the OSPF neighbor state, and see if you can actually share other OSPF networks using the network command. If that is successful, then you should follow some of the troubleshooting tips in the following lesson to try to resolve it:
Let us know how you get along so we can help you further in your troubleshooting process…
Yes, all I did was add the redistribute connected subnets command. Here’s my config:
R1:
interface Loopback0
ip address 1.1.1.1 255.255.255.254
!
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router ospf 1
redistribute connected subnets
network 192.168.12.0 0.0.0.255 area 0
!
R2:
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router ospf 1
network 192.168.12.0 0.0.0.255 area 0
And you can see in R2, we have the following:
R2#show ip route ospf
!<-- output omitted -->
Gateway of last resort is not set
1.0.0.0/31 is subnetted, 1 subnets
O E2 1.1.1.0 [110/20] via 192.168.12.1, 00:03:37, GigabitEthernet0/1
As you can see from my configs, I have added this command on both routers:
network 192.168.12.0 0.0.0.255 area 0
Note that this is the subnet on the directly connected interfaces of the OSPF routers. This command is needed so that the routers can become OSPF neighbors. If you don’t add this command, then the routers will not become neighbors, and thus the redistribute command will have no effect. The connected routes that I’m sharing are those of the loopback, which is a /31 network.
Taking a look at RFC 2328 which describes OSPFv2, we can see that the neighbor field contains a list of router IDs of the routers with which it has established OSPF neighbor adjacencies. Specifically, the RFC states that the neighbor field contains:
The Router IDs of each router from whom valid Hello packets have
been seen recently on the network. Recently means in the last
RouterDeadInterval seconds.
LSAcks are not used for DBD exchanges according to every other source out there, most notably Cisco themselves. They all say the Master/Slave roles during ExStart state along with associated sequence numbers already serve the same purpose of LSAcks. I don’t actually see any LSAcks in Rene’s debug output.
You are indeed correct in your observation. Let me describe the process with the initial exchange of the DBD, and then let Rene know to make any necessary changes to the lesson:
After the Exstart State, the Master sends the DBD to the slave, and the slave responds by sending its DBD as well. This initial exchange of DBD packets does not use a specific acknowledgment mechanism in the same way that LSU packets are acknowledged by LSAck messages. Instead, the acknowledgment of DBD packets is implicit in the OSPF state machine process.
However, once the DBDs are exchanged, LSRs and LSUs may be exchanged to obtain additional, more updated information, as described in the lesson. When this takes place, LSAcks are subsequently sent to acknowledge the sending of the LSUs. Does that make sense?
Thanks for pointing this out, I will let Rene know to make any necessary changes.
As you mentioned in this article, the 2-way state is achieved when R2 sends a unicast reply to R1 instead of replying to the multicast address of 224.0.0.5 right?Can you please clarify?
In the packet capture is this packet number 8 ? but i see the DBD appear in packet-7.
DR/BDR Election:
I also see a tug of war b/w R1 & R2 for becoming the DR. This can be seen in packets:
7, 9 and 10 and in packet 10, R1 finally turns of the Master bit and sets a value of 0.
So if the DR/BDR election happens after the 2 way state, how are we are able to see the DBD in packet-7?
Please explain.
LSR and LSU:
Packet 13: LSR from R2 to R1 for 192.168.12.1
Packet 14: LSU from R2 to R1 for Packet 13
Packet 15: LSU from R2 to 224.0.0.5
Packet 16: LSU from R1 to 224.0.0.5
Can you explain what’s happening here? Why is there an LSU to the mcast group 224.0.0.5 from both Routers after a LSR?
Yes this is correct. This is the way the protocol is designed, and the most likely scenario. However, the OSPF definition gives some leeway concerning how vendors choose to implement these rules. The RFC 2328 states that:
The IP source address of an OSPF protocol packet is one end of a router adjacency, and the IP destination address is either the other end of the adjacency or an IP multicast address.
Also it says:
On broadcast networks, each router advertises itself by periodically multicasting Hello Packets.
So although the general rule is what Rene stated in the lesson, it’s not always implemented strictly. It may take a couple of exchanges of hellos before the OSPF algorithm switches over to unicast. I believe that in the Cloudshark capture, the 2Way state is achieved after packet 2, since R2 sends a hello to R1 that contains its own router ID in the neighbor field.
Actually, the master bit is not involved in the DR/BDR election. The master/slave is a relationship between OSPF routers that become neighbors and determines how they can communicate. The DR/BDR election is determined using the Router Priority and the router IDs. You can only see the DR and BDR within hello packets, so you wouldn’t see this information in packets 7, 9, and 10 which don’t contain this information. The initial DR/BDR election takes place after the 2way state. That doesn’t mean that the DR/BDR election can’t take place again at any time. So initially, we see the DR/BDR election take place, and by packet 3 (after the 2 way state) the DR and BDR are already (initially) determined.
According to the RFC:
Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always sent directly to the neighbor.
So LSUs are always sent as multicast, unless they are responding to a specific LSR. Does that make sense?
Indeed, looking through the wireshark capture, I see that the 2.2.2.0/24 network does not appear in any LSAs. It could be that when Rene performed the wireshark capture, the 2.2.2.0/24 network was not being advertised by OSPF. I will let Rene know to take a look and consider making some corrections.
Hello Rene and the entire Network Lessons Team,
In my understanding, if the priorities of the OSPF routers are identical, than both the DR/BDR election and the master/slave election is determined by the router-id.
For both the scenarios in the example routers, the router with the highest ID is suppose to be both the DR and the master, but i can see clearly in the “debug ip ospf adj” output, that the DR is 1.1.1.1 and not 2.2.2.2, but the master is 2.2.2.2.
R2#
OSPF: Elect BDR 2.2.2.2
OSPF: Elect DR 1.1.1.1
OSPF: Elect BDR 2.2.2.2
OSPF: Elect DR 1.1.1.1
DR: 1.1.1.1 (Id) BDR: 2.2.2.2 (Id)
OSPF: Send DBD to 1.1.1.1 on FastEthernet0/0 seq 0x1E09 opt 0x52 flag 0x7 len 32
OSPF: Rcv DBD from 1.1.1.1 on FastEthernet0/0 seq 0x886 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
OSPF: First DBD and we are not SLAVE
OSPF: Rcv DBD from 1.1.1.1 on FastEthernet0/0 seq 0x1E09 opt 0x52 flag 0x2 len 72 mtu 1500 state EXSTART
OSPF: NBR Negotiation Done. We are the MASTER
My question is about the configuration which isn’t shown in the bottom of the lesson, were there any change in the router priorities not mentioned, or how come that the DR and master routers are not the same router?
You’re correct in your understanding that if OSPF router priorities are identical, the router with the highest router ID would be elected as the DR. However, the DR/BDR election process and the master/slave election during the OSPF database exchange process are two different things. They take place at different times, and when modifications are made, they behave differently.
The DR/BDR election happens when OSPF routers first become adjacent on a network segment.
The master/slave election, on the other hand, happens during the Database Description (DBD) exchange process, which is a part of the OSPF adjacency formation process. The router that wins this election (the master) starts the DBD exchange, and the other router (the slave) responds. In this case, the router with the highest router ID becomes the master.
So, in your scenario, it seems like 1.1.1.1 was elected as the DR and 2.2.2.2 was elected as the master during the DBD exchange process. This is possible if 1.1.1.1 became the DR before 2.2.2.2 came up. When 2.2.2.2 came online, it couldn’t pre-empt the DR role from 1.1.1.1, but it was able to win the master role during the DBD exchange due to its higher router ID.
You see, the DR/BDR election isn’t preemptive. If there is a stable DR already elected, even if a new router with a higher router ID is configured and connected, no election takes place. Take a look at these networkLessons notes for more information on this topic:
Hello Guys
I have one question, after the first hello sent it by R1 to 244.0.0.5 R2 will respond with a unicast packet to R1, right? When you said "R1 will receive this hello packet and sees its own router ID. We are now in the two-way state." -that means that I will find it in a packet capture on the field “active neighbor” the R1 router-id?
Indeed, that information is found within the “Active Neighbor” filed in the OSPF Hello packet. This shows the router ID of the OSPF neighbor. So R1 should see its own router ID in that field.
