|
0:00:14
|
The next network type we have here in OSPF is the point-to-point
|
|
0:00:19
|
that will be default in any type of point-to-point media like HTLC or PPP.
|
|
0:00:24
|
Now, we saw this before on the..
|
|
0:00:27
|
Ethernet link that was between the router 5 and switch 2,
|
|
0:00:30
|
I configured the network type as point-to-point,
|
|
0:00:33
|
which means that they will no longer be generating
|
|
0:00:36
|
the Type-2 LSA that is normally reserved for the designated router.
|
|
0:00:42
|
So, in addition to actual point-to-point links,
|
|
0:00:45
|
like the serial link that is between router 2 and router 3,
|
|
0:00:49
|
between router 3 and router 1,
|
|
0:00:51
|
we could also use point-to-point network type
|
|
0:00:54
|
on any Ethernet or other multipoint media like frame-relay multipoint
|
|
0:00:59
|
that has only two neighbors on the segment.
|
|
0:01:02
|
Again, the advantage of that is that in addition to the LSA 1
|
|
0:01:07
|
that we would always generate the router's LSA,
|
|
0:01:10
|
we would not be generating LSA 2 from the designated router.
|
|
0:01:15
|
Now, as I mentioned before,
|
|
0:01:17
|
as part of the adjacency establishment,
|
|
0:01:20
|
the network type technically does not have to directly match
|
|
0:01:24
|
as long as it is compatible based on the LSA numbers that are used.
|
|
0:01:30
|
So, we'll see that if we look at the network types that can run...
|
|
0:01:34
|
with different network types. As long as we...
|
|
0:01:39
|
either support the DR/BDR election,
|
|
0:01:44
|
or do not,
|
|
0:01:47
|
where the two types that do run the election would be broadcast,
|
|
0:01:52
|
and non-broadcast,
|
|
0:01:58
|
where the types that do not run the BDR election would be point-to-point,
|
|
0:02:04
|
point-to-multipoint,
|
|
0:02:06
|
and point-to-multipoint non-broadcast.
|
|
0:02:09
|
Now, a case where you would mismatch these...
|
|
0:02:13
|
and it would be fine in the design,
|
|
0:02:14
|
let's say that between the frame-relay spokes and the frame-relay hub,
|
|
0:02:19
|
on the spokes, we are running these links as point-to-point sub-interfaces.
|
|
0:02:25
|
So, for all of the spokes, routers...
|
|
0:02:28
|
1, 2, 3, and 4,
|
|
0:02:30
|
I'm gonna change them from their main interfaces that are multipoint.
|
|
0:02:34
|
We're gonna change these to point-to-point sub-interfaces.
|
|
0:02:37
|
We will then see that it should change the default network type in OSPF
|
|
0:02:42
|
from non-broadcast to point-to-point.
|
|
0:02:44
|
So first, on router 1, let's look at the...
|
|
0:02:47
|
Show Run Interface Serial 0/0.
|
|
0:02:51
|
I'm gonna take the IP address off of the main interface,
|
|
0:02:56
|
and we'll move it to the sub-interface.
|
|
0:02:58
|
So, to simplify this, I'll just say Default...
|
|
0:03:01
|
Interface Serial 0/0.
|
|
0:03:07
|
On the serial link, we will be running frame-relay.
|
|
0:03:10
|
So, Encapsulation Frame-Relay.
|
|
0:03:12
|
We'll have a point-to-point sub-interface...
|
|
0:03:16
|
that has the IP address and the frame-relay...
|
|
0:03:20
|
interface DLCI, which in this case is 105.
|
|
0:03:27
|
And we'll do the same thing on...
|
|
0:03:30
|
router 2. So, Default Interface Serial 0/0.
|
|
0:03:36
|
We'll Re-encapsulate Frame-Relay.
|
|
0:03:39
|
We'll have a point-to-point sub-interface...
|
|
0:03:44
|
that has the IP address 155.42.0.2.
|
|
0:03:53
|
And the frame-relay interface DLCI, 205.
|
|
0:03:58
|
Now, I could likewise do this on router 3 and router 4,
|
|
0:04:02
|
but for the sake of this example, we'll just use two of the routers.
|
|
0:04:04
|
Now, if we look at the Show IP OSPF Interfaces,
|
|
0:04:09
|
we'll see now that the sub-interface for frame-relay,
|
|
0:04:13
|
which is serial 0/0.1,
|
|
0:04:16
|
this is running OSPF area zero,
|
|
0:04:18
|
because we have a network type, or a network statement, excuse me.
|
|
0:04:21
|
Network statement under the OSPF process
|
|
0:04:25
|
that is matching the IP address we have assigned to the link.
|
|
0:04:28
|
Since this is a point-to-point sub-interface, it then means that the network type will be point-to-point by default.
|
|
0:04:36
|
Notice that the point-to-point network type is using the hello timer of 10
|
|
0:04:41
|
and the dead interval of 40.
|
|
0:04:44
|
The weight time is also 40, but this is not gonna be used,
|
|
0:04:47
|
because we're not using the DR and BDR election.
|
|
0:04:52
|
Now, if we look at router 5
|
|
0:04:54
|
who is on the other end of the link,
|
|
0:04:56
|
and we Show IP OSPF Interface Serial 0/0/0,
|
|
0:05:02
|
this link is configured as point-to-multipoint,
|
|
0:05:05
|
which is using the default timers of 30 and 120.
|
|
0:05:12
|
So, although the network types are compatible,
|
|
0:05:15
|
we would see that router 1 will not establish an adjacency with 5,
|
|
0:05:19
|
and neither will 2 and 5
|
|
0:05:21
|
simply because their hello intervals are mismatched.
|
|
0:05:26
|
If we were to look at the Debug IP OSPF Adjacency,
|
|
0:05:29
|
and the Debug IP OSPF Hello Packets,
|
|
0:05:33
|
we'll see that when router 5 receives the hellos from 1 or 2,
|
|
0:05:40
|
it's gonna tell us that these parameters are mismatched.
|
|
0:05:52
|
So, this would then imply if we did want to use network types together,
|
|
0:05:57
|
point-to-point and point-to-multipoint at the same time,
|
|
0:06:01
|
it's fine as long as all the other parameters of the adjacency are matching.
|
|
0:06:06
|
So, if I were then to go to router 1 and router 2 at the sub-interface,
|
|
0:06:12
|
and change the IP OSPF hello interval to 30 seconds,
|
|
0:06:17
|
it means that this will automatically then update the dead interval to a 120 seconds,
|
|
0:06:26
|
So I should now be able to establish the adjacency with router 5.
|
|
0:06:30
|
Likewise if I were to do this on router 1,
|
|
0:06:36
|
IP OSPF hello interval is 30.
|
|
0:06:42
|
If we look at router 5, if we Show IP OSPF Neighbors,
|
|
0:06:47
|
we could see now we do have the adjacency with router 2.
|
|
0:06:51
|
So, it's not gonna effect anything else about the advertisement of the network.
|
|
0:06:56
|
If we were to look in the database, we'll see that this is still considered a point-to-point adjacency
|
|
0:07:01
|
between router 2 and router 5.
|
|
0:07:04
|
It's just that if we do have the point-to-point sub-interfaces here on the spokes,
|
|
0:07:10
|
we don't necessarily need to set this as point-to-multipoint network type,
|
|
0:07:16
|
we could leave it as the default point-to-point
|
|
0:07:18
|
as long as the other attributes are matching.
|
|
0:07:21
|
So, the hello interval, the dead interval,
|
|
0:07:23
|
the authentication, the stub flags, the area number,
|
|
0:07:26
|
all of that stuff has to match in order for the adjacency to occur.
|
|
0:07:31
|
Now, what will not be supported
|
|
0:07:34
|
is if we are running any combination of point-to-point and broadcast,
|
|
0:07:43
|
or point-to-multipoint and non-broadcast,
|
|
0:07:46
|
point-to-multipoint and broadcast,
|
|
0:07:47
|
we'll see that this routers would form a neighbor relationship
|
|
0:07:53
|
if the network types are mismatched, but they would not actually form an adjacency.
|
|
0:07:59
|
And it can kind of a difficult problem to troubleshoot.
|
|
0:08:03
|
If we were to look at let's say the link between router 5 and switch 2,
|
|
0:08:09
|
on router 5, I have this configured as point-to-point network type.
|
|
0:08:15
|
Let's go to switch 2, and we'll set it back to the default. We'll set it to broadcast.
|
|
0:08:23
|
So, on switch 2's interface VLAN 58,
|
|
0:08:27
|
we'll say the IP OSPF network is broadcast, which is the default.
|
|
0:08:32
|
And I'll also change the hello interval to match what router 5 has.
|
|
0:08:38
|
So, the point-to-point network type hello interval is 10,
|
|
0:08:41
|
where on broadcast and non-broadcast, it is 30.
|
|
0:08:46
|
So, if we look at the Show IP OSPF Neighbors,
|
|
0:08:49
|
we'll see that router 5 and switch 2 will form a neighbor relationship,
|
|
0:08:58
|
but when we actually look in the database and then the routing table,
|
|
0:09:03
|
they're not able to build the graph to input the SPF.
|
|
0:09:10
|
So, let's see on router 5, if we Show IP OSPF Neighbors,
|
|
0:09:15
|
router 5 says, "The adjacency to switch 2 is up. It's in the full state."
|
|
0:09:20
|
On switch 2, if we Show IP OSPF Neighbors,
|
|
0:09:24
|
likewise, switch 2 says this is okay,
|
|
0:09:27
|
but notice one of the differences here.
|
|
0:09:30
|
Switch 2 says router 5 is the BDR, which means I am the DR.
|
|
0:09:37
|
Router 5 says that switch 2 is neither the DR nor the BDR.
|
|
0:09:45
|
This is an indication here that there is a mismatch between the network types.
|
|
0:09:49
|
But if we were now to look at the database of switch 2,
|
|
0:09:53
|
Show IP OSPF Database,
|
|
0:09:56
|
we see that we actually learn the LSAs
|
|
0:10:01
|
in area zero,
|
|
0:10:06
|
but when we look at our own originated LSA, which is this 150.42.8.8,
|
|
0:10:13
|
if we Show IP OSPF Database for the router 150.42.8.8,
|
|
0:10:27
|
it says that "On this segment, I am adjacent with the designated router."
|
|
0:10:29
|
Designated router's address is the same as mine. It means that I am the DR.
|
|
0:10:33
|
If I now Show IP OSPF Database for the network LSA 155.42.58.8,
|
|
0:10:43
|
it says, "I'm the DR.
|
|
0:10:46
|
I'm adjacent with 5, and I'm adjacent with 8."
|
|
0:10:51
|
If we now look at router 5's router LSA,
|
|
0:10:55
|
Show IP OSPF Database for the router 150.42.5.5,
|
|
0:11:07
|
router 5 says that this is a point-to-point adjacency
|
|
0:11:12
|
that is going directly to switch 2.
|
|
0:11:16
|
Where is they were running compatible network types,
|
|
0:11:20
|
router 5 should say that it is adjacent with the DR.
|
|
0:11:25
|
The end result of this is that there is a mismatch in the data structure
|
|
0:11:29
|
between router 5's database view and switch 2's database view.
|
|
0:11:32
|
So, if we look in the routing table,
|
|
0:11:35
|
we can actually install the prefixes.
|
|
0:11:40
|
So, it appears that the database synchronizes, but when we look at the detail of the path selection,
|
|
0:11:47
|
if we did some sort of low level debug on the OSPF SPF process,
|
|
0:11:51
|
we would see that there's a failure in the path selection state machine,
|
|
0:11:57
|
because router 5 and switch 2 don't agree who they are adjacent with on that segment of the graph.
|
|
0:12:04
|
But again, it's kind of hard to troubleshoot, because when we look at he Show IP OSPF Neighbors,
|
|
0:12:09
|
it looks fine on this side, it says that "I'm adjacent with router 5,
|
|
0:12:12
|
they're the backup designated router."
|
|
0:12:15
|
Even when I look in the database,
|
|
0:12:18
|
I'm receiving all the LSAs,
|
|
0:12:22
|
but then, based on the fact that they're not installed in the routing table,
|
|
0:12:25
|
we then know that there's something wrong.
|
|
0:12:27
|
So again, we can allow for mismatches on the network types
|
|
0:12:32
|
as long as they don't cross this boundary where we have the ones that support the Dr and BDR election,
|
|
0:12:38
|
and then the ones that do not.
|
|
0:12:40
|
So, we have point-to-point adjacent with point-to-multipoint, that was fine.
|
|
0:12:44
|
We could have broadcast adjacent with broadcast, that's fine.
|
|
0:12:47
|
But broadcast and point-to-point, non-broadcast and point-to-multipoint,
|
|
0:12:51
|
those are not gonna be supported.
|
|
0:12:53
|
So, on switch 2, I'll then say on this VLAN 58,
|
|
0:12:56
|
we'll run this as OSPF network point-to-point.
|
|
0:13:00
|
So now, we're matching with what router 5 says.
|
|
0:13:03
|
If we look at the routing table,
|
|
0:13:07
|
we could see now, we can install all of those entries.
|
