Two routers are trying to establish an OSPFv3 adjacency over an Ethernet link, but the adjacency is
not forming. Which two options are possible reasons that prevent OSPFv3 to form between these
two routers? (Choose two.)
A.
mismatch of subnet masks
B.
mismatch of network types
C.
mismatch of authentication types
D.
mismatch of instance IDs
E.
mismatch of area types
The authentication type has to be the same between neighbors.
Instance IDs are only locally significant to the router so it doesn’t matter if they match.
Instance ID is carried in the OSPFv3 Header
authentication n network type
More,ospfv3 troubleshooting
1. Area ID -show ipv6 ospf interface brief
2. Connectivity, ping
3. Timer , dead interval must be at least four times the hello interval
4. Authentication, type must be same between neighbours
5. network type, must be matched, point-to-point or broadcast
6. ACL-no blocking
7. Debug for more details info
So you should know what are the correct answers
OSPFv3 includes support for multiple instances of OSPF running in parallel across a common link. This is especially handy for shared network segments such as those found in Internet exchange points. On Cisco IOS, OSPFv3 instances are configured by appending the instance argument to the ipv6 ospf statement
if you have a mismatch in network type but you adjust timers to match then adjacency will form.
However the SPF tree can’t be built so you will have no routes installed. OSPF does not know how to build the tree when there is a mismatch in network types that don’t agree on if DR should be used or not.
There is no requirement for matching subnets because link local addresses are used for forming the adjacency.
OSPFv3 does not have ANY authentication of it’s own. It relies on IPSEC to secure communications between neighbors.