Hi,
How does OSPF prevent loops INSIDE an area?
Thanks,
Nihar
Hello Alessandro
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ā¦
I hope this has been helpful!
Laz
Hi,
but u have configured only redistribute connected subnets command under OSPF process?
Or u have add network 192.168.1.2 0.0.0.1 area 0 command?
Can u show your configuration?
Thanks.
Hello Alessandro
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.
I hope this has been helpful!
Laz
Hello Nihar
Take a look at this post:
I hope this has been helpful!
Laz
Hi Rene,
1 question : when R1 sends hello packet what information will be there in Neighbor field
Hello Prashant
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.
I hope this has been helpful!
Laz
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.
Hello CJ
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.
I hope this has been helpful!
Laz
No problem, thanks for clarifying!
1 Like
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?
Hello Adhithya
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?
I hope this has been helpful!
Laz
1 Like