Configuring AAA on Cisco ASA for TACACS Users

Before reading this you may need to know how to configure Cisco ACS server. If so click here and comeback.. There I am adding a Cisco router as a AAA client but for an ASA it is same too.

Steps:-

1. Define the TACACS server group name and protocol
Server group name (tag) here is TACACS and the protocol is tacacs+

ciscoasa(config)# aaa-server TACACS protocol tacacs+ 

2. Define the reachable interface, server IP address and key
In my setup TACACS server is reachable from OUTSIDE interface.
Key must be the key given as the shared secret of authentication options in Cisco ACS server.

ciscoasa(config)# aaa-server TACACS (OUTSIDE) host 10.1.1.200
ciscoasa(config-aaa-server-host)# key C1sc0#adm

3. Define the authentication methods for SSH & HTTP (for ASDM access)
Server group TACACS will be used for authentication 1st, if it is not available local database will be checked.

ciscoasa(config)# aaa authentication ssh console TACACS LOCAL
ciscoasa(config)# aaa authentication http console TACACS LOCAL

4. Define the accounting method for SSH
1st command is configured for all administrators on all consoles and specifies the TACACS server group to be used for command accounting. 2nd command will be for SSH users.

ciscoasa(config)# aaa accounting command TACACS
ciscoasa(config)# aaa accounting ssh console TACACS

Click here to know how to enable SSH access on Cisco ASA..
Click here to know how to enable ASDM access on Cisco ASA..

Enabling SSH on Cisco ASA for Local Users

Basic yet a useful note, so made a post for my future reference.. Following commands are entered in global configuration mode..

Steps:-

1. Generate Crypto keys
This will be used to generate key pairs for encryption & decryption of data.
ciscoasa(config)#crypto key generate rsa

2. Create Local User Accounts
These will be used as login credentials
ciscoasa(config)#username roshan password cisco123 privilege 15

3. Allow SSH on interfaces per source subnets
This command will define the incoming interface of the ssh session and the source ip range
OUTSIDE is the interface name on my ASA
ciscoasa(config)#ssh 10.1.1.0 255.255.255.0 OUTSIDE

4. Tell ASA to use LOCAL database for usernames and passwords
ciscoasa(config)#aaa authentication ssh console LOCAL

Because the keys are generated by the ASA itself, when you try to connect it using a terminal client, It will show this error. Hit yes and you are in..

Configuring AAA on Cisco Routers / Switches for TACACS Users

Before reading this you may need to know how to configure Cisco ACS server. If so click here and comeback..

Steps:-

1. Enable AAA new model
This will unlock AAA configurations

R1(config)#aaa new-model

2. Define the TACACS server group name and parameters
Key must be the key given as the shared secret of authentication options in Cisco ACS server.

R1(config)#tacacs server TACACS
R1(config-server-tacacs)#address ipv4 10.1.1.200
R1(config-server-tacacs)#key C1sc0#adm

3. Create a default AAA Authentication Method List
The following default method list specifies TACACS+ as the first authentication method option. If TACACS+ authentication failed, local user database will be used.
Also a custom method list can be configured.

R1(config)#aaa authentication login default group tacacs+ local 

4. Create default Authorization Method List.
I am creating this for Shell Privilege and for Privilege Level 15 commands.

R1(config)#aaa authorization exec default group tacacs+
R1(config)#aaa authorization commands 15 default group tacacs+
R1(config)#aaa authorization config-commands

5. Create an Accounting Method List using TACACS+

R1(config)#aaa accounting commands 15 default start-stop group tacacs+

6. Apply the AAA authentication method list "default" to line vty
This command may not required because the method list is the default one. If created a custom one, we should use this command with the custom method list name.

R1(config)#line vty 0 4
R1(config-line)#login authentication default

If you want to know how to configure ssh access for a router please click here.

Now, the user mst_roshan will log into privilege level 15 and commands are authorized using TACACS+ protocol and can watch the AAA Accounting entries in ACS at Monitoring and Reports > Reports > Catalog > AAA Protocol

Click here to know how to enable SSH on Cisco routers & switches..

Configure Users & Add AAA Clients to TACACS Server

If you want to know how to install Cisco ACS server on VMware Workstation to practice this please click here. TACACS server version I use is 5.7 & the AAA client is a Cisco Router..

Steps:-

1. Create a user in Cisco ACS

2. Configure Shell Profiles for Commands Authorization
3. Configure Command Sets for Commands Authorization

4. Binding the Users with Shell Profiles & Command Sets
5. Add the device in Cisco ACS

Let's begin..

1. Create a user in Cisco ACS

Go to Users and Identity Stores > Users and fill the mandatory items.
(click on the images to view in full size)

2. Configure Shell Profiles for Commands Authorization

Go to Policy Elements > Authorization and Permissions > Device Administration > Shell Profiles. Create new, give a name and change the Common Tasks like the following..
I have given the highest privilege level of 15..

3. Configure Command Sets for Commands Authorization

Create a Command Set from Policy Elements > Authorization and Permissions > Device Administration > Command Sets

4. Binding the Users with Shell Profiles & Command Sets

Go to Access Polices >  Default Device Admin > Authorization and click customize

Hit OK and Click on create new..

Give the previously created username and Shell Profile and hit OK and save changes.

5. Add the device in Cisco ACS

Go to Network Resources >  Network Devices and AAA Clients and fill the mandatory items.

If you want to know how to configure a AAA client like a Cisco router for SSH access for TACACS users click here.

Domainless Dynamic NAT & PAT with NVI Zero

I have explained a little about domainless NAT & NVI0 here. If you are not sure what this NVI0 is please read that 1st..

Here are some briefings for Domainless Dynamic NAT.. These are same as Domain Dynamic NAT too..

Maps a local address with a pool global addresses..
Need to have one real public IP address for every private IP address..
Cannot permanently bind a public IP address with host like in static NAT..
When the pool is exhausted, router discards the translation..

Let's configure dynamic NAT on R1..

Enable NAT on interfaces..

R1(config)#int e0/0
R1(config-if)#ip nat enable

R1(config)#int e0/1
R1(config-if)#ip nat enable

Create a pool for private IP range..
R1(config)#access-list 10 permit 192.168.1.0 0.0.0.255

Create a pool for public IP range..
R1(config)#ip nat pool DYNAMIC 203.115.41.110 203.115.41.120 netmask 255.255.255.0

Do the mapping..
R1(config)#ip nat source list 10 pool DYNAMIC

As soon as you enter the above commands, you will not see anything on nat translations & routing table like in static NAT.. But when the traffic is generated, they will start to populate..

When PC-1 is pining the server 203.115.41.221; following will be the output.

You will see a new entry for the public IP address in the routing table too to the outside interface..
Note that it will clear this entry when you clear ip nat translations..

If you are doing PAT (Overloading), following will be the command..

R1(config)#ip nat source list 10 interface e0/0 overload

Domainless Static NAT with NVI Zero

Old style or classic NAT is called Domain NATing because in order to do NAT we specify inside and outside domains. But this method seem to have limitations comparing to the newer introduced  method to do NAT called Domainless NATing.

Here are some example situations where Domain NATing can not be used.

Above VRF example situation, both the VRF subnets (Shop & Bank) have to be NATed when they enter the VRF-Service network. We cannot use Domain NATing here..

And also in the second diagram, you can see that both the INSIDE and DMZ are company's inside networks. So from INSIDE to DMZ what will we use as the domains?

NVI (NAT Virtual Interface) addresses these and many other limitations of classic Domain NATing.. Now the NAT is doing at a virtual interface inside the process rather than doing it on physical interfaces. Even you can do NAT for the traffic of same interface too like in Hair-Pinning or NAT-Loopback in Cisco ASAs.

Let's see a simple example of static NAT 1st..

Let's configure NAT on R2..

Enable NAT on interfaces..

R2(config)#int e0/0
R2(config-if)#ip nat enable

R2(config)#int e0/1
R2(config-if)#ip nat enable

Do the mapping..
R2(config)#ip nat source static 192.168.2.21 203.115.41.221
R2(config)#ip nat source static 192.168.2.22 203.115.41.222

Note:- 

As soon as you enter any NAT related command, NVI0 will come up as a new interface. It will assign an IP address of an actual interface just to show off. It does not matter what the IP address of NVI is. Because I entered a nat command on e0/0 interface 1st it took the IP address of that interface. If I entered a global command I think it will take the lowest interface (E0/0 in this case) IP address.
You cannot go inside to it or change it. If you want to remove it, you have to undo all the NAT related commands and reboot the router..

Now let's see the translations table by show nat nvi translations command..

No translations have been occurred yet as no traffic has passed through..

Let's see the routing table..

Well there are 2 entries in the routing table for NAT IPs. Pretty much the same as in Domain NATing.

When the servers are generating traffic destined to outside of their network (ex:- pinging to 203.115.41.111 which is actually the public IP of PC1 from 203.115.41.221), you will see the following output..

Inside Global, Inside Local & Outside Global, Outside Local have been replaced with the following above which really means the same..

Let's change something and see the behavior..

This time I am changing the source & global address of Server-2, let's see what happens..
Doing the mapping..
R2(config)#ip nat source static 203.115.41.222 192.168.2.22

Now before traffic passes through, the table will be like this..

How about a ping from Server-2 to 203.115.41.111 address now..
Well, it is not pinging, because there is no matching translation rule.

Note:- 

The above command means to translate the source IP to 192.168.2.22 if it is 203.115.41.222
But the source IP is always 192.168.2.22 so the packet will be forwarded from R2 according to the routing table without any translation which will not come back again because the far end destination does not know how to find the 192.168.2.22

Though the rule is incorrect there will be a routing entry for the static destination 192.168.2.22 as a local route via E0/1..

Note:- 

This above example could have been done by Domain NATting too.. More unique examples for Domainless NATing will be discussed in later posts..

Multiple Spanning Tree (MST) Related Basic Configuration

MST is nothing but grouping per VLAN RSTP instances. Back end calculations are same as in Rapid PVST. Grouping multiple instances of Rapid PVST minimizes the processor overhead in managing the topology.

Let's see how it will be configured..

VLAN 11-15 are created in all switches.

By default, Cisco switches run PVST. For all 6 VLANs (including the VLAN 1), there will be 6 PVST instances on all 3 switches.






Let's see what are the roots by default calculations here.

SW-1#show spanning-tree root

Now let's change the mode of STP to MST on all switches..

SW-1(config)#spanning-tree mode mst
SW-2(config)#spanning-tree mode mst
SW-3(config)#spanning-tree mode mst

Now let's see the show spanning-tree root & show spanning-tree outputs..

Now we can see that there is only one instance for all 6 VLANs. There is only one root. Because I entered only the global mode command just to change the mode of STP, all default MST settings have been applied. We can see them by show spanning-tree mst configuration command..

As we can see the revision is 0 and all VLANs are mapped to instance 0. Also there is no name for the region. MST region is just a group of switches which shares same revision number and VLAN to STP instance mappings.

We can configure these parameters in mst configuration mode as well for more controllability. But all the switches in same region must have same configuration.
Note:- these parameters can be pushed through VTP version 3..

SW-1(config)#spanning-tree mst configuration 
SW-1(config-mst)#name REGION-A
SW-1(config-mst)#revision 1
SW-1(config-mst)#instance 1 vlan 11-13
SW-1(config-mst)#instance 2 vlan 14-15

SW-2(config)#spanning-tree mst configuration 
SW-2(config-mst)#name REGION-A
SW-2(config-mst)#revision 1
SW-2(config-mst)#instance 1 vlan 11-13
SW-2(config-mst)#instance 2 vlan 14-15

SW-3(config)#spanning-tree mst configuration 
SW-3(config-mst)#name REGION-A
SW-3(config-mst)#revision 1
SW-3(config-mst)#instance 1 vlan 11-13
SW-3(config-mst)#instance 2 vlan 14-15

Related show command outputs are as following..

Now let's make SW-2 the root for instance 2 by the spanning-tree mst 2 root primary macro command on SW-2..

Note:- 

If it is a migration from other STP to MST, it is best practice to start configuration from mst configuration sub mode and finally enable mode globally starting from root switch..

Configuring GRE Tunnels

It's a method of tunneling data from one router to another router. The sending router encapsulates packets of one networking protocol called the passenger protocol inside packets of another protocol called the transport protocol (ex:- IPv6 inside IPv4). It is not necessarily be two protocols. It can also be used to hide topology information inside a network within same protocol. Also note that GRE tunnel is not an encrypted tunnel.

Here is an example configuration I have done.

Assume that R1's L1:10.10.10.1/24 (interface Loopback 1) is a connected external network to R1 & R4's L1:40.40.40.4/24 (interface Loopback 1) is a connected external network to R4..
Here I am going to tunnel the traffic between those 2 networks..

Configuration of GRE is like the following..

Create the tunnel interface on R1..
R1(config)#interface Tunnel14
R1(config-if)#ip address 14.14.14.1 255.255.255.0
R1(config-if)#tunnel source 1.1.1.1
R1(config-if)#tunnel destination 4.4.4.4

Create the tunnel interface on R4..
R4(config)#interface Tunnel41
R4(config-if)#ip address 14.14.14.4 255.255.255.0
R4(config-if)#tunnel source 4.4.4.4
R4(config-if)#tunnel destination 1.1.1.1

Loopback 0 interfaces of R1 were taken as tunnel sources and destinations for high availability. Those 2 interfaces must be reachable via under lay routing. I used EIGRP on all interface on all routers except the tunnel interfaces. Also both the tunnel interfaces must be in the same subnet.

Setting static routes to destinations on both R1 & R4..

R1(config)#ip route 40.40.40.0 255.255.255.0 14.14.14.4

R4(config)#ip route 10.10.10.0 255.255.255.0 14.14.14.1

Now the configuration is done. Routing tables of R1 & R4 will be like the following..

Pings & Traceroute outputs will look like the following..

Because the tunnel interface seems like a connected interface, you can configure some other routing protocol like OSPF inside tunnel and bring up adjacency if needed.

Note:- 

Default mode of a tunnel interface is GRE. you can change it to some other like ip-in-ip by using the command tunnel mode ipip in tunnel interface.

How RSTP Reacts to Direct & Indirect Failures and Topology Changes

In Rapid Spanning-Tree (RSTP);

1. Direct link failures are handled by the best Alternate Port becoming a new Root Port
2. Indirect link failures are handled by accepting inferior BPDUs from Designated Switches
3. Adding a new Root Link is handled by the Sync Operation
4. Change over of a new Root Switch is handled by the combination of above..

Only a transition of a Non-Edge Port from Non-Forwarding state to Forwarding state is considered a topology change event in RSTP.

When a topology change is detected RSTP switches immediately flood BPDUs with TC flag set. Switches which detect a topology change on its port or learned about a topology change will;

1. Set a tcWhile Timer to the value of a Hello Time plus 1 second on all remaining Non-Edge Designated Ports & Root Port (if any) except the port which the topology change was detected or learned..
2. Immediately flush all MAC addresses learned on these ports..
3. Send BPDUs with the TC flag set on these ports every Hello seconds until the tcWhile Timer expires..

Direct Link Failures

Direct link failure is a failure of the Root Port of a switch which maintains an Alternate Port.

In the topology, you can see that SW-C is the switch we are talking about.

What happens when the e0/2 of SW-C goes down is that RSTP will simply compare the remaining BPDUs on Alternate Ports and choose the port with the superior BPDU as the new Root Port and will immediately become Root-Forwarding..

Indirect Link Failures

Indirect link failure is a failure of the Root Port of a switch which does not maintain an Alternate Port. In the topology, you can see that SW-B is the switch we are talking about.

What happens when the e0/1 of SW-B goes down is that the SW-B thinks that it is the Root Switch now and send inferior BPDUs towards SW-C and they will be accepted right away from SW-C expiring the old superior BPDU stored on his e0/3 port and recalculates the superiority for that segment. Once SW-C identifies its own BPDU as the superior BPDU on the segment, it will declare its port as a new Designated-Forwarding Port from Non-Designated-Discarding state..

Once SW-B receives the superior BPDU from SW-C it will change its e0/3 from Designated-Forwarding to Root-Designating state..

Here is a video for above 2 incidents..

Passive Link / Reachability Failure

In a very rare case, for some reason if a switch does not receive 3 sequential Hellos in a row, it will think the link with the neighbor is down.. Then what it sets the port to Designated-Discarding 1st and starts transmitting Proposals. Even though it does not receive any Agreement for 2 Forward Delay times (fdWhile) it will change the port state to Designated-Forwarding. This 2 times Forward Delay is the time it takes to go through regular Discarding > Learning > Forwarding process.

We can experience this by enabling BPDU Filter on e0/3 port of SW-2 on above diagram.

Before enabling BPDU Filter on SW-2, the show spanning-tree output of SW-3 will be like the following..

After enabling BPDU Filter on SW-2's e0/3 interface, output of the debug spanning-tree events will be like the following..

Then you can see the final port roles and states on show spanning-tree output..

When the BPDU Filter is disabled, a superior BPDU will update the roles back immediately.

Sync Operation of RSTP

Rapid Spanning Tree protocol, commonly known as RSTP (802.1w) does not rely on timers to converge like in Classic STP (802.1d). Convergence mechanism of RSTP is very simple. It is called the Sync Operation / Process.

Goal of a switch is to elect and synchronize its Root Port with the rest of the topology..

The logic behind electing the Root Port is very simple and straight forward just like in Classic STP.
It is the logic of identifying the superior BPDU (Bridge Protocol Data Unit - L2 data frames which contains STP information).

Following is the format of a BPDU..

RSTP uses Type 2 BPDU while Classic STP uses Type 0 BPDU. You can see in the picture above that 802.1d (Classic STP) uses only 2 bits in the flags field while 802.1w (RSTP) uses all the bits in the flags field.

Switches compare the BPDUs received on their ports and determine which one is better. They are compared in the following order, lower the value is better..

1. Root Bridge ID
2. Root Path Cost
3. Sender Bridge ID
4. Sender Port ID
5. Receiver Port ID (not included in the BPDU, evaluated locally)

Also each port in STP stores the superior BPDU that it has either sent or received. Only the Designated Ports send superior BPDUs while Root Ports & Alternate Ports only receive BPDUs.

Note:- There are 2 types of BPDUs called Configuration BPDUs and TCN BPDUs used in Classic STP for initial convergence and to deal with topology changes. But RSTP only use one type of BPDU. Also in STP, configuration BPDUs are originated only in Root switch and all other switches just relay them on their designated ports downstream accoring to the timers configured in Root switch. In RSTP, all switches generate their own BPDUs and send them on their designated ports downstream according to the local timers set on them.

Sync mechanism is simple. It uses few BPDUs to negotiate the port roles. There are 2 BPDUs are involved in the process. They are;

1. Proposals
2. Agreements

Proposals are the BPDUs sent with the Proposal bit set which signifies the willingness of a port to become Designated-Forwarding & the Agreements are the BPDUs sent with the Agreement bit set which signifies permission to do so..

Let's analyze a network segment with 2 switches..
Steps of the Sync are like the following..

As soon as a new point-to-point Non Edge (ports which are connected to other switches) link is up ports of both ends will become Designated-Discarding which is the default port type and role of a Non Edge port..

Both Designated-Discarding and Designated-Learning ports send Proposals.

Superior BPDU will be from the SW-A obviously and once it hits SW-B, SW-B will change the port role of e0/2 to be the Root-Discarding immediately & put its all Non-Edge Designated ports to be Designated-Discarding..

Now SW-B sends an Agreement to SW-A saying now it's safe to move from Designated-Discarding to Designated-Forwarding.. After receiving the Agreement from SW-B, SW-A changes the role of it's e0/1port to Designated-Forwarding..

Still the other Non-Edge Designated ports on SW-2 are in Designated-Discarding state. Which means they send Proposals too. Same above Sync operation will happen on their downstream segments until all the network gets converged..

As you know Classic STP takes 50 seconds to converge a link by default timers.
If you want to see how much time will it take for RSTP, watch the following video.

Instantly becomes green ryt?

Let's power on a switched network..

For the lab I am using actual Catalyst 3750 as the SW-1 and Catalyst 2960s as other switches..
So the ports will be Gi1/0/1 and Gig1/0/2 in SW-1 and others will be Fastethernet but the numbers represent the same as in the diagram.. For the sake of getting more understandable debug outputs, I am connecting one link by one link.

I am connecting the SW-1 to SW-2 segment 1st..

Here are the related outputs debug spanning-tree events command of SW-1 & SW-2..
(click on the images to see in full size)

Next I am connecting SW-1 & SW-4 segment.
Here are the related outputs debug spanning-tree events command..

Finally I am connecting both the links of SW-3 at once..
Here are the related outputs debug spanning-tree events command..

As you can see Fa0/1 (e0/1) of SW-3 has become the Alternate Port..