|
0:00:13
|
So next, let's look at the redistribution from the RIP process into the OSPF process.
|
|
0:00:20
|
So, up to this point under RIP, I said Redistribute OSPF 1 Metric 1.
|
|
0:00:25
|
Now, I'm gonna go from RIP back into OSFP.
|
|
0:00:30
|
Now, since router 4 is in area zero,
|
|
0:00:34
|
this is not a stub area.
|
|
0:00:36
|
It should mean that when router 4 originates these routes,
|
|
0:00:40
|
these are going to be Type-5 LSAs,
|
|
0:00:44
|
which are either E1 or the E2 routes.
|
|
0:00:51
|
By default, the route type is gonna be external Type-2.
|
|
0:00:55
|
And the default seed metric is 20.
|
|
0:00:58
|
So, on router 4, if we simply go to the OSPF process,
|
|
0:01:03
|
and say Redistribute RIP.
|
|
0:01:09
|
The default metric will be 20,
|
|
0:01:11
|
and the default metric type will be 2.
|
|
0:01:15
|
But notice the log message that comes up here, it says, "Only classful networks will be redistributed."
|
|
0:01:21
|
So, when OSPF Version 2 as a backwards compatibility,
|
|
0:01:25
|
it has this key word for subnets, which is not enabled by default.
|
|
0:01:32
|
So, if we simply say Redistribute RIP, it means that only classful summaries.
|
|
0:01:38
|
So, class A networks that are /8, class B networks that are /16,
|
|
0:01:42
|
class C networks that are /24
|
|
0:01:45
|
would be included in the OSPF database.
|
|
0:01:49
|
Now generally, we're gonna have more subnets or aggregates
|
|
0:01:54
|
that are not classful summaries.
|
|
0:01:56
|
So, 99% of the time, we would wanna say here, Redistribute RIP.
|
|
0:02:00
|
Then, the subnets.
|
|
0:02:06
|
The end result of this is that router 4
|
|
0:02:09
|
should be originating anything that shows up in the routing table as RIP
|
|
0:02:14
|
plus the connected interfaces that are running RIP into the OSPF database.
|
|
0:02:21
|
So, if we look at the Show IP OSPF Database,
|
|
0:02:26
|
and look at the Type-5 AS external link states.
|
|
0:02:30
|
It says the advertising router is router 4 for these individual routes.
|
|
0:02:39
|
So, the link ID field, this is the address.
|
|
0:02:42
|
The advertising router is the router ID of router 4.
|
|
0:02:46
|
Then, if we were to look at the details inside of the database,
|
|
0:02:50
|
it's gonna tell us what is the subnet mask, what is the metric, and what is the metric type.
|
|
0:02:57
|
So, on router 4, if we look at the Show IP OSPF...
|
|
0:03:05
|
Show IP OSPF Database for the external LSA with the link ID 30.0.0.0.
|
|
0:03:14
|
It says that "This particular prefix
|
|
0:03:17
|
was originated by myself. I am the advertising router."
|
|
0:03:22
|
The link state ID, that's the address. The network mask is the subnet mask.
|
|
0:03:27
|
So, it essentially means that this prefix is 30.0.0.0/16.
|
|
0:03:33
|
The metric type is 2 by default, this means that this is an E2 route.
|
|
0:03:39
|
The default seed metric is 20.
|
|
0:03:42
|
So, this should now mean that all routers in the OSPF network
|
|
0:03:47
|
are gonna see the prefix 30.0.0.0/16.
|
|
0:03:51
|
Install this in OSPF E2 route with a metric of 20.
|
|
0:03:56
|
So, if we were to go anywhere else in the topology,
|
|
0:04:00
|
let's say we look at router 6.
|
|
0:04:04
|
And on router 6,
|
|
0:04:12
|
on router 6, we look at the Show IP Route OSPF.
|
|
0:04:17
|
We see that the 8 routes that router 4 was learning as RIP
|
|
0:04:22
|
plus the connected interface, which is the 204.12.28.0/24.
|
|
0:04:28
|
These are now being learned as OSPF E2 routes.
|
|
0:04:32
|
They all have a metric of 20, and all have an administrative distance of 110.
|
|
0:04:39
|
Now, if we look at the specifics of any of these routes, if we Show IP Route...
|
|
0:04:43
|
then, the exact match, let's say 204.12.28.0.
|
|
0:04:50
|
Router 6 says that the metric is 20.
|
|
0:04:54
|
The type of route is an external 2.
|
|
0:04:58
|
And the forward metric is 1 to get to this particular ASBR.
|
|
0:05:07
|
So, as I mentioned previously, the difference in the calculation between the E1 and N1 routes
|
|
0:05:14
|
versus the E2 and N2 routes
|
|
0:05:17
|
is that the external Type-2s separate the metric fields to the seed metric.
|
|
0:05:23
|
Plus the metric to the ASBR.
|
|
0:05:27
|
So essentially, it means here on router 6
|
|
0:05:29
|
that in order to get to router 4, my cost is 1.
|
|
0:05:33
|
Because this is going over a directly connected Fast Ethernet interface.
|
|
0:05:38
|
If we were to go multiple hops away,
|
|
0:05:41
|
if we were to look at this from switch 1, from router 3, or from switch 3's perspective,
|
|
0:05:47
|
we should see that they're learning the same route
|
|
0:05:49
|
with the same metric value.
|
|
0:05:53
|
So, everyone should install this in the routing table with the metric of 20.
|
|
0:05:57
|
But the forward metric is going to increment
|
|
0:05:59
|
depending on how far away they are from the ASBR.
|
|
0:06:05
|
Now, the only time again that this is gonna matter
|
|
0:06:08
|
is that if there are multiple exit points between the two protocols.
|
|
0:06:14
|
If there is a tie in the metric of the E2 routes,
|
|
0:06:17
|
then, we're gonna look at the forward metric as a tie breaker.
|
|
0:06:23
|
So, in this particular topology,
|
|
0:06:26
|
if router 4 were to redistribute the route from RIP into OSPF,
|
|
0:06:33
|
redistribute it from RIP into EIGRP,
|
|
0:06:37
|
then, router 3 redistributed it back from EIGRP into OSPF,
|
|
0:06:42
|
now, we have multiple paths in order to reach those external routes.
|
|
0:06:47
|
There is gonna be a set of E2 routes that are originated by router 3,
|
|
0:06:51
|
and the set of E2 routes that are originated by router 4.
|
|
0:06:55
|
Now, which one the OSPF routers are gonna choose
|
|
0:06:59
|
would then be based on their distance away from the ASBR.
|
|
0:07:04
|
Now, assuming that all of these interfaces have the same cost since they're all Fast Ethernet,
|
|
0:07:11
|
the VLAN 146 interface is gonna be a cost of 1, the VLAN 67 is a cost of 1.
|
|
0:07:16
|
The link between switch 1 and router 3 is gonna be a cost of 1.
|
|
0:07:20
|
Essentially, it's gonna be a hop count.
|
|
0:07:24
|
This should then mean that router 6
|
|
0:07:26
|
would choose the route through router 4,
|
|
0:07:29
|
but switch 1 would choose the route from router 3.
|
|
0:07:34
|
Because although the seed metric is the same for both of them, it's gonna default to 20,
|
|
0:07:39
|
router 6 would say, "The forward metric to go to router 4 is 1
|
|
0:07:43
|
versus the forward metric of 2 to get towards router 3."
|
|
0:07:49
|
Then likewise, switch 1 is gonna say the opposite. It would say, "My forward metric to reach router 3 is 1.
|
|
0:07:53
|
My forward metric to reach router 4 is 2.
|
|
0:07:56
|
Since there's a tie in the two metric values, then, I'm gonna use the forward metric as the tie breaker."
|
|
0:08:04
|
Now, if we were to set these external types as to external Type-1 routes,
|
|
0:08:09
|
then, there's no differentiation between the metric and the forward metric.
|
|
0:08:13
|
Switch 1 would simply install that in the routing table
|
|
0:08:16
|
as the 20 plus whatever the cost is to the ASBR.
|
|
0:08:20
|
So, switch 1 would say that the cost is 21.
|
|
0:08:24
|
Then, as we go to switch 3, since this link is a cost of 1 to get to switch 1,
|
|
0:08:28
|
it would say, its metric is 22.
|
|
0:08:35
|
So again, the only time that this really matters
|
|
0:08:38
|
what the metric value is and what the metric type is
|
|
0:08:41
|
is when there are multiple exit points out of that particular protocol domain.
|
|
0:08:49
|
Now, we could also use this for the purpose of traffic engineering
|
|
0:08:53
|
based on the route type in the OSPF path selection state machine.
|
|
0:09:01
|
So, as we talked about before, when OSPF does a path selection,
|
|
0:09:05
|
it's always gonna choose an intra-area route over an inter-area route
|
|
0:09:11
|
over E1 over E2 over N1 over N2.
|
|
0:09:18
|
So, this is regardless of the administrative distance or of the metric.
|
|
0:09:25
|
This would then mean, if I wanted to prefer router 3 for certain destinations versus router 4,
|
|
0:09:33
|
on router 3, when I do redistribution of EIGRP and OSPF,
|
|
0:09:37
|
I could say, "Set the metric type to E1."
|
|
0:09:41
|
On router 4, when I redistribute from EIGRP to OSPF,
|
|
0:09:45
|
I could leave this as the default metric of E2.
|
|
0:09:48
|
Metric type of E2.
|
|
0:09:52
|
So in this case, regardless of what the cost is to the ASBR,
|
|
0:09:55
|
or regardless of what's the cost that's advertised as the seed metric,
|
|
0:10:01
|
router 3 would always be used as the exit point to get to the EIGRP network,
|
|
0:10:07
|
because the E1 routes, they always had to be preferred first over E2.
|
|
0:10:15
|
But again, if the only device you're doing redistribution is router 4,
|
|
0:10:18
|
then, it really doesn't matter what the metric type is or what the metric is,
|
|
0:10:23
|
because if the only physical path to get to the RIP domain in this way,
|
|
0:10:28
|
then, regardless of what values are installed in the routing table,
|
|
0:10:31
|
that's the physical path that the traffic is gonna follow.
|
|
0:10:36
|
Now, once our redistribution is complete here,
|
|
0:10:39
|
the next step that we would want to go through in our verification
|
|
0:10:42
|
would be to test, can I actually reach the destinations that are learned from the other protocol?
|
|
0:10:50
|
So, at this point, we're redistributing just between RIP and EIGRP on router 4.
|
|
0:10:56
|
This means that ideally, I should be able to go to switch 3,
|
|
0:10:59
|
and send ICMP pings to any of those destinations learned from BB3,
|
|
0:11:04
|
and I should get a response back in.
|
|
0:11:08
|
So of course, this would assume that we're not doing any type of application filtering
|
|
0:11:12
|
like pings or denying somewhere in the transit path.
|
|
0:11:16
|
But with no other features configured, just the normal routing and the normal redistribution,
|
|
0:11:21
|
switch 3 should be able to reach any of those prefixes learned from RIP.
|
|
0:11:26
|
So, if we look at the command line on switch 3 and look at the Show IP Route.
|
|
0:11:31
|
And I'm gonna look at just the E2 routes.
|
|
0:11:35
|
So, Show IP Route Include E2.
|
|
0:11:38
|
These are the ones that were redistributed from RIP into OSPF.
|
|
0:11:42
|
If I were to ping 30.0.0.1,
|
|
0:11:47
|
we see, I get a response back.
|
|
0:11:49
|
If I ping 204.12.28.4..
|
|
0:11:55
|
which is router 4's address,
|
|
0:11:57
|
I got a response back in.
|
|
0:11:58
|
.254, that's BB3.
|
|
0:12:03
|
So, this is now verifying for me.
|
|
0:12:06
|
Not only did router 4 performed the redistribution both ways correctly.
|
|
0:12:11
|
The devices in the RIP domain are learning about the OSPF routes,
|
|
0:12:15
|
and the devices in the OSPF domain are learning the RIP routes.
|
|
0:12:21
|
So, for the vast majority over the redistribution checks,
|
|
0:12:24
|
this is gonna be our final verification.
|
|
0:12:26
|
If we can reach the destinations, we can assume that the redistribution was correct.
|
|
0:12:33
|
Now, we'll see that the problem we're gonna run into though
|
|
0:12:36
|
is that if the routing table is very large,
|
|
0:12:39
|
it can be very time consuming to check for each individual destination,
|
|
0:12:44
|
do I have reachability to that
|
|
0:12:46
|
when I'm sourcing the packets from different interfaces?
|
|
0:12:51
|
Because on switch 3, when we look at the Show IP Route 204.12.28.254,
|
|
0:13:00
|
switch 3 says that "My outgoing interface
|
|
0:13:03
|
in order to reach this particular destination is VLAN 79."
|
|
0:13:08
|
So, this then means whatever IP address I have assigned to VLAN 79,
|
|
0:13:14
|
this would be the source address
|
|
0:13:17
|
that I use for any packets that I am locally generating to the particular destination.
|
|
0:13:23
|
So, when I ping 204.12.28.254,
|
|
0:13:28
|
it means those packets are coming from 155.28.79.9.
|
|
0:13:35
|
However, this does not necessarily imply
|
|
0:13:39
|
that this destination has a route back to the other interfaces on switch 3.
|
|
0:13:46
|
So, if we look at the Show IP Route Connected,
|
|
0:13:50
|
just because I have reachability to them when I'm sourcing traffic from VLAN 79,
|
|
0:13:55
|
it doesn't mean that's gonna be the case when it's coming from the loopback or from VLAN 9.
|
|
0:14:01
|
Now likewise, it doesn't necessarily mean they won't have reachability.
|
|
0:14:05
|
Just means that there's separate check that we would have to go through.
|
|
0:14:08
|
So, if I wanna see...
|
|
0:14:10
|
do they have reachability to my VLAN 79 network?
|
|
0:14:15
|
That's what this first thing is gonna test.
|
|
0:14:17
|
If I wanna know, do I have reachability to them
|
|
0:14:20
|
and do they have reachability to my VLAN 9,
|
|
0:14:23
|
I would need to change what is the source of the packets.
|
|
0:14:26
|
So, if I ping from VLAN 9, it means they have a route back to that.
|
|
0:14:30
|
If I ping from the loopback 0,
|
|
0:14:32
|
likewise, it means they have a route back to that as well.
|
|
0:14:38
|
Now, specifically in this case, the reason why I do have reachability
|
|
0:14:42
|
is on switch 3, if I look at the Show IP OSPF Interface Brief,
|
|
0:14:46
|
all three of those interfaces are already in OSPF process.
|
|
0:14:52
|
But if for some reason, the loopback was not advertised, the VLAN 9 was not advertised,
|
|
0:14:57
|
then, devices in the RIP domain are not gonna have reachability back to those segments.
|
|
0:15:04
|
So, the key point here
|
|
0:15:06
|
is that unless we actually test that it works,
|
|
0:15:08
|
there's really no way to predict what the reachability is gonna be.
|
|
0:15:13
|
So, we could look at the routing databases on each individual device and make a list of them,
|
|
0:15:18
|
but usually, that's gonna be too time-consuming.
|
|
0:15:21
|
So, one thing that we can do for verifying
|
|
0:15:25
|
this type of reachability
|
|
0:15:27
|
is to use...
|
|
0:15:31
|
the TCL scripting along with ICMP.
|
|
0:15:36
|
So, we'll see in our next couple examples when we do run into problems
|
|
0:15:40
|
with route feedback and traffic loops,
|
|
0:15:43
|
using a TCL script to run through different ping commands
|
|
0:15:47
|
is a quick method that we can use on all of the devices
|
|
0:15:51
|
to figure out what destinations do they have reachability to,
|
|
0:15:54
|
and what destinations do they not have reachability to.
|
|
0:16:00
|
Now, TCL stand s for the Tool Command Language,
|
|
0:16:04
|
which is an open source scripting language.
|
|
0:16:06
|
It's not specific to Cisco IOS.
|
|
0:16:09
|
Now, specifically, IOS supports version 8.3.4,
|
|
0:16:13
|
which I believe there's some newer releases beyond that,
|
|
0:16:17
|
but pretty much, any functionality that we would need for scripting is gonna be supported
|
|
0:16:21
|
in that particular version.
|
|
0:16:25
|
Now, since TCL is actually a full programming language,
|
|
0:16:29
|
99% of it is gonna be outside of our scope.
|
|
0:16:32
|
So, we're not gonna talk about writing a lot of complex scripts today with TCL.
|
|
0:16:37
|
What we're gonna be using it for is just some basic reachability testing
|
|
0:16:41
|
for automating these different ping commands
|
|
0:16:44
|
to the destinations that we have installed in the routing table.
|
|
0:16:48
|
Now, the only issue with this
|
|
0:16:50
|
is that you have to know what the syntax is exactly,
|
|
0:16:55
|
because there's not a reference for the syntax on the context sensitive help,
|
|
0:16:59
|
or in the Cisco documentation.
|
|
0:17:04
|
So, here's an example of a basic script,
|
|
0:17:07
|
where first, router 1 is starting the TCL shell.
|
|
0:17:10
|
It says, we're gonna create a four loop, and define a variable X.
|
|
0:17:15
|
So for each value the X has,
|
|
0:17:18
|
we're gonna run the ping command for the particular variable's value.
|
|
0:17:25
|
So, the end result of this would be that router 1 is gonna ping 1.2.3.4.
|
|
0:17:31
|
Then, it would ping 5.6.7.8.
|
|
0:17:33
|
Then, it would ping 9.10.11.12.
|
|
0:17:38
|
Now, the reason that we would even wanna do this in the first place
|
|
0:17:41
|
is that if we were to do ping commands,
|
|
0:17:45
|
let's say on switch 3, where we were just looking at,
|
|
0:17:49
|
I wanna ping 30.0.0.1.
|
|
0:17:52
|
And I wanna ping 30...
|
|
0:17:56
|
Is it 30.1 or 31...
|
|
0:18:01
|
30.1. So, I wanna ping 30.1.0.1.
|
|
0:18:04
|
And 30.2.0.1, etc. So, there's bunch of different destinations that I wanna ping.
|
|
0:18:12
|
The problems is if I take these commands and simply paste them into the console,
|
|
0:18:17
|
you'll see that you're gonna overrun the console's buffer.
|
|
0:18:23
|
So, when I paste this from the clipboard,
|
|
0:18:26
|
the first command was Run Ping 30.0.0.1,
|
|
0:18:29
|
but while the IOS was trying to return this command to the exact prompt,
|
|
0:18:36
|
two of the other commands were lost in the console's buffer.
|
|
0:18:40
|
Now, when we do this with TCL,
|
|
0:18:43
|
the difference is that the router waits for the command ping 1.2.3.4 to return completely
|
|
0:18:49
|
before it issues the next one, which would be ping 5.6.7.8.
|
|
0:18:57
|
So, the vast majority of platforms,
|
|
0:19:00
|
as long as their IOS version in relatively recent, they should support the TCL.
|
|
0:19:05
|
And this is gonna include most of the newer Catalyst IOS versions as well.
|
|
0:19:12
|
So, if we were to look at some device in the topology let's say...
|
|
0:19:15
|
on router 6 or switch 1,
|
|
0:19:19
|
and I wanna test, do I have reachability to all of those routes that are being learned from RIP.
|
|
0:19:25
|
So, on router 6,
|
|
0:19:27
|
the first thing I need to know is what are all the addresses that I wanna reach?
|
|
0:19:31
|
So, if I Show IP Route and Include the E2 routes,
|
|
0:19:37
|
I wanna test reachability to these 9 different destinations.
|
|
0:19:42
|
So, first off, I need to make a list of these.
|
|
0:19:44
|
So, I'll just take these into Notepad...
|
|
0:19:49
|
And paste them.
|
|
0:19:53
|
Okay, the end address that I'm trying to test here is the .1s.
|
|
0:19:57
|
And then, for that connected segment between router 4 and BB3,
|
|
0:20:01
|
The address there is .254.
|
|
0:20:06
|
Now, I could remove the leading space here,
|
|
0:20:10
|
but for most of the syntax, it's not gonna matter if there's actually spaces there.
|
|
0:20:14
|
Okay, so now, I have the list of addresses that I wanna test.
|
|
0:20:19
|
Now, on router 6, I'm gonna start the TCL shell.
|
|
0:20:24
|
I'll say, for each variable that I'm defining,
|
|
0:20:28
|
open braces,
|
|
0:20:31
|
the list of addresses,
|
|
0:20:34
|
close braces and open braces on the same line,
|
|
0:20:38
|
whatever the exact command I want, in this case's ping,
|
|
0:20:42
|
dollar sign, and then the variable name
|
|
0:20:45
|
followed by close brace.
|
|
0:20:52
|
So, we can see, the result of this is that router 6
|
|
0:20:55
|
pings all nine of these destinations,
|
|
0:20:57
|
but it waits for the first command to return before it runs the additional ones.
|
|
0:21:04
|
So now, essentially, we could use the same type of script
|
|
0:21:08
|
that we wrote on router 6,
|
|
0:21:10
|
and then use it on all of the other routers that support TCL.
|
|
0:21:17
|
So basically, our full script here would be for each
|
|
0:21:20
|
whatever variable is,
|
|
0:21:22
|
the list of addresses,
|
|
0:21:24
|
close brace, open brace,
|
|
0:21:26
|
ping, dollar sign, access, the variable name,
|
|
0:21:30
|
and then close braces.
|
|
0:21:35
|
So, if I were to try this from switch 1 as well, let's say TCL Shell.
|
|
0:21:40
|
Paste that script in, and then it runs through all the pings.
|
|
0:21:47
|
So, based on this result,
|
|
0:21:49
|
I can now assume that all of the routes that came from RIP
|
|
0:21:52
|
were properly advertised into OSPF,
|
|
0:21:55
|
and the routes from OSPF were properly advertised back to the RIP domain.
|
|
0:22:02
|
Now again, this is not going to include
|
|
0:22:05
|
testing the reachability from every source interface.
|
|
0:22:10
|
So for example, on router 6, if I'm not advertising my loopback,
|
|
0:22:14
|
when I do these pings, since router 6's route to get to this destination is via
|
|
0:22:19
|
Fast Ethernet 0/0.146,
|
|
0:22:23
|
my pings are really only checking BB3 and whatever routers are behind it.
|
|
0:22:29
|
It's checking their reachability back to that particular segment.
|
|
0:22:34
|
So, if I had another interface, VLAN 6,
|
|
0:22:39
|
that doesn't necessarily test that connectivity.
|
|
0:22:42
|
So, we need to modify what the script says
|
|
0:22:45
|
and change the...
|
|
0:22:48
|
change the source.
|
|
0:22:50
|
So, I'll say, Ping X. And the source is from my loopback 0.
|
|
0:23:06
|
So, we can see now, router 6 is testing reachability to these.
|
|
0:23:10
|
It says, "I'm pinging that particular destination,
|
|
0:23:13
|
but now, I'm changing what the source address was. It's now my loopback."
|
|
0:23:17
|
So, based on this fact, now that the pings are getting on their back,
|
|
0:23:21
|
then, I can assume that reachability back to that interface works as well.
|
|
0:23:29
|
Now, you can get really complicated with the syntax of the scripting.
|
|
0:23:32
|
Because as I mentioned, it's a full programming language basically.
|
|
0:23:37
|
The other only thing you may wanna know here is that
|
|
0:23:40
|
if you want to run multiple commands,
|
|
0:23:43
|
you can terminate the line with a semi-colon,
|
|
0:23:46
|
and then run whatever other additional commands you want.
|
|
0:23:49
|
So, we could say...
|
|
0:23:51
|
that I wanna ping from the loopback, but then also ping from...
|
|
0:23:57
|
let's say Fa0/0.146,
|
|
0:24:02
|
Fa0/0.67,
|
|
0:24:07
|
and then, let's see on router 6 what other interfaces it have.
|
|
0:24:10
|
Let's say Show IP Route Connected
|
|
0:24:15
|
Serial 0/0/0.
|
|
0:24:24
|
So now, router 6 should do this from all four of those different interfaces.
|
|
0:24:35
|
Where we could see basically, BB3 have reachability back to all of those.
|
|
0:24:40
|
Now, if there was some address there that we didn't have reachability to,
|
|
0:24:44
|
we would see this in the scripting in the output just because the command line is gonna stop.
|
|
0:24:49
|
So, if I put this address 1.2.3.4,
|
|
0:24:52
|
this is not an actual valid address in this topology.
|
|
0:24:56
|
So, we could see, simply based on the fact that the packets are being lost,
|
|
0:24:59
|
I now know that there's a reachability problem to this destination.
|
|
0:25:08
|
When you run into this case that the router is dropping packets because it doesn't have a route,
|
|
0:25:12
|
or there's some sort of problem,
|
|
0:25:14
|
now, we need to cancel the script, otherwise, it's gonna keep running,
|
|
0:25:17
|
and it may take it 10 minutes before it times everything out.
|
|
0:25:22
|
So, the way you can do this if you're connected to the router through it's directly connected console,
|
|
0:25:27
|
just use the normal escape sequence, which is .
|
|
0:25:32
|
If you're connected to the access server,
|
|
0:25:35
|
then, the access server is connected to the router's console,
|
|
0:25:38
|
you need to send the escape sequence through the access server down to that individual TTY line.
|
|
0:25:45
|
And the difference is that instead of doing ,
|
|
0:25:51
|
you do .
|
|
0:25:58
|
So, would send a break to the access server itself.
|
|
0:26:02
|
is gonna send it through the access server's line
|
|
0:26:07
|
down to the router that's actually connected.
|
|
0:26:11
|
So, in this case, since I have multiple windows opened, these are connected directly to the consoles,
|
|
0:26:16
|
then, I could just say .
|
|
0:26:19
|
But if I went to the access server and then did a reverse telnet to router 6,
|
|
0:26:22
|
then, I would have to say to send the break down to that particular line.
|
|
0:26:30
|
Now, there's a lot of resources for TCL
|
|
0:26:33
|
that are gonna be outside of our scope here.
|
|
0:26:36
|
If you go to the main TCL website, which is tcl.tk,
|
|
0:26:42
|
you can see all sorts of documentation there.
|
|
0:26:44
|
There's also a specific book that is for IOS scripting on TCL,
|
|
0:26:51
|
so, it's just called "TCL Scripting for Cisco IOS".
|
|
0:26:54
|
You could see this one available on Safari.
|
|
0:26:57
|
If you wanna read through some portions of it,
|
|
0:26:59
|
or you could buy a printed copy from Cisco Press or Amazon wherever.
|
|
0:27:05
|
Also, if you go Cisco's website and just search for TCL,
|
|
0:27:10
|
there's this document here that explains the basic functionality for the process.
|
|
0:27:17
|
But when you look at the...
|
|
0:27:20
|
when you look at their examples,
|
|
0:27:22
|
the problem is it's not a lot of real good syntax that it shows you.
|
|
0:27:28
|
So here, it says...
|
|
0:27:32
|
TCL Script using the Show Interfaces command example.
|
|
0:27:41
|
It says, "Using the TCL regular expression engine scripts can filter specific
|
|
0:27:45
|
information from show commands...
|
|
0:27:48
|
in a custom format.
|
|
0:27:50
|
The following is an example of filtering show interfaces and creating a comma-separated list
|
|
0:27:54
|
of BRI interfaces on the router.
|
|
0:27:58
|
So, you can see, you pretty much have to know the exact syntax of the TCL to do this.
|
|
0:28:05
|
So, there's a lot of flexibility that you can do with the IOS.
|
|
0:28:08
|
The problem is you need to know the programming language to begin with.
|
|
0:28:13
|
And the issue within the scope of the CCIE lab exam
|
|
0:28:16
|
is that TCL is not really an IOS feature.
|
|
0:28:20
|
It's a separate open source scripting language.
|
|
0:28:24
|
So, this means that the documentation, it's not gonna be on Cisco's website.
|
|
0:28:27
|
It's gonna be on the TCL website.
|
|
0:28:30
|
So, if you are gonna use this technique
|
|
0:28:33
|
for testing reachability in the CCIE lab exam,
|
|
0:28:36
|
then, you're gonna have to know the syntax exactly.
|
|
0:28:42
|
Now, the other potential issue
|
|
0:28:44
|
is that once you invoke the TCL shell,
|
|
0:28:48
|
the TCL command parser runs on top of the normal IOS parser.
|
|
0:28:56
|
Now, what this means is that any commands you send to the router,
|
|
0:28:59
|
they're first gonna be processed by TCL,
|
|
0:29:02
|
and if there's not a match for TCL syntax, then, it's gonna be passed to the normal IOS process.
|
|
0:29:08
|
And the issue that you could have here
|
|
0:29:11
|
is that if there's an overlap between a TCL command and a regular IOS command,
|
|
0:29:18
|
then, the IOS command is not gonna be accepted.
|
|
0:29:22
|
And a good example of this would be the set command in a route map.
|
|
0:29:26
|
So, let's say here on router 6
|
|
0:29:29
|
that we're trying to do some configuration in BGP,
|
|
0:29:33
|
where I'm trying to change the local preference of routes coming from a particular neighbor.
|
|
0:29:39
|
So, from a BGP implementation point of view,
|
|
0:29:42
|
what I would need to do is create a route map.
|
|
0:29:45
|
Let's say Route Map from BGP Peer Permit 10.
|
|
0:29:52
|
Okay, in the route map, I wanna change a BGP attribute. I'm gonna set the local-preference.
|
|
0:29:57
|
So, I'll say Set Local-Preference.
|
|
0:30:00
|
And then, whatever value. 12345.
|
|
0:30:06
|
Now, notice here, there's an odd output from the command line,
|
|
0:30:10
|
where it returned the value 12345
|
|
0:30:15
|
instead of going just back to the next prompt.
|
|
0:30:21
|
Okay, if I also said something like Set Origin Incomplete,
|
|
0:30:26
|
it's gonna do the same thing.
|
|
0:30:28
|
What this actually means is that with the set command,
|
|
0:30:32
|
I'm not actually issuing route map commands.
|
|
0:30:37
|
I'm creating an environment variable named "local-preference".
|
|
0:30:41
|
And a variable named "origin".
|
|
0:30:45
|
So, if I say now, "echo origin",
|
|
0:30:49
|
or I'm gonna have to say "echo dollar sign origin".
|
|
0:30:54
|
Let's say, "echo origin". Let's try puts.
|
|
0:30:58
|
So, in different versions, it'll be a little bit different in the syntax here.
|
|
0:31:05
|
So, it says, "The value of the variable origin...
|
|
0:31:09
|
is the string incomplete."
|
|
0:31:12
|
The problem now, if we look at the result of this in the running config, if we Show Run Begin Route Map,
|
|
0:31:19
|
route map from BGP peer,
|
|
0:31:22
|
it didn't actually take any of those values that I input.
|
|
0:31:27
|
So, while I wanted it to set the origin to be incomplete,
|
|
0:31:30
|
I wanted it to set the local-preference to be 12345,
|
|
0:31:33
|
it's not actually doing that.
|
|
0:31:34
|
It's creating variables named "local-preference",
|
|
0:31:37
|
and a variable named "origin".
|
|
0:31:42
|
So, the way that you can get around this
|
|
0:31:45
|
is just that when you're done with the TCL shell. When you're done with your ping script,
|
|
0:31:49
|
just say TCL Quit.
|
|
0:31:51
|
And that's gonna exit the process.
|
|
0:31:54
|
Now, we can see that the TCL shell hadn't exited,
|
|
0:31:58
|
because when I invoked it, and it later went to global config,
|
|
0:32:03
|
went to the interface level.
|
|
0:32:06
|
From here, it doesn't look like there's any problem.
|
|
0:32:08
|
But if I type end or do ,
|
|
0:32:12
|
it goes back to the TCL parser.
|
|
0:32:17
|
So, just be aware that the TCL parser comes first before the IOS parser.
|
|
0:32:22
|
So, for any overlapping commands,
|
|
0:32:24
|
it's gonna go to TCL instead of the regular IOS syntax.
|
|
0:32:28
|
So, to avoid that, just when you're done with your TCL scripting,
|
|
0:32:31
|
either type "TCL Quit", or "Exit" to leave the exact process,
|
|
0:32:36
|
which is then gonna terminate the TCL shell.
|
