Remember that a DR/BDR election takes place on a per-network segment basis, and not on a per-area basis. This means that an OSPF router connected to multiple network segments may be a DR on one segment, a BDR on another, and neither on a third. This post tells you much more about this situation:
Now to answer your question specifically, you can see in the output you provided that:
on the network segment connected to the interface with IP address 10.12.0.1 the router is a DR
on the network segment connected to the interface with IP address 10.24.0.4 the router is a BDR
on the network segment connected to the interface with IP address 10.23.0.3 the router is neither
You can see this from the state column. So you see, a router can be DR, BDR, or neither at the very same time!
To answer this question, take a look at the following post:
I have a question i was reading about summary LSA and found somthing that’s confusing me
ABR expects summary LSAs from Area 0 only. This means there should
be at least one adjacency in FULL state built over Area 0 interface. In
case if ABR has such adjacency, it will ignore summary-LSAs received
over non-backbone areas. These LSAs will be installed in the database,
but not used for SPF calculations.
ABR will accept and use summary-LSAs learned over non-backbone area
if it DOES NOT have a FULL adjacency built over an Area 0 interface. It is
safe to do so, since the ABR will not be able to flood the summary back
into Area 0 creating routing loops
question
so summary LSA is only allowed form area 0
if yes and an ABR is installed between 4 areas how will all other areas will know each other
As you can see, a Type 3 LSA is generated by an ABR as a result of the receipt of a Type 1 LSA from a non-backbone area. This Type 3 LSA may be relayed to other non-backbone areas, as you can see, but will never originate in a non-backbone area. Type 3 LSAs are only generated and sent out of interfaces of ABRs that are on Area 0 and are received by ABRs only on their Area 0 interfaces.
Therefore the statement “ABR expects summary LSAs from Area 0 only.” is correct. However, summary LSAs are allowed in non-backbone areas, and non-ABR routers in those areas may receive them. There is an exception to this rule, as stated in point number 2 in your post.
As for your second question, I believe it has been answered. Non-ABR routers can and do receive Type 3 LSAs from the ABR in non-backbone areas so they do indeed learn of each other’s networks.
In your topology, it looks like R7 has one interface (F0/0) in area 2, while interface f0/1 is not participating in OSPF at all. Also, if we use a prefix of /24 it looks like the VM and F0/1 on R7 are in the same subnet.
If that is correct, then R7 becomes an Autonomous System Border Router (ASBR) because it has at least one interface in an OSPF area (F0/0) and at least one interface in a non-OSPF area (F0/1).
In order to allow your OSPF topology to learn about the subnet in which your VM exists, you must redistribute the route to the 192.168.85.0/24 subnet into OSPF. This is done using the redistribute command on R7.
In this particular case, you would use the redistribute connected subnets command in the OSPF configuration of R1. This will redistribute the subnets of connected interfaces on R7 that are not participating in OSPF, namely the 192.168.85.0/24 subnet.
If your VM was not on a directly connected subnet, then you could create a static route in R7 and then use the redistribute static command.
In any case, if R7 knows how to get to the VM IP address, using any means (directly connected, static, or another routing protocol), you can use the redistribute command to inject that route into OSPF.
Hello Laz
The following is the routing table of R7 and R6. It seems that the 192.168.85.0/24 subnet has been redistributed to the ospf area, but R6 still cannot establish communication with the vm (make sure the network where the vm is located is 192.168.85.0/24).
R7:
R6:
Since the destination network is correctly within the routing tables of the routers involved, then it looks like OSPF is working fine. If you don’t have connectivity, then you will have to look elsewhere for the problem.
The first thing you should always do in such cases is to ensure that the closest router to the destination has connectivity with the destination. In this case, it is R7, and the destination is in the same subnet as the F0/1 interface of R7. Can R7 ping the VM? If not, then you should check the configuration on the VM (default gateway) and the network on which the VM is installed.
If you can ping from there, then you will have to trace your way back and check the whole path from the source to the destination.
Some things to keep in mind:
Remember that routing must be configured correctly for both directions to function. The 192.168.85.0 network may be in the routing table, but is the subnet of the pinging device also in all the routing tables so that the response can reach it?
Make sure the default gateway on the VM is configured correctly.
These thoughts may be able to help you out in your troubleshooting process.
The chapter mentions that the Area ID needs to be same for the routers to be OSPF neighbors. But I have a setup where the routers have different Area IDs and the link type is point-to-point and they have adjacency established between them. Could you please clarify if the requirement of matching Area ID applies for point-to-point link types also.
When we talk about “an OSPF router being in area 0” we have to keep in mind that some OSPF routers are in multiple areas. This is because the designation of area is not something that belongs to the router as a whole, but to particular interfaces. OSPF routers that have interfaces in different areas are called Area Border Routers or ABRs.
The network command specifies subnets that belong to a specific area. In turn, the interfaces with IP addresses within those defined subnets belong to those areas. Two directly connected OSPF routers will become neighbors only if the interfaces through which they are connected are in the same area. This is the case regardless of the network type being used.
I labbed this up just to be sure, and I configured point-to-point OSPF networks on both ends, with different area IDs, and an adjacency did not form. I did however get this error:
00:11:43: %OSPF-4-ERRRCV: Received invalid packet: mismatch area ID, from backbone area must be virtual-link but not found from 10.10.10.2, GigabitEthernet0/0/0
Hey guys,
just want to be sure. The OSPF topic/explanation is about OSPFv2, right ?
Because there is OSPFv3 out there but for CCNA only OSPFv2 is needed.
Using /31 prefixes for point-to-point links in IPv4 is considered acceptable, and is well defined within RFC3021. As such, OSPF, as well as other routing protocols are able to advertise /31 addresses normally, without any additional configuration parameters. I labbed this up and confirmed that a /31 prefix was successfully advertised by OSFP:
O 192.168.14.0/31
[110/2] via 192.168.12.1, 00:02:45, GigabitEthernet0/1
I labbed this up and tested it and yes indeed, in order for two OSPF routers to become neighbors, they must be directly connected, and each must have an interface in the same subnet, and have the same subnet mask on those interfaces.
Hello Rene, i’m studing for CCIE IE and, topics on BP of CCIE exam as topic 1.4 OSPFv3 and 1.4.e i Metrics don’t have in this lessons, can you help me about this?
Take a look at this lesson, as well as several subsequent lessons. There you will find all the information about OSPFv3:
You can also take a look at this lesson to see how OSPFv3 is used for IPv4:
Concerning OSPF metrics, as a topic, this is expressed in various areas and lessons. There is no single lesson on “OSPF metrics”. This is one of those topics that you will learn about as you go through the content sequentially. Some particular lessons that mention OSPF metrics include:
It’s really a gateway problem 