CCNA Security 27

An ASA has many inherited switching and routing capabilities similar to IOS switches and routers. The most widely employed switching feature in the ASA is its Dot1Q tagging capabilities. ASA can use sub-interfaces just as a router could, and the configuration is really similar.
Suppose that we want to partition our e0/1 interface into two sub-interfaces connected to two different companies through leased lines. The only trunking protocol supported by the ASA (all models) is the Dot1Q protocol. Sub-interfaces assume the state of the physical interface, so before we can use the sub-interface, we will need to enable the physical interface.

However, we would not want the physical interface to pass traffic. The way we do this is to completely omit the "nameif" command on the physical interface. We instead name the sub-interfaces only. Like any other interfaces, a sub-interface also has a security-level.

On the ASDM, the configuration of the sub-interfaces can be found at Configuration - Interfaces. Of course, for us, we'll do it on the CLI:
in e0/1
no shut
in e0/1.10
vlan 10
nameif COMPANYONE
sec 50
ip add 10.10.10.1
in e0/1.20
vlan 20
nameif COMPANYTWO
sec 50
ip add 20.20.20.1

The only difference between the ASA and the IOS, of course other than the "nameif" and "security-level" command, is that the "encap dot" command is changed to "vlan" since Dot1Q is the only protocol it supports.

Of course, at the other end, you should have a switch to help us dynamically the packets as it leaves to the other companies. I however will not go through configuration of the switch as you can review it here.

Like a router, the ASA will send unknown routes to the default-gateway. The default-gateway is where the ASA will send packets of unknown destination gateways. Static routes can also be set in the ASA. Static routes will be up until the interface is down.

ASA comes with a static route tracking feature so that we can cause another route to come online if a monitoring target goes down. A monitoring target is typically a pingable host.

To track a host, for example, 10.10.10.2, we'll create a monitoring process as follows:
sla monitor 1
type echo protocol ipIcmpEcho 10.10.10.2 interface COMPANYONE
numpackets 3
frequency 10

This will create a monitoring process that pings for 3 packets every 10 seconds. We would also need to configure a schedule to do the monitoring. We can type:
sla schedule 1 life forever start-time now

This creates a schedule that runs from now till forever for monitor process 1 defined above. We now create a track object to group the monitor and the schedule objects together:
track 1 rtr 1 reachability

Now we have the object which we can put to a static route. If the tracking fails, the route is removed. You would not need to wait for the interface to go down. Suppose that we have to entries for a server farm at the other end:
route COMPANYONE 15.15.15.0 255.255.255.0 10.10.10.2 1 track 1
route COMPANYONE 15.15.15.0 255.255.255.0 10.10.10.3 2

In this case, the route with the metric of 1 would be used first. If the 10.10.10.2 becomes unreachable, it would attempt to go through using 10.10.10.3.

Finally, we'll go through some routing protocols that the ASA supports. These includes all the standard OSPF, EIGRP and RIP. To enable a routing protocol, you enable them the same way as IOS routers from the global configuration screen:
router ospf 1
network 1.1.1.1 255.255.255.255 area 0
network 10.10.10.1 255.255.255.255 area 1
network 20.20.20.1 255.255.255.255 area 2

Note that the mask of the network is opposite from how we do it in an IOS router. We no longer make use of wildcard masks. There are a few other deviations in the commands, so make sure you use context-sensitive help (?) regularly.