Cisco Guest Blog

Check out my guestblog @ Cisco: http://blogs.cisco.com/perspectives/dmz-basics

 

Advertisements

Differences between HP, 3COM and Cisco

Lately I have been working a lot with HP(2610, 2620), 3COM(4500, 5500) and Cisco switches. For a customer I migrated the 3COM cores switch to a Cisco Coreswitch. Before this job I never worked with HP or 3COM before. Although networking principles and protocols are the same for Cisco, HP and 3Com, there are some substantial differences between them.

First of all you have to understand that “trunking” in Cisco language means that you configure a port to transport several vlan’s. In HP/3COM it means bundeling two or more physical interfaces to one logical interface. Bundeling physical ports to become one logical port is called “port-channeling” in Cisco language.  The equivalent of Cisco’s trunking in HP/3COM language is “port tagging”.

When you configure a trunk port on a Cisco switch, you configure the port to allow trunking of several vlan’s. When configuring port-tagging you create a vlan and add ports to the vlan. An example:

Cisco:
Trunk_Cisco

HP:

HP

3COM:

3com_vlan

3com trunk

 

Since HP bought 3COM in 2010, I was clearly dealing with a lot of old stuff. So the 3COM CLI doesn’t exist anymore on modern switches. It’s all HP now. Nevertheless it is possible you encounter 3COM switches in modern networks. Below a table with some handy show command’s for Cisco and the equivalents for HP and 3COM.

commands

Then there is good old spanning-tree. On the internet you read a lot about horror story’s about spanning-tree between Cisco and HP/3COM. After reading about it, I configured “rapid spannig-tree ” (802.1w) on the Cisco core switchs. On the HP and 3COM switches the equivalent of 802.1w was already configured. After replacing the 3COM core switch with the Cisco model, I did not encounter any problems with spanning-tree!

One other thing that catched my attention, is that the HP 2610 and 2620 only host a maximum of 8 vlan’s and 16 static routes.

Off course there are a lot of other differences between Cisco and HP/3COM, but the ones described as above are the most obvious ones.

 

Web Cache Communication Protocol (WCCP)

A customer implemented a transparant Cisco WSA (Ironport) for the redirection of the http and https traffic. WCCP had to be configured on their Cisco 3750 switch with IOS releas 12.2(55)SE9.
First some background info on WCCP:

The Cisco IOS WCCP feature allows utilization of Cisco Cache Engines (or other caches running WCCP) to localize web traffic patterns in the network, enabling content requests to be fulfilled locally. Traffic localization reduces transmission costs and download time.
WCCP enables Cisco IOS routing platforms to transparently redirect content requests. The main benefit of transparent redirection is that users need not configure their browsers to use a web proxy. Instead, they can use the target URL to request content, and have their requests automatically redirected to a cache engine. The word “transparent” is this case means that the end user does not know that a requested file (such as a web page) came from the cache engine instead of from the originally specified server.
When a cache engine receives a request, it attempts to service it from its own local cache. If the requested information is not present, the cache engine issues its own request to the originally targeted server to get the required information. When the cache engine retrieves the requested information, it forwards it to the requesting client and caches it to fulfill future requests, thus maximizing download performance and substantially reducing transmission costs.
WCCP enables a series of cache engines, called a cache engine cluster, to provide content to a router or multiple routers. Network administrators can easily scale their cache engines to handle heavy traffic loads through these clustering capabilities. Cisco clustering technology enables each cache member to work in parallel, resulting in linear scalability. Clustering cache engines greatly improves the scalability, redundancy, and availability of your caching solution. You can cluster up to 32 cache engines to scale to your desired capacity.

I took the above text from the Cisco website, so if you want to read more on the theory behind WCCP check out: http://www.cisco.com/c/en/us/td/docs/ios/12_2/configfun/configuration/guide/ffun_c/fcf018.html

To configure WCCP on a Cisco 3750 there are some constraints:

  • Make sure SDM prefer is on an routing image
  • Forwarding can only be L2 (in the WSA this is default GRE or L2, configure it hard on L2 only)
  • Assignement method can only be MASK (in the WSA this is default HASH or MASK, configure it hard on MASK only)
  • Make sure clients and WSA are on different vlan’s
  • Forwarding redirect list can only understand PERMIT statements
  • When usig a dynamic WCCP identifier configure in the WSA the ports that have to be redirected, in this example it has to be 80(http) and 443(https)

Configuration will look like below:
First configure the routed vlan’s
!
vlan 100
name WSA
!
vlan 200
name Clients
!
int vlan 100
ip address 10.10.10.254 255.255.255.0
no shut
!
int vlan 200
ip address 172.18.10.254 255.255.255.0
no shut
!

Then configure the access-lists to “catch” the client traffic that has to be redirected:
!
ip access-list extended 100
permit tcp 172.18.10.0 0.0.0.255 any eq www
permit tcp 172.18.10.0 0.0.0.255 any eq 443
!
I used a numbered ACL, so I can debug it. A named list can’t be debugged! Make the ACL as specific as possible!

Then create an ACL for the redirect-list. This ACL consists of the WSA addresses.
!
access-list 10 permit 10.10.10.1
access-list 10 permit 10.10.10.2
!

The actual WCCP configuration consist out of two command.
A global command:
!
ip wccp 100 redirect-list 10
!

And a command on the client vlan interface:
!
int vlan 200
ip wccp 100 redirect in
!

There isn’t more to it. To check if WCCP is functioning use the “show ip wccp 100 [detail|view]” command.
To check a little deeper, use the “debug ip wccp packets” command. If you see the “WCCP2_HERE_I_AM” and “WCCP2_I_SEE_YOU” packets than the WCCP mechanism is functioning.
Even if WCCP functions it’s possible traffic does not get redirected. This can be due to a dozen of problems. First step is to check if the client traffic is redirect at all. This can be done by using the “debug ip packet detail 100” command. If no traffic hits the ACL, traffic won’t be redirected to the WSA.

VSS on Cisco 4500-X

For a customer I recently configured two Cisco 4500-x switches with VSS (Virtual Switching System). VSS makes two 4500-x switches to function as one logical switch. By configuring VSS on botch switches, there is one active RP (Route Processor) and one hot standby RP. When the active RP fails, the hot standby RP will take over operations without the loss of data.

The VSS switches are connected by an VSL (Virtual Switch Link), which is normally build as an etherchannel. The VSL serves as logical connection that carries critical system control information such as hot-standby supervisor programming, line card status, Distributed Forwarding Card (DFC) card programming, system management, diagnostics, and more. In addition, VSL is also capable of carrying user data traffic when necessary.

By using VSS it’s possible to uplink a switch with two uplinks in an etherchannel.This is called a MEC (Multichassis Etherchannel). Because you connect the uplinks to two switches functioning as one, there is no need for spanning-tree to block one of the links. So instead of two uplinks with one blocked by spanning-tree, there are two active links which makes it possible to use a 2 x 1/10/40Gb etherchannel as uplink.

To prevent both switches from becoming active, there is a mechanism called “Dual active detection” or VSLP (Virtual Switch Link Protocol). Two modes are available, PagP and Fast-hello. In the following configuration example, I’ll give an example of VSS with “Fast-hello” dual active detection.

The picture below depicts the written above:
VSS

Now let’s take a look at the configuration:

First configure the switches seperatly
Switch1
!
conf t
!
switch virtual domain 100
switch 1
switch 1 priority 110
mac-address use-virtual
!
int pox
switchport
swi virtual link 1
no shutdown
!
int range tx/x/x – x
channel-group 101 mode on
no shut
!
switch set switch_num 1 local
switch read switch_num 1 local
!
end
!
wr
!

Switch2
!
conf t
!
switch virtual domain 100
switch 2
switch 2 priority 90
mac-address use-virtual
!
int poxx
switchport
sw virtual link 2
no shutdown
!
int range tx/x/x – x
no switchport nonegotiate
channel-group x mode on
no shutdown
!
end
!
switch set switch_num 2 local
switch read switch_num 2 local
!
wr
!

After this give the following command on both switches to convert them to VSS mode:
!
switch convert mode virtual
!

After rebooting the Fast-hello dual active detection can be configured.
Switch1
!
conf t
!
switch vitrual domain 100
dual-active detection fast-hello
!
int tx/x/x
dual-active fast-hello
no shut
!
end
!
wr
!

Switch2
!

conf t
!
switch virtual domain 100
dual-active detection fast-hello
!
!
int tx/x/x
dual-active fast-hello
no shut
!
end
!
wr
!

Make sure u use an IOS XE version higher than:  cat4500euniversal.SPA.03.04.03.SG.151-2.SG3.bin
The IOS XE version above supports only PagP dual active detection!

To be fully complete in the IOS XE version mentioned earlier is a bug. If you try to configure the Fast Ethernet ports for management, the won’t work. It’s possible to configure a IP address and so one. The “show ip int brie” commando will even say the interface is up, but it’s just not possible to ping the interface.
After an IOS upgrade everthing came to life and functioned as intended.

 

Initial Nexus 5548 Configuration

For a customer I installed a Nexus solution, based on 5548 switches (5k) en 2248 FEX (2k) devices. In this post I will show you how to configure the Nexus switches to function as the toplogy beneath shows.

nexus

Although there are two Nexus 5k switches in the drawing, they function as one logical unit after configuring.

Before you start on a Nexus device, enable the services you need. In our case the following services are enabled:
!
feature vcp
feature lacp
feature fex
!

First configure the managment ports on both switches, so we can access the devices from the network. Use the management vrf, the default vrf which is on the device out of the box.

!

interface mgmt0
ip address <ip address /subnet>
!
vrf context management
ip route 0.0.0.0/0 <next hop>
!

Now configure the Peer-Keepalive link, this is a “heartbeat” between the two Nexus 5k switches.  First configure a vPC domain.
!
vpc domain 1
role priority 1200
!
They actual Peer-Keepalive configuration is done under the vPC domain configuration

!
vpc domain 1
role priority 1200
peer-keepalive destination <target ip address> source <local ip address>
!

In our case we used the management port as the Peer-Keepalive link, but it is also possible to use a normal switchport for the Peer-Keepalive.
To verify the above configuration use the “show vpc peer-keepalive” commando.
show_vpc_peer-keepalive

Now we have to configure the Peer Link. This link has to be redundant, in our configuration we use a port-channel of 2 x 10Gb links. Traffic on this link is intra vPC traffic, therefore the only traffic on this link is the traffic of vlan’s that are used in the vPC’s.
!
int eth x/x – x
channel-group <nr> mode active
no shut
!
int Po<x>
switchport mode trunk
switchport trunk allowed vlan x,x,x,x,x
vpc peer-link
!

To verify the vPC Peer-Link use the “show vpc” command.
show_vpc

 

The basic configuration of the two Nexus 5k switches is done. Now we can start connecting the FEX’s.  A FEX can be compared with a line card in a modular switch like the Cisco 6500. Like a line card, the management of a FEX is done on the Nexus 5k switch. There are two possible options to connect a FEX.
1) Redundant uplinks to both Nexus 5k switches
2) Single connection to one of the Nexus 5k switches

Because the 2 Nexus 5k switches work as one logical unit and all servers are connected to a FEX on unit 1 and FEX on unit two, it’s not necessary to connect a FEX redundant to both Nexus 5k units.
It’s possible to connect 24 FEX devices per 5k unit in layer 2 mode on the standard license. So if the FEX’s only connect to one 5k unit, it is possible to connect up to 48 FEX units with two 5k units in layer 2 mode. If you connect a FEX redundant to both units, it will cost a license on both units, which means that only 24 FEX units can connect to your Nexus 5k units.

Fot this implementations the customer chose for option two as described above.

To connect a FEX to a 5k unit the following configuration is needed
!
interface port-channel10
switchport mode fex-fabric
fex associate 101
!
interface Ethernet1/1
switchport mode fex-fabric
fex associate 101
channel-group 10
!
interface Ethernet1/2
switchport mode fex-fabric
fex associate 101
channel-group 10
!

It will take some time before the FEX is available, to monitor the status of the FEX, use the “show fex <nr>”
sh_fex_nr

 

Howto Install Cacti on Ubuntu

Recently I wrote a blogpost about Smokeping. Although Smokeping is good in what it does, I needed some more features than available in Smokeping.
The customer for who I am setting up this monitoring needs more information like cpu usage history or memory history. After some research I got to Cacti. Cacti is an open source solution that has many possibilities like latency polling, cpu usage, memory usage and bandwidth usage. Cacti can do a lot more, but for this customer the above things are the key features.
Cacti is available for Windows and Linux. For this kind of tools I always use Linux, beacause 9 out of 10 times the tools work on Linux “out-of-the-box” and the windows versions need a lot of tweaking and tuning.
Installing Cacti on Ubuntu:
  • First update your machine –> sudo apt-get update (If you are behind a proxy server use the following command: http_proxy=http://ip-adres:port-nr apt-get update )
  • Install Cacti –> sudo apt-get install cacti
  • During the install you have to give in some password e.d., just follow the installation and everthing will be fine
  • After installing give the following cli commando: rrdtool create datafile.rrd DS:mysource:ABSOLUTE:900:0:10000000 RRA:AVERAGE:0.5:1:9600 RRA:AVERAGE:0.5:4:9600 RRA:AVERAGE:0.5:24:6000
  • Now open a browser with: http://ip-adres/cacti, follow the instructions and the installation is done
  • To actually monitor a device follow the next steps:
  • Click Console–>Devices–>Add, make sure it looks like the picture below
  • Capture
  • Click Create
  • When the screen reloads some new options are available, “Associated Graph Template” and “Associated Data Queries”, this are options to monitor several different types of devices.
  • To monitor the CPU load and Latency add “Cisco – CPU Usage” and “Unix – Ping Latency” to “Associated Graph Templates”
  • To monitor interface bandwidth add “SNMP – Interface Statistics” to “Associated Data Queries”
  • Click Save
  • Click Devices again and check the box and choose “Place on a tree” and click Go
To create the actual graph follow the next steps
  • Click new Graphs
  • Check the checkboxes of the interfaces/processes you want to monitor and click Create
  • Wait for five minutes and click graphs

 

Now you can see the graphs, but they are not filled….. Damn!
This can be resolved by following the next steps:

 

  • Open the ping.pl script: sudo nano /usr/share/cacti/site/scripts/ping.pl, the output will look like this:

 

#!/usr/bin/perl
# take care for tcp:hostname or TCP:ip@
$host = $ARGV[0];
$host =~ s/tcp:/$1/gis;
open(PROCESS, “ping -c 1 $host | grep icmp_seq | grep time |”);
$ping = <PROCESS>;
close(PROCESS);
$ping =~ m/(.*time=)(.*) (ms|usec)/;
if ($2 == “”) {
print “U”;  # avoid cacti errors, but do not fake rrdtool stats
}elsif ($3 eq “usec”) {
print $2/1000; # re-calculate in units of “ms”
}else{
print $2;
}

 

  • Change “icmp_seq” into “icmp_req” save the file and restart the server

Wait for a couple of minutes and you’ll see that the graphs are getting filled!

Install and configure Tacacs.net

A customer asked me for a central management point for switch and router logins. Also they want the option of accounting these logins.

The first option that comes in mind is Cisco ACS, but that should have been to easy. The customer told me it had to be a cost efficient solution.
After searching the internet I came across Tacacs.net, after reading the configuration guide I came to the conclusion that this piece of software had all the features the customer was asking for. Tacacs.net is able to perform authentication, authorization and accounting. Tacacs.net has also the ability to use a Microsoft active directory for credential authorization.
Tacas.net is fully build in xml, so configuring is not that difficult. Although there is a configuration guide available, there are some tricky parts.
So below a walktrough for configuring tacacs.net
  • First download the tacas.net zip file from http://www.tacacs.net
  • Tacas.net can be installed on all windows platforms starting at windows 2000 server, for this customer I chose Windows 2008 R2.
  • Follow the instructions and for most customers the standard installation is sufficient. While installing tacacs.net asks for a tacacs key. Choose a random string of numbers and/or letters and write it down somewhere. This key is needed when configuring the network equipment
  • After installaling check if the tacacs.net service is running, it can be checked by start–>run–>services.msc
  • After checking this the real configuration can start
  • First check the tacplus.xml file. Change the ip address from 127.0.0.1 to the local ip address. This is not really necessary if there is only one network interface. But it is always recommended to configure it manually.
  • Now open the authentication.xml. The customer want to connect tacacs.net to their active directory. Make sure the section under “Active Directory configuration” looks like the configuration below:

<UserGroup>

<Name>Network Operations</Name>

<AuthenticationType>Windows_Domain</AuthenticationType>

<LDAPServer>{ip address of DC:389</LDAPServer>

​  <LDAPUserDirectorySubtree>OU=<group>,OU=<group>,OU=<group>,OU=<group>,DC=<domain>,DC=<domain></LDAPUserDirectorySubtree>

​  <LDAPGroupName>{AD group name with tacacs users}</LDAPGroupName>

​  <LDAPAccessUserName>{user with domain admin rights}</LDAPAccessUserName>

​  <LDAPAccessUserPassword ClearText=”{password in clear text}” DES=”{password in DES format”></LDAPAccessUserPassword>

​ </UserGroup>

  • To make this configuration to work you need to configure a DES format password. This is just the clear text password in encrypted format. The DES password can created by starting TACDES. This program is in de default tacacs.net installation. Start it by clicking start–>program files–>tacacs.net–>tacdes.
  • Type at the command prompt “tacdes <cleartext password>, copy the outcome in the above configuration at the DES section.
  • Now click save and close the authentication.xml file.
Open up the clients.xml and make sure the configuration looks like below

<ClientGroup Name=”INTERNAL”>

<Secret ClearText=”{tacacs password in cleartext}” DES=”{tacacs password in DES format}”> </Secret>

<Clients>

<Client>{ip address or subnet}</Client>

</Clients>

</ClientGroup>

Now the basic configuration of the tacacs server is done and is fully functional after restarting the tacacs.net service and configuring the switches or routers.
The tacacs.net service can be stopped and started again with the following commands:
start–>run–>cmd–>net stop tacacs.net and net start tacacs.net
On the switch, router or firewall the following lines have to be configured. Before you configure this, make sure you configure a local user and password in case the tacacs server fails. If the tacacs server fails the switch can still be reached with the local credentials.
!
aaa new-model
aaa authentication login default group tacacs local
aaa authentication enable default group tacacs+ enable
aaa accounting commands 0 default start-stop group tacacs+
aaa accounting commands 3 default start-stop group tacacs+
aaa accounting commands 5 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
!
tacacs-server host <ip address tacacs server>
tacacs-server key 0 <tacacs password>
!
!
To check the accounting, login to the tacacs.net server and go to C:\ProgramData\TACACS.net\Logs and open up accounting.txt.
The output will look something like below:

<102> 2012-12-05 14:36:02 [<ip address>:28691] 12/05/2012 14:36:02 NAS_IP=<ip address> Port=tty1 rem_addr=<ip address> User=<user> Flags=TAC_PLUS_ACCT_FLAG_STOP task_id=36 timezone=CET service=shell priv-lvl=15 cmd=show running-config <cr>
<102> 2012-12-05 14:36:14 [<ip address>:22679] 12/05/2012 14:36:14 NAS_IP=<ip address> Port=tty1 rem_addr=<ip address> User=<user> Flags=TAC_PLUS_ACCT_FLAG_STOP task_id=37 timezone=CET service=shell priv-lvl=15 cmd=show running-config <cr>
<102> 2012-12-05 14:36:17 [<ip address>:64422] 12/05/2012 14:36:17 NAS_IP=<ip address> Port=tty1 rem_addr=<ip address> User=<user> Flags=TAC_PLUS_ACCT_FLAG_STOP task_id=38 timezone=CET service=shell priv-lvl=15 cmd=configure terminal <cr>
<102> 2012-12-05 14:36:36 [<ip address>:58260] 12/05/2012 14:36:36 NAS_IP=<ip address> Port=tty1 rem_addr=<ip address> User=<user> Flags=TAC_PLUS_ACCT_FLAG_STOP task_id=39 timezone=CET service=shell priv-lvl=15 cmd=aaa accounting commands 0 default start-stop group tacacs+ <cr>
<102> 2012-12-05 14:36:41 [<ip address>:33050] 12/05/2012 14:36:41 NAS_IP=<ip address> Port=tty1 rem_addr=<ip address> User=<user> Flags=TAC_PLUS_ACCT_FLAG_STOP task_id=40 timezone=CET service=shell priv-lvl=15 cmd=aaa accounting commands 3 default start-stop group tacacs+ <cr>
<102> 2012-12-05 14:36:42 [<ip address>:38303] 12/05/2012 14:36:42 NAS_IP=<ip address> Port=tty1 rem_addr=<ip address> User=<user> Flags=TAC_PLUS_ACCT_FLAG_STOP task_id=41 timezone=CET service=shell priv-lvl=0 cmd=end <cr>