SF(config)#
line vty 0 1180
SF(config-line)#
password telnet
SF(config-line)#
login
SF(config-line)#
banner motd #This is the SF Branch router#
SF(config)#
exit
SF#
copy run start
Destination filename [startup-config]?
Building configuration...
[OK]
Let’s take a look at our configuration of the interfaces with the following
two commands:
SF#
sh run | begin int
interface FastEthernet0/0
description SF LAN
ip address 192.168.10.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/0/0
description WAN Connection to Corp
ip address 172.16.10.2 255.255.255.252
clock rate 1000000
!
SF#
sh ip int brief
Interface IP-Address OK? Method Status
Protocol
FastEthernet0/0 192.168.10.1 YES manual up
up
FastEthernet0/1 unassigned YES unset administratively
down down
Serial0/0/0 172.16.10.2 YES manual up
up
Serial0/0/1 unassigned YES unset administratively
down down
SF#
Now that both ends of the serial link are configured, the link comes up.
Remember, the up/up status for the interfaces are Physical/Data Link
layer status indicators that don’t reflect the layer 3 status! I ask students
in my classes, “If the link shows up/up, can you ping the directly
connected network?” And they say, “Yes!” The correct answer is, “I don’t
know,” because we can’t see the layer 3 status with this command. We
only see layers 1 and 2 and verify that the IP addresses don’t have a typo.
This is really important to understand!
The
show ip route
command for the SF router reveals the following:
SF#
sh ip route
C 192.168.10.0/24 is directly connected, FastEthernet0/0
L 192.168.10.1/32 is directly connected, FastEthernet0/0
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.10.0 is directly connected, Serial0/0/0
L 172.16.10.2/32 is directly connected, Serial0/0/0
Notice that router SF knows how to get to networks 172.16.10.0/30 and
192.168.10.0/24; we can now ping to the Corp router from SF:
SF#
ping 172.16.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.1, timeout is 2
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4
ms
Now let’s head back to the Corp router and check out the routing table:
Corp>
sh ip route
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.10.0 is directly connected, Serial0/0
L 172.16.10.1/32 is directly connected, Serial0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, FastEthernet0/0
L 10.10.10.1/32 is directly connected, FastEthernet0/0
On the SF router’s serial interface 0/0/0 is a DCE connection, which
means a clock rate needs to be set on the interface. Remember that you
don’t need to use the
clock rate
command in production. While true, it’s
still imperative that you know how/when you can use it and that you
understand it really well when studying for your CCNA exam!
We can see our clocking with the
show controllers
command:
SF#
sh controllers s0/0/0
Interface Serial0/0/0
Hardware is GT96K
DCE V.35, clock rate 1000000
Corp>
sh controllers s0/0
Interface Serial0/0
Hardware is PowerQUICC MPC860
DTE V.35 TX and RX clocks detected.
Since the SF router has a DCE cable connection, I needed to add clock
rate to this interface because DTE receives clock. Keep in mind that the
new ISR routers will autodetect this and set the clock rate to 2000000.
And you still need to make sure you’re able to find an interface that is
DCE and set clocking to meet the objectives.
Since the serial links are showing up, we can now see both networks in
the Corp routing table. And once we configure LA, we’ll see one more
network in the routing table of the Corp router. The Corp router can’t see
the 192.168.10.0 network because we don’t have any routing configured
yet—routers see only directly connected networks by default.
LA Configuration
To configure LA, we’re going to do pretty much the same thing we did
with the other two routers. There are two interfaces to deal with, Serial
0/0/1 and FastEthernet 0/0, and again, we’ll be sure to add the
hostname, passwords, interface descriptions, and a banner to the router
configuration:
Router(config)#
hostname LA
LA(config)#
enable secret GlobalNet
LA(config)#
no ip domain-lookup
LA(config)#
int s0/0/1
LA(config-if)#
ip address 172.16.10.6 255.255.255.252
LA(config-if)#
no shut
LA(config-if)#
clock rate 1000000
LA(config-if)#
description WAN To Corporate
LA(config-if)#
int f0/0
LA(config-if)#
ip address 192.168.20.1 255.255.255.0
LA(config-if)#
no shut
LA(config-if)#
description LA LAN
LA(config-if)#
line con 0
LA(config-line)#
password console
LA(config-line)#
login
LA(config-line)#
logging sync
LA(config-line)#
exit
LA(config)#
line vty 0 ?
<1-1180> Last Line number
LA(config)#
line vty 0 1180
LA(config-line)#
password telnet
LA(config-line)#
login
LA(config-line)#
exit
LA(config)#
banner motd #This is my LA Router#
LA(config)#
exit
LA#
copy run start
Destination filename [startup-config]?
Building configuration...
[OK]
Nice—everything was pretty straightforward. The following output, which
I gained via the
show ip route
command, displays the directly connected
networks of 192.168.20.0 and 172.16.10.0:
LA#
sh ip route
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.10.4 is directly connected, Serial0/0/1
L 172.16.10.6/32 is directly connected, Serial0/0/1
C 192.168.20.0/24 is directly connected, FastEthernet0/0
L 192.168.20.1/32 is directly connected, FastEthernet0/0
So now that we’ve configured all three routers with IP addresses and
administrative functions, we can move on to deal with routing. But I want
to do one more thing on the SF and LA routers—since this is a very small
network, let’s build a DHCP server on the Corp router for each LAN.
Configuring DHCP on Our Corp Router
While it’s true that I could approach this task by going to each remote
router and creating a pool, why bother with all that when I can easily
create two pools on the Corp router and have the remote routers forward
requests to the Corp router? Of course, you remember how to do this
from Chapter 7!
Let’s give it a shot:
Corp#
config t
Corp(config)#
ip dhcp excluded-address 192.168.10.1
Corp(config)#
ip dhcp excluded-address 192.168.20.1
Corp(config)#
ip dhcp pool SF_LAN
Corp(dhcp-config)#
network 192.168.10.0 255.255.255.0
Corp(dhcp-config)#
default-router 192.168.10.1
Corp(dhcp-config)#
dns-server 4.4.4.4
Corp(dhcp-config)#
exit
Corp(config)#
ip dhcp pool LA_LAN
Corp(dhcp-config)#
network 192.168.20.0 255.255.255.0
Corp(dhcp-config)#
default-router 192.168.20.1
Corp(dhcp-config)#
dns-server 4.4.4.4
Corp(dhcp-config)#
exit
Corp(config)#
exit
Corp#
copy run start
Destination filename [startup-config]?
Building configuration...
Creating DHCP pools on a router is actually a simple process, and you
would go about the configuration the same way on any router you wish to
add a DHCP pool to. To designate a router as a DHCP server, you just
create the pool name, add the network/subnet and the default gateway,
and then exclude any addresses that you don’t want handed out. You
definitely want to make sure you’ve excluded the default gateway address,
and you’d usually add a DNS server as well. I always add any exclusions
first, and remember that you can conveniently exclude a range of
addresses on a single line. Soon, I’ll demonstrate those verification
commands I promised I’d show you back in Chapter 7, but first, we need
to figure out why the Corp router still can’t get to the remote networks by
default!
Now I’m pretty sure I configured DHCP correctly, but I just have this
nagging feeling I forgot something important. What could that be? Well,
the hosts are remote across a router, so what would I need to do that
would allow them to get an address from a DHCP server? If you
concluded that I’ve got to configure the SF and LA F0/0 interfaces to
forward the DHCP client requests to the server, you got it!
Here’s how we’d go about doing that:
LA#
config t
LA(config)#
int f0/0
LA(config-if)#
ip helper-address 172.16.10.5
SF#
config t
SF(config)#
int f0/0
SF(config-if)#
ip helper-address 172.16.10.1
I’m pretty sure I did this correctly, but we won’t know until I have some
type of routing configured and working. So let’s get to that next!
Configuring IP Routing in Our Network
So is our network really good to go? After all, I’ve configured it with IP
addressing, administrative functions, and even clocking that will
automatically occur with the ISR routers. But how will our routers send
packets to remote networks when they get their destination information
by looking into their tables that only include directions about directly
connected networks? And you know routers promptly discard packets
they receive with addresses for networks that aren’t listed in their routing
table!
So we’re not exactly ready to rock after all. But we will be soon because
there are several ways to configure the routing tables to include all the
networks in our little internetwork so that packets will be properly
forwarded. As usual, one size fits all rarely fits at all, and what’s best for
one network isn’t necessarily what’s best for another. That’s why
understanding the different types of routing will be really helpful when
choosing the best solution for your specific environment and business
requirements.
These are the three routing methods I’m going to cover with you:
Static routing
Default routing
Dynamic routing
We’re going to start with the first way and implement static routing on
our network, because if you can implement static routing and make it
work, you’ve demonstrated that you definitely have a solid understanding
of the internetwork. So let’s get started.
Static Routing
Static routing is the process that ensues when you manually add routes in
each router’s routing table. Predictably, there are pros and cons to static
routing, but that’s true for all routing approaches.
Here are the pros:
There is no overhead on the router CPU, which means you could
probably make do with a cheaper router than you would need for
dynamic routing.
There is no bandwidth usage between routers, saving you money on
WAN links as well as minimizing overhead on the router since you’re
not using a routing protocol.
It adds security because you, the administrator, can be very exclusive
and choose to allow routing access to certain networks only.
And here are the cons:
Whoever the administrator is must have a vault-tight knowledge of
the internetwork and how each router is connected in order to
configure routes correctly. If you don’t have a good, accurate map of
your internetwork, things will get very messy quickly!
If you add a network to the internetwork, you have to tediously add a
route to it on all routers by hand, which only gets increasingly insane
as the network grows.
Due to the last point, it’s just not feasible to use it in most large
networks because maintaining it would be a full-time job in itself.
But that list of cons doesn’t mean you get to skip learning all about it
mainly because of that first disadvantage I listed—the fact that you must
have such a solid understanding of a network to configure it properly and
that your administrative knowledge has to practically verge on the
supernatural! So let’s dive in and develop those skills. Starting at the
beginning, here’s the command syntax you use to add a static route to a
routing table from global config:
ip route [destination_network] [mask] [next-hop_address or
exitinterface] [
administrative_distance] [permanent]
This list describes each command in the string:
ip route
The command used to create the static route.
destination_network
The network you’re placing in the routing table.
mask
The subnet mask being used on the network.
next-hop_address
This is the IP address of the next-hop router that will
receive packets and forward them to the remote network, which must
signify a router interface that’s on a directly connected network. You
must be able to successfully ping the router interface before you can add
the route. Important note to self is that if you type in the wrong next-hop
address or the interface to the correct router is down, the static route will
show up in the router’s configuration but not in the routing table.
exitinterface
Used in place of the next-hop address if you want, and
shows up as a directly connected route.
administrative_distance
By default, static routes have an administrative
distance of 1 or 0 if you use an exit interface instead of a next-hop
address. You can change the default value by adding an administrative
weight at the end of the command. I’ll talk a lot more about this later in
the chapter when we get to the section on dynamic routing.
permanent
If the interface is shut down or the router can’t communicate to
the next-hop router, the route will automatically be discarded from the
routing table by default. Choosing the
permanent
option keeps the entry in
the routing table no matter what happens.
Before I guide you through configuring static routes, let’s take a look at a
sample static route to see what we can find out about it:
Router(config)#
ip route 172.16.3.0 255.255.255.0 192.168.2.4
The
ip route
command tells us simply that it’s a static route.
172.16.3.0 is the remote network we want to send packets to.
255.255.255.0 is the mask of the remote network.
192.168.2.4 is the next hop, or router, that packets will be sent to.
But what if the static route looked like this instead?
Router(config)#
ip route 172.16.3.0 255.255.255.0 192.168.2.4 150
That 150 at the end changes the default administrative distance (AD) of 1
to 150. As I said, I’ll talk much more about AD when we get into dynamic
routing, but for now, just remember that the AD is the trustworthiness of
a route, where 0 is best and 255 is worst.
One more example, then we’ll start configuring:
Router(config)#
ip route 172.16.3.0 255.255.255.0 s0/0/0
Instead of using a next-hop address, we can use an exit interface that will
make the route show up as a directly connected network. Functionally,
the next hop and exit interface work exactly the same.
To help you understand how static routes work, I’ll demonstrate the
configuration on the internetwork shown previously in
Figure 9.8
. Here it
is again in
Figure 9.9
to save you the trouble of having to go back and
forth to view the same figure.
FIGURE 9.9
Our internetwork
Corp
Each routing table automatically includes directly connected networks.
To be able to route to all indirectly connected networks within the
internetwork, the routing table must include information that describes
where these other networks are located and how to get to them.
The Corp router is connected to three networks. For the Corp router to be
able to route to all networks, the following networks have to be
configured into its routing table:
192.168.10.0
192.168.20.0
The following router output shows the static routes on the Corp router
and the routing table after the configuration. For the Corp router to find
the remote networks, I had to place an entry into the routing table
describing the remote network, the remote mask, and where to send the
packets. I am going to add a 150 at the end of each line to raise the
administrative distance. You’ll see why soon when we get to dynamic
routing. Many times this is also referred to as a floating static route
because the static route has a higher administrative distance than any
routing protocol and will only be used if the routes found with the routing
protocols go down. Here’s the output:
Corp#
config t
Corp(config)#
ip route 192.168.10.0 255.255.255.0 172.16.10.2 150
Corp(config)#
ip route 192.168.20.0 255.255.255.0 s0/1 150
Corp(config)#
do show run | begin ip route
ip route 192.168.10.0 255.255.255.0 172.16.10.2 150
ip route 192.168.20.0 255.255.255.0 Serial0/1 150
I needed to use different paths for networks 192.168.10.0 and
192.168.20.0, so I used a next-hop address for the SF router and an exit
interface for the LA router. After the router has been configured, you can
just type
show ip route
to see the static routes:
Corp(config)#
do show ip route
S 192.168.10.0/24 [150/0] via 172.16.10.2
172.16.0.0/30 is subnetted, 2 subnets
C 172.16.10.4 is directly connected, Serial0/1
L 172.16.10.5/32 is directly connected, Serial0/1
C 172.16.10.0 is directly connected, Serial0/0
L 172.16.10.1/32 is directly connected, Serial0/0
S 192.168.20.0/24 is directly connected, Serial0/1
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, FastEthernet0/0
L 10.10.10.1/32 is directly connected, FastEthernet0/0
The Corp router is configured to route and know all routes to all
networks. But can you see a difference in the routing table for the routes
to SF and LA? That’s right! The next-hop configuration showed up as via,
and the route configured with an exit interface configuration shows up as
static but also as directly connected! This demonstrates how they are
functionally the same but will display differently in the routing table.
Understand that if the routes don’t appear in the routing table, it’s
because the router can’t communicate with the next-hop address you’ve
configured. But you can still use the
permanent
parameter to keep the
route in the routing table even if the next-hop device can’t be contacted.
The
S
in the first routing table entry means that the route is a static entry.
The
[150/0]
stands for the administrative distance and metric to the
remote network, respectively.
Okay—we’re good. The Corp router now has all the information it needs
to communicate with the other remote networks. Still, keep in mind that
if the SF and LA routers aren’t configured with all the same information,
the packets will be discarded. We can fix this by configuring static routes.
Don’t stress about the 150 at the end of the static route
configuration at all, because I promise to get to it really soon in this
chapter, not a later one! You really don't need to worry about it at this
point.
Dostları ilə paylaş: