NetworkJutsu

Network Security Consulting | San Francisco Bay Area

Blog

Cisco Live 2012 Schedule

By Leave a Comment

Here’s my schedule for the Cisco Live 2012 San Diego.

Since I am taking the CCIE R&S Written at Cisco Live, I am including this as well.

As you can see, the schedule for my written overlaps with the FCoE for the IP Network Engineer session since the written is a two-hour exam. Hopefully, I won’t miss the good stuff since I am really new to the data center realm. The Cisco UCS that we’re bringing in should be a good experience once it has been deployed since I’ll be involved with that. It’ll also give me hands on experience with Nexus 1000V since we bought it with the Cisco UCS bundle. That’s the reason why I am taking some sessions about Nexus as well. I have very limited exposure with NX-OS since my previous employer had other network engineers that were in charge of the data center. There were only several instances that I had to log in to those routers since most of the projects that I handled and daily tasks were away from the data center part of the network.

Anyway, if you’re in the same session as I am, please feel free to say hi.

Enabling AAA on Cisco ASA

By 7 Comments

Enabling AAA on Cisco routers and switches were covered a while back in this guide. As previously mentioned, I am quite new to Cisco ASAs since my old environment was pure routing and switching. Firewalls were handled by IT Security and the firewalls weren’t ASAs. Having said all of that, I enjoy playing with ASAs whenever I get a chance. A couple of days ago, I started teaching myself using the CLI since I’ve always used the ASDM for making changes. I occasionally use the CLI, but not heavily since I am still a newbie in using ASAs. If you are in the same situation as I am, one of the books that are very helpful for non-full time network security engineer is Cisco ASA for Accidental Administrators: An Illustrated Step-by-Step ASA Learning and Configuration Guide. I have no experience with this book so please read through the reviews to make sure it is the one you need.

As I was teaching myself on how to configure an ASA from scratch using CLI, I decided to play around with AAA since I need to get our production ASAs to communicate to our TACACS+ server anyway. After playing around with it and reading the AAA section of Cisco ASA: All-in-One Firewall, IPS, Anti-X, and VPN Adaptive Security Appliance, I came up with a configuration that will be our standard when building ASAs.

Related: How to configure tac_plus (TACACS+ daemon) on Ubuntu Server

Without further delay, here are the steps to enable AAA on ASA using CLI:

This command enables the TACACS+ protocol and use the name TACACS+ as the AAA server group.

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

To specify the maximum number of failures that will be allowed for any server in the group before that server is deactivated. The default value is three.

aaa-server TACACS+ max-failed-attempts 3

There are two different AAA server reactivation modes in ASA: timed mode and depletion mode. The command below is the timed mode. With the timed mode, it reactivates a failed server after 30 seconds of downtime. In my limited testing, it continuously tried to reactivate the server after 30 seconds when I bring the TACACS+ server down.

ciscoasa(config-aaa-server-group)# reactivation-mode timed

With the depletion mode shown below, the failed TACACS+ server will stay down until all servers in the group are in the failed state. The default deadtime is 10 minutes.

ciscoasa(config-aaa-server-group)# reactivation-mode depletion

To check the status of the TACACS+ server on a particular ASA.

ciscoasa# show aaa-server proto tacacs | i status
Server status:   FAILED, Server disabled at 15:15:52 UTC Wed Mar 5 2012
Server status:   FAILED, Server disabled at 15:15:52 UTC Wed Mar 5 2012

This command specifies the TACACS+ server’s IP address. If you notice there’s a (inside) keyword in the command. This basically tells the ASA which interface to send the TACACS+ traffic. If the TACACS+ server is actually on the outside interface, then you just change it to outside. In this scenario, the TACACS+ is part of the inside network.

aaa-server TACACS+ (inside) host 192.168.100.200 tacacs-key timeout 3
aaa-server TACACS+ (inside) host 192.168.100.201 tacacs-key timeout 3

By issuing this command, it instructs the ASA to use the user’s enable password stored in the TACACS+ server first and then use the local enable password as a backup if the TACACS+ servers are unavailable.

aaa authentication enable console TACACS+ LOCAL

Don’t get confused with the keyword console and serial console. The serial is the actual physical console port in the ASA. If you do not issue this command, ASA will use the user local user database for authentication. Same thing as above, if TACACS+ is available then it will always use the stored account on the server before using the local account.

aaa authentication serial console TACACS+ LOCAL

This is a good idea to enable if you want to manage your ASA using ASDM. Same thing as above, if TACACS+ is available then it will always use the stored account on the server before using the local account.

aaa authentication http console TACACS+ LOCAL

This is for managing your ASA using SSH. Same thing as above, if TACACS+ is available then it will always use the stored account on the server before using the local account. If you want to manage your ASA using telnet, just change the ssh keyword to telnet. I honestly do not recommend using telnet.

aaa authentication ssh console TACACS+ LOCAL

Once the authentication part is finished, now you need to enable the authorization. This tells the ASA what commands are available for the authenticated user. To enable authorization, issue the command below. Again, if TACACS+ is available then it will always use the stored account on the server before using the local account.

aaa authorization command TACACS+ LOCAL

Once done with the authorization, you may want to monitor the commands that have been issued in the ASA. To enable accounting, issue the command below. This command will only monitor issued commands that are listed in the privilege level 15. If you want to monitor all commands, feel free to change the level to 1.

aaa accounting command privilege 15 TACACS+

There you have it, a step by step guide on how to enable AAA on Cisco ASAs. There’s no good reason to not enable AAA especially if you can get the TACACS+ server for free!

I hope this has been helpful and thank you for reading!

Related blog posts:

How to build and configure tac_plus
TACACS+ (tac_plus daemon) ACL

Reference

Cisco ASA: All-in-One Firewall, IPS, Anti-X, and VPN Adaptive Security Appliance

Want to learn more about ASA?

Cisco ASA: All-in-one Next-Generation Firewall, IPS, and VPN Services (3rd Edition)
Cisco ASA for Accidental Administrators: An Illustrated Step-by-Step ASA Learning and Configuration Guide

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

OSPF Network Types

By Leave a Comment

OSPF behavior using different interface types.

Interface TypeUses DR/BDR?Default
Hello
Interval		Requires a
neighbor
Command?		More than Two
Hosts Allowed
in the Subnet?
BroadcastYes10NoYes
Point-to-point 1No10NoNo
Nonbroadcast 2 (NBMA)Yes30YesYes
Point-to-multipointNo30NoYes
Point-to-multipoint nonbroadcastNo30YesYes
LoopbackNo——No

1 Default on Frame Relay point-to-point subinterfaces.
2 Default on Frame Relay physical and multipoint subinterfaces.

Reference

CCIE Routing and Switching Certification Guide 4th Edition

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

QoS Classification and Marking

By 4 Comments

About three or four months ago, we’ve rolled out VoIP to our first remote site and was tasked to implement QoS. At the time, I knew a little about QoS (I still do) and that was the first reason why I had to read the QoS book last year. That was great since it also knocked down one area in my CCIE studies, but I am still not confident enough that what I currently know is enough for CCIE.

In my previous environment, we just copy and paste the QoS template and it should be good to go. That template is great and I am sure it is still being used by other engineers there since there were no issues in call quality using it. From what I was told, the template was just a tweaked version of Auto QoS. Anyway, today I’ll talk about what I learned about one topic in QoS. This post will not cover everything about the classification and marking since there are several ways of doing it.

In the most basic explanation, classification is a way for a router/switch to distinguish regular packets (DSCP value of zero or BE) from “premium” packets (DSCP value 46 or EF). By default, Cisco Catalyst switches do not care about the DSCP markings on the packets received, so no classification occurs. To verify this, let’s issue the command show mls qos int f0/1 using Catalyst 3560.

Switch#show mls qos int f0/1
FastEthernet0/1
QoS is disabled. When QoS is enabled, following settings will be applied
trust state: not trusted
trust mode: not trusted
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

As you can see, the switch has QoS disabled and the ports are not trusted by default. To enable classification, QoS must be enabled globally and the command to do this is mls qos. After issuing this command, the show mls qos int f0/1 command will no longer show that QoS is disabled, as shown below.

Switch(config)#mls qos
Switch(config)# do show mls qos int f0/1
FastEthernet0/1
trust state: not trusted
trust mode: not trusted
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

As you can see above, the output no longer shows that the QoS is disabled. However, the switch still do not trust the DSCP markings and will be marked zero or BE (best effort). There are several options to trust the DSCP marking and the most basic one is shown below.

Switch(config)#int f0/1
Switch(config-if)#mls qos trust dscp
Switch(config-if)#do show mls qos int f0/1      
FastEthernet0/1
trust state: trust dscp
trust mode: trust dscp
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

Majority, if not all, of Cisco and Avaya phones mark the voice payload packet with DSCP 46 (EF) and COS 5 which is great since we do not have to do anything to mark them and we can just trust it. However, my issue with this command is that it will trust any packet that has an EF tag. That said, if a savvy user or worse a hacker who wants to do a DoS attack can mark their packets with an EF tag and when congestion occurs these unauthorized packets will be prioritized as well as your real time traffic, like VoIP. So, how can we prevent this from happening? Well, there several options that we can do. The very obvious one is by using the command below. However, this command will not help us if the phone isn’t made by Cisco. How does it know to differentiate if the phone is Cisco or not? You know it! By using CDP.

Switch(config-if)#mls qos trust device ?
  cisco-phone  Cisco IP Phone

Since the command above is not a non-Cisco phone friendly, what other options can we use so it’ll work with an Avaya or other IP phones available out there? There are two commands that I use for this depending on the platform. The first one is shown below. I normally use this command on 3560, 3750, and 6500. This command will not work on some platform, if I recall correctly, this will not work with 2950 and for sure on a Catalyst 4500 with Sup 7E. The Sup 7E uses MQC (Modular QoS CLI) to do QoS so no more srr or wrr commands. It basically acts just like a router which is great in my opinion since tweaking srr and wrr commands can be a pain. I honestly still do not know a whole lot about it but I’ll attempt to cover it some time this year.

Switch(config)#int f0/1
Switch(config-if)#mls qos vlan-based
Switch(config-if)#do show mls qos int f0/1
FastEthernet0/1
trust state: not trusted
trust mode: not trusted
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: vlan-based

With this command, you will apply the policy on the SVI (Switch Virtual Interface) and not on the physical interface of the switch as shown below.

interface Vlan10
 description Voice VLAN
 ip address 192.168.1.254 255.255.255.0
 service-policy input PRIORITY

The service-policy input PRIORITY command will not work without having a policy map configured as shown below. Without a class map configured, you can’t really match anything under policy map. Having said that, you really need to follow the flow that was covered here.

Switch(config-if)#service-policy input PRIORITY
policy map PRIORITY not configured

Since I referred to my previous blog post, I’ll explain what those commands mean since they’re important part of this topic.

ip access-list extended VOICE-RTP
 permit udp 192.168.1.0 0.0.0.255 any range 16384 32767

16384 – 32767 is the port range that Cisco uses for its voice payload. This ACL will help us out with the classification phase.

ip access-list extended VOICE-SIGNALING
 permit tcp 192.168.1.0 0.0.0.255 any range 2000 2002

2000 – 2002 is what Cisco uses for its proprietary signaling protocol, Skinny Call Control Protocol (SCCP), also known as Skinny. The concept is pretty much the same as above, but signaling gets a lower DSCP value as mentioned in Cisco’s SRND (Solution Reference Network Design) Guide.

class-map match-all VOICE-RTP
 match access-group name VOICE-RTP
class-map match-all VOICE-SIGNALING
 match access-group name VOICE-SIGNALING

These commands create class maps named VOICE-RTP and VOICE-SIGNALING and will be used later for the policy map. These class maps uses the named ACL we created to classify which traffic will be trusted for QoS purposes. If traffic doesn’t match the ACL, then it will not be classified as voice related traffic.

policy-map VOICE
 class VOICE-RTP
  set dscp ef
 class VOICE-SIGNALING
  set dscp cs3

The policy actually tags the traffic that match our class maps with a DSCP EF tag. As mentioned, Cisco or Avaya phones mark their packet with DSCP EF so the set command is unnecessary. Truthfully, if you really want to be very specific in the ACL earlier you can do so as shown below. If I remember correctly, the older Cisco phones do not set their packet to CS3 and according to the revised SRND to remark it to this value. To be safe, let the set command under the voice signaling. Now with Avaya phones, I was told that the phones mark their signaling traffic to DSCP 46 (EF) which isn’t the recommended per SRND. Make sure to remark those packets or they will be competing with the voice payload.

ip access-list extended VOICE-RTP
 permit udp 192.168.1.0 0.0.0.255 any range 16384 32767 dscp ef

As mentioned earlier, the service-policy command is to apply the policy we just created. The direction included in the command works just like ACL – input coming into the interface and output going out of the interface.

interface Vlan10
 description Voice VLAN
 load-interval 30
 service-policy input VOICE

I like the mls qos vlan-based better since I can create separate policy for voice and data, but in the real world sometimes what you like isn’t always going to work. As mentioned earlier, the Sup 7E for Catalyst 4500 will not allow you to issue commands like wrr, srr, and mls qos. Having said that, the other option that I use is the service-policy command, which has been covered already. The only thing why I dislike using this is because I need to combine data and voice policies into one. Not really a big deal, just a preference.

Since we’ve covered the MQC already, then you already know how to combine the data and voice policy. What I like to do with my policy map though is call it something like DATA+VOICE or something to that effect which will definitely help the next guy that touches the network, at least in my opinion. Below is an example of a data and voice policy, but this is not complete by any means.

class-map match-any BULK
 match protocol ftp
 match protocol secure-ftp
class-map match-all MISSION-CRITICAL
 match protocol citrix
class-map match-any SCAVENGER
 match protocol gnutella
 match protocol edonkey
 match protocol kazaa2
 match protocol bittorrent
!
policy-map DATA+VOICE
 class VOICE-RTP
  set dscp ef
 class VOICE-SIGNALING
  set dscp cs3
 class MISSION-CRITICAL
  set dscp af31
 class BULK
  set dscp af11
 class SCAVENGER
  set dscp cs1
!
interface f0/1
 service-policy input DATA+VOICE

If you noticed, I didn’t use ACL for the data part. I used NBAR (Network Based Application Recognition) to classify the traffic. For your information, this is not available with 3560 or 3750 – only subset of NBAR. I only used it to show another way to classify a packet without using ACL. Also if you noticed, I have match protocol bittorrent in there but if you try to use it on router without the bittorrent PDLM (Packet Description Language Module), which is available for download from Cisco, then it will not work.

While I didn’t cover everything there is to know about classification and marking, I believe I’ve covered enough to get someone started with their QoS configuration. I will definitely try to cover srr commands next time since it is recommended to use L2 QoS/CoS even though it is high speed link compared to a typical WAN link.

I hope this has been helpful and thank you for reading!

References

Cisco QoS Exam Certification Guide (IP Telephony Self-Study) (2nd Edition)
End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPN

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

Proxy ARP

By 2 Comments

Proxy ARP (Address Resolution Protocol) is a technique in which a device, usually a router, answers ARP queries intended for another device. Cisco routers and Catalyst multilayer switches have this protocol turned on by default. This allows a misconfigured device to reach other subnet without setting a default gateway. This also pose a security problem since it will allow an attacker to issue multiple ARP requests and use up the router/switch’s resources when it tries to respond to all ARP requests in a DoS (denial of service) attack.

An example of how proxy ARP works is shown below. In this example, there are four devices – two of them are acting as routers and the other two are acting as a regular PC. The R1’s IP configuration was configured correctly, while the R4’s IP configuration was configured with incorrect subnet mask and no default gateway.

R1’s IP configuration and routing table:

R1#sh run int f0/0
Building configuration...
Current configuration : 97 bytes
!
interface FastEthernet0/0
 ip address 172.17.100.1 255.255.255.0
 duplex auto
 speed auto
end
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is 172.17.100.254 to network 0.0.0.0
     172.17.0.0/24 is subnetted, 1 subnets
C       172.17.100.0 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 [1/0] via 172.17.100.254

R4’s IP configuration and routing table:

R4#sh run int f0/0
Building configuration...
Current configuration : 92 bytes
!
interface FastEthernet0/0
 ip address 172.17.99.1 255.0.0.0
 duplex auto
 speed auto
end
R4#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C    172.0.0.0/8 is directly connected, FastEthernet0/0

Now, let’s try to ping R1 from R4. This should be successful since proxy ARP is enabled by default on Cisco routers.

R3’s show ip interface f0/0 output:

R3#sh ip int f0/0
FastEthernet0/0 is up, line protocol is up
  Internet address is 172.17.99.254/24
  Broadcast address is 255.255.255.255
  Address determined by setup command
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.10
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is enabled
  Local Proxy ARP is disabled
! Omitted for brevity

R4’s ping output:

R4#ping 172.17.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.100.1, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 40/52/60 ms

My guess on the two packets that failed were because it took a while before the router steps in to be the proxy. Once R4 has the MAC address of R1 in the ARP table any succeeding communication between them will be successful.

Now, let’s disable proxy ARP on R3 and make sure R4’s ARP table does not have R1’s IP address.

R3(config)#int f0/0
R3(config-if)#no ip proxy-arp
R3#sh ip int f0/0
FastEthernet0/0 is up, line protocol is up
  Internet address is 172.17.99.254/24
  Broadcast address is 255.255.255.255
  Address determined by setup command
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.10
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is disabled
  Local Proxy ARP is disabled
! Omitted for brevity
R4#sho ip arp f0/0
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.17.99.254          17   c002.1704.0000  ARPA   FastEthernet0/0
Internet  172.17.100.1            8   c002.1704.0000  ARPA   FastEthernet0/0
Internet  172.17.99.1             -   c003.1704.0000  ARPA   FastEthernet0/0
R4#clear arp int f0/0
R4#sho ip arp f0/0
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.17.99.254           0   c002.1704.0000  ARPA   FastEthernet0/0
Internet  172.17.99.1             -   c003.1704.0000  ARPA   FastEthernet0/0

Now R4 does not have the 172.17.100.1 listed in the ARP table let’s try to ping R1.

R4#ping 172.17.100.1 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 172.17.100.1, timeout is 2 seconds:
..........
Success rate is 0 percent (0/10)

As shown above, R4 is now unable to communicate with R1 when proxy ARP is disabled. This should definitely be disabled when it is not needed to harden your Cisco network devices. For more tips to harden your Cisco network devices, please visit here. I will keep adding to this list as time allows.

I hope this has been helpful and thank you for reading!

References

Cisco Proxy ARP
Basic Cisco IOS Software and Catalyst 3550 Series Security

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.