|
0:00:14
|
Our next feature we have here for frame relay is known
|
|
0:00:22
|
And it's designed to solve cases
|
|
0:00:24
|
where the Local Management
|
|
0:00:28
|
cannot report an accurate status of the end-to-end
|
|
0:00:35
|
So, between the two routers.
|
|
0:00:38
|
Now, in the normal case for LMI,
|
|
0:00:44
|
that if one of the switches went down, or the link
|
|
0:00:50
|
the other end of the circuit
|
|
0:00:53
|
with the circuit status going to inactive.
|
|
0:00:57
|
And again, we can see that when we look
|
|
0:01:01
|
The problem is that in some designs,
|
|
0:01:05
|
if we have a true frame relay network that is
|
|
0:01:12
|
typically, the providers would
|
|
0:01:16
|
or more commonly today,
|
|
0:01:19
|
if frame relay is being tunneled
|
|
0:01:25
|
like in the any transport over MPLS feature.
|
|
0:01:30
|
So in that case, the LMI is not
|
|
0:01:37
|
So, as part of the frame
|
|
0:01:40
|
there's a separate Layer 2 keepalive that is known
|
|
0:01:48
|
that runs directly between the DTE devices.
|
|
0:01:53
|
So, the idea behind this is that
|
|
0:01:57
|
to figure out if the link is up or down,
|
|
0:02:07
|
Now, configuration wise, this is gonna be
|
|
0:02:13
|
not to be confused with the
|
|
0:02:18
|
So, Map Class if for legacy frame relay
|
|
0:02:23
|
or if we were to do frame relay traffic shaping,
|
|
0:02:25
|
frame relay header compression, frame relay discard
|
|
0:02:34
|
So first, we define the Map Class name,
|
|
0:02:37
|
then, we pick what is the particular mode that
|
|
0:02:44
|
The important point to note about this...
|
|
0:02:47
|
is that it has to be run between
|
|
0:02:51
|
So, if you enable it on one side,
|
|
0:02:54
|
If I configure router 1 with the
|
|
0:03:02
|
this means that it is expecting the
|
|
0:03:09
|
In turn, if router 1 is configured to reply,
|
|
0:03:13
|
but it does not receive any requests
|
|
0:03:17
|
it will report its local circuit status down.
|
|
0:03:23
|
So, we need to make sure when we're doing this
|
|
0:03:28
|
on the correct circuits, and that it is between...
|
|
0:03:32
|
both of the neighbors across the link.
|
|
0:03:36
|
Now, the place where you could
|
|
0:03:39
|
is that when you apply the class,
|
|
0:03:42
|
there's two different options. We can
|
|
0:03:48
|
So, this one goes to the DLCI.
|
|
0:03:51
|
The frame relay class goes to the interface.
|
|
0:03:59
|
Now, why would they give us two options here?
|
|
0:04:09
|
If we apply the class to the interface,
|
|
0:04:15
|
It will be inherited by all circuits on that link.
|
|
0:04:19
|
So, if we have the main interface
|
|
0:04:24
|
and we use the Frame Relay Class command,
|
|
0:04:26
|
it means that the class would be
|
|
0:04:30
|
If I were only trying to run
|
|
0:04:35
|
then, that's gonna be a problem.
|
|
0:04:37
|
So, typically, the case within the lab
|
|
0:04:42
|
would be that if you have
|
|
0:04:45
|
where let's say router 1 is the hub...
|
|
0:04:49
|
of a frame relay network
|
|
0:04:56
|
Router 2 and to router 3.
|
|
0:05:01
|
On router 1, we have two different circuits,
|
|
0:05:06
|
and circuit 103 that goes to router 3.
|
|
0:05:12
|
In this case, I want to run end-to-end
|
|
0:05:18
|
but not between 1 and 3.
|
|
0:05:22
|
If I configure the class on both router 1 and 2,
|
|
0:05:26
|
and apply it to the interface on router 2,
|
|
0:05:29
|
and the interface of router 1,
|
|
0:05:32
|
it means it would also be applied this direction.
|
|
0:05:38
|
This is not necessarily bad as long
|
|
0:05:43
|
to use a compatible mode with
|
|
0:05:47
|
So, if router 1 is saying Request, it would
|
|
0:05:54
|
The other option would be to apply it
|
|
0:05:58
|
and then, we know that it goes just to that
|
|
0:06:05
|
So, let's look at an example of this here...
|
|
0:06:08
|
with the hub and spoke network
|
|
0:06:24
|
So first, between them, we'll go to the main
|
|
0:06:30
|
On router 3, this is serial 1/0.
|
|
0:06:33
|
We'll say, Encapsulation Frame Relay.
|
|
0:06:38
|
The IP address will be 123.0.0.3 on router 3,
|
|
0:06:45
|
and we have mappings to get to router 1...
|
|
0:06:51
|
via circuit 301.
|
|
0:06:54
|
And mappings to router 2 via the same circuit.
|
|
0:07:00
|
Okay, and actually, I would want to...
|
|
0:07:04
|
not use the broadcast keyword
|
|
0:07:06
|
So, I have multiple mappings that
|
|
0:07:10
|
The reason that I need to do that
|
|
0:07:14
|
the router doesn't know the binding between
|
|
0:07:21
|
Even if we were to run inverse ARP,
|
|
0:07:23
|
we would only be able to resolve router 1
|
|
0:07:29
|
But in this case, I wanna be able to
|
|
0:07:37
|
so, let's take this configuration and we'll
|
|
0:07:41
|
On router 2,
|
|
0:07:45
|
the only thing that's gonna be different is the interface,
|
|
0:07:54
|
So, from router 2, this is 201...
|
|
0:07:57
|
that goes to 1 and 3.
|
|
0:08:09
|
Then, on router 1,
|
|
0:08:14
|
we have the mapping to routers 2 and 3.
|
|
0:08:17
|
This would be via 102 and 103.
|
|
0:08:24
|
So, personally, I like to write a two
|
|
0:08:28
|
or any text editor, because then,
|
|
0:08:31
|
Sometimes, it's easier to catch your errors in syntax if
|
|
0:08:38
|
Especially when it's a configuration like this that's
|
|
0:08:44
|
So again, you will have access to do that
|
|
0:08:53
|
So next, let's look at the
|
|
0:08:58
|
And look at what's the status of the DLCIs.
|
|
0:09:02
|
Ideally, I want to see that both
|
|
0:09:09
|
So, those are the circuits that goes
|
|
0:09:14
|
Okay, which they are. Both of them
|
|
0:09:19
|
Next, if we look at the
|
|
0:09:23
|
I have the static mappings that
|
|
0:09:27
|
So now, I should be able to reach...
|
|
0:09:30
|
router 2...
|
|
0:09:32
|
and router 3, which I can.
|
|
0:09:35
|
From router 2,
|
|
0:09:37
|
we know that we can reach 1.
|
|
0:09:39
|
Because if 1 can reach 2, it implies that...
|
|
0:09:45
|
2 can reach 1.
|
|
0:09:48
|
Then, if we test connectivity between the spokes,
|
|
0:09:51
|
we can see both 2 and 3 can reach each other.
|
|
0:09:55
|
So now, we have full connectivity over
|
|
0:09:59
|
Next step is that we're gonna add
|
|
0:10:03
|
So, I wanna run this just between
|
|
0:10:07
|
So on router 1, this should
|
|
0:10:11
|
On router 2, this is gonna be on 201.
|
|
0:10:21
|
Next step is we create the
|
|
0:10:25
|
So, Map Class for Frame Relay.
|
|
0:10:29
|
We'll call this EEK. So, any name.
|
|
0:10:38
|
Next, I wanna set the frame
|
|
0:10:43
|
You can also see if you look at the frame relay options here,
|
|
0:10:48
|
Frame relay fragmentation,
|
|
0:10:51
|
the QoS stuff, like the adaptive shaping,
|
|
0:10:56
|
CIR and the minimum CIR.
|
|
0:10:58
|
We'll come back and talk about this stuff
|
|
0:11:02
|
But in this case, we're using it for
|
|
0:11:08
|
Now, I wanna know what is the mode.
|
|
0:11:10
|
This determines, am I sending the
|
|
0:11:15
|
Are we doing it both ways?
|
|
0:11:17
|
Or we're only replying once
|
|
0:11:21
|
So, in this case, I'll say that router 1
|
|
0:11:27
|
Then, on the other end, router 2
|
|
0:11:32
|
Next, at the interface level,
|
|
0:11:35
|
Frame Relay Class is EEK.
|
|
0:11:41
|
Then, we'll do the same thing on router 2,
|
|
0:11:48
|
EEK.
|
|
0:11:49
|
We want frame relay end-to-end...
|
|
0:11:54
|
keepalives.
|
|
0:11:55
|
And the mode will be to reply.
|
|
0:12:01
|
Then, at the link level, we have
|
|
0:12:06
|
Now, ideally, what we should see
|
|
0:12:11
|
that when we look at
|
|
0:12:16
|
PVC's.
|
|
0:12:18
|
and look at the individual DLCIs,
|
|
0:12:21
|
we have a new status...
|
|
0:12:24
|
that is for the end-to-end keepalives.
|
|
0:12:27
|
So, on whatever circuits that
|
|
0:12:32
|
which are...
|
|
0:12:33
|
all five of these.
|
|
0:12:36
|
We are now looking at the end-to-end
|
|
0:12:43
|
So, it tells us that LMI says
|
|
0:12:47
|
but end-to-end keepalive says that's
|
|
0:12:53
|
For the circuit that goes over to router 2,
|
|
0:12:56
|
the EEK status is up, because
|
|
0:13:02
|
for which we are requesting.
|
|
0:13:10
|
So again, this is the example of...
|
|
0:13:13
|
the error in applying the class. Since I'm
|
|
0:13:18
|
it's being inherited by both of the circuits,
|
|
0:13:20
|
but in reality, I only want to
|
|
0:13:25
|
So, instead what I should do...
|
|
0:13:28
|
is not apply this to the main interface,
|
|
0:13:31
|
but go to the individual circuit, so we'll
|
|
0:13:38
|
And apply the Class EEK.
|
|
0:13:43
|
So now, if we look at the running config,
|
|
0:13:47
|
now, the class goes only to that individual circuit.
|
|
0:13:50
|
If we look at the PVC status,
|
|
0:13:53
|
we see now, this is not affecting...
|
|
0:13:55
|
circuit 103.
|
|
0:14:01
|
If we test connectivity again,
|
|
0:14:03
|
we should be able to reach
|
|
0:14:09
|
Another common mistake with this
|
|
0:14:14
|
go to the Frame Relay Interface DLCI Mode,
|
|
0:14:19
|
so this is DLCI 102.
|
|
0:14:22
|
And then, instead of saying Class EEK,
|
|
0:14:29
|
which notice it does what?
|
|
0:14:35
|
When the parser returned the prompt,
|
|
0:14:38
|
it didn't return me to the same mode I was at before.
|
|
0:14:41
|
I was previously under the Frame Relay DLCI.
|
|
0:14:44
|
When I hit enter, it returned me
|
|
0:14:50
|
What does that mean when the router
|
|
0:14:55
|
than you are in before you entered a command?
|
|
0:15:02
|
Okay, it actually means that my command was
|
|
0:15:10
|
So, if we look at the result in running config,
|
|
0:15:14
|
we should see that the Frame Relay Class
|
|
0:15:20
|
It wasn't applied under the circuit.
|
|
0:15:22
|
Because the syntax under the circuit is the Class
|
|
0:15:28
|
So then again, we end up in that same error...
|
|
0:15:31
|
where now, router 3 circuit is declared down,
|
|
0:15:36
|
which means that we cannot send packets to them.
|
|
0:15:41
|
So, if the EEK status of the circuit is down,
|
|
0:15:44
|
the router will not use it for switching.
|
|
0:15:49
|
So, I would be able to reach router 2,
|
|
0:15:52
|
but not router 3.
|
|
0:16:06
|
So, if we look at our final configuration here on
|
|
0:16:17
|
The Map Class is router 1 is requesting.
|
|
0:16:20
|
Which means that...
|
|
0:16:21
|
router 2,
|
|
0:16:24
|
would either have to say the mode is
|
|
0:16:29
|
So, passive reply means that
|
|
0:16:33
|
before you would declare the circuit down.
|
|
0:16:36
|
There's also some other options you can
|
|
0:16:43
|
for receiving requests?
|
|
0:16:49
|
Okay, this would be, how many do you need
|
|
0:16:55
|
Then, the success events would be the opposite.
|
|
0:16:59
|
how many new successful...
|
|
0:17:02
|
events do you need to happen in a row
|
|
0:17:08
|
So, these type of options really don't matter.
|
|
0:17:11
|
If you needed to apply these in the exam,
|
|
0:17:13
|
you could just look up the command reference for...
|
|
0:17:16
|
the Frame Relay End-to-End Keepalive command,
|
|
0:17:18
|
and then, figure out what are
|
|
0:17:24
|
Now, documentation wise,
|
|
0:17:27
|
if we go to the main...
|
|
0:17:30
|
documentation page.
|
|
0:17:32
|
Under products...
|
|
0:17:34
|
to IOS.
|
|
0:17:36
|
Cisco IOS 12.4T,
|
|
0:17:41
|
then, to Configuration Guides.
|
|
0:17:44
|
Frame Relay is gonna be towards the bottom...
|
|
0:17:48
|
under WAN.
|
|
0:17:50
|
So, Wide Area Networking
|
|
0:17:54
|
Then, under this first part,
|
|
0:17:59
|
Most of the topics will be under this first
|
|
0:18:04
|
But you could see some
|
|
0:18:06
|
frame relay fragmentation,
|
|
0:18:08
|
IP RTP priority, PPP over frame relay,
|
|
0:18:14
|
But something like end-to-end keepalives, this would be
|
|
0:18:26
|
So, Configuring Frame Relay
|
|
0:18:28
|
Also, configuring PPP over frame
|
|
0:18:33
|
So, it doesn't hurt to spend a couple
|
|
0:18:38
|
and see what are some of the other features.
|
|
0:18:40
|
Like Frame Relay Fragmentation,
|
|
0:18:43
|
it's supports a Layer 2 fragmentation...
|
|
0:18:46
|
as opposed to like Ethernet.
|
|
0:18:48
|
Which if you wanted to do
|
|
0:18:52
|
you would have to do fragmentation at the
|
|
0:18:57
|
But frame relay itself supports
|
|
0:19:02
|
that you would sue for some sort of
|