Cisco Live 2012

March 20th, 2012 No comments

It’s the first day of spring and NetVet session registration is open for Cisco Live 2012 in the US.

Here is my schedule:


Monday
BRKSEC-2202 Understanding and Preventing Layer 2 Attacks in IPv4 Networks
BRKSPG-2209 Designing Access Network With the ME3600X and ME3800X
BRKARC-3445 Cisco Catalyst 4500E Switch Architecture

Tuesday
BRKMPL-2101 Deploying MPLS-based Layer 2 Virtual Private Networks
GENKEY-4346 Keynote and Welcome Address
BRKRST-2331 The Care and Feeding of EIGRP Networks
BRKSPG-2204 Building Carrier Ethernet Services Using Cisco Ethernet Virtual Circuit Framework

Wednesday
BRKOPT-2117 Emerging Technologies for WAN Interconnections in Packet Networks
GENKEY-4347 Cisco Technology Keynote
BRKSPG-2207 Redundancy Mechanisms for Carrier Ethernet and Layer 2 VPN Services
BRKCRS-3143 Troubleshooting Cisco Catalyst 6500 Series Switches

Thursday
BRKARC-3002 Cisco CRS Carrier Routing System Multichassis Overview
BRKNMS-1035 The NOC at CiscoLive


Install mpt-status on XenServer

October 14th, 2011 No comments

I have a XenServer with an LSI MPT Fusion RAID controller. The only way to check the status of the RAID mirror from within the XenServer is to grep dmesg for lines containing “mptbase” and reading through them. Here is a sample output of said file:

[root@xenserver-01 ~]# grep mptbase /var/log/dmesg
mptbase: ioc0: 32 BIT PCI BUS DMA ADDRESSING SUPPORTED, total memory = 777148 kB
mptbase: ioc0: Initiating bringup
mptbase: ioc0: RAID STATUS CHANGE for VolumeID 0
mptbase: ioc0:   volume is now optimal, enabled, quiesced
mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 0 id=0
mptbase: ioc0:   PhysDisk is now online, quiesced
mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=0
mptbase: ioc0:   PhysDisk is now online, quiesced
mptbase: ioc0: RAID STATUS CHANGE for VolumeID 0
mptbase: ioc0:   volume is now optimal, enabled
mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 0 id=0
mptbase: ioc0:   PhysDisk is now online
mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=0
mptbase: ioc0:   PhysDisk is now online
mptbase: ioc0: RAID STATUS CHANGE for VolumeID 0
mptbase: ioc0:   volume is now optimal, enabled, quiesced
mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 0 id=0
mptbase: ioc0:   PhysDisk is now online, quiesced
mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=0
mptbase: ioc0:   PhysDisk is now online, quiesced
mptbase: ioc0: RAID STATUS CHANGE for VolumeID 0
mptbase: ioc0:   volume is now optimal, enabled
mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 0 id=0
mptbase: ioc0:   PhysDisk is now online
mptbase: ioc0: RAID STATUS CHANGE for PhysDisk 1 id=0
mptbase: ioc0:   PhysDisk is now online

You can no doubt see how this is a less than optimal (no pun intended) way to check on the status of the mirror. This is where ‘mpt-status’ comes into play.

In order to get it working there are a few things that need to be done. First you will need to install the rpm for ‘mpt-status‘. It can be obtained from “http://www.drugphish.ch/~ratz/mpt-status/RPMS/1.2.0_RC7/” (mirrored here) or you can download the src and build your own RPM. After you have the rpm in your home directory, you can install it.

[root@xenserver-01 ~]# rpm -Uhv mpt-status-1.2.0_RC7-3.i386.rpm
Preparing...                ########################################### [100%]
   1:mpt-status             ########################################### [100%]
[root@xenserver-01 ~]#

The first time you try to run it, you will probably see the following output:

[root@xenserver-01 ~]# mpt-status
open /dev/mptctl: No such file or directory
  Try: mknod /dev/mptctl c 10 220
Make sure mptctl is loaded into the kernel

As the output suggests, you will need to create the device and load mptctl into the kernel.

[root@xenserver-01 ~]# mknod /dev/mptctl c 10 220
[root@xenserver-01 ~]# modprobe mptctl

Now, you can sucessfully run the ‘mpt-status’ command:

[root@xenserver-01 ~]# mpt-status
ioc0 vol_id 0 type IM, 2 phy, 66 GB, state OPTIMAL, flags ENABLED
ioc0 phy 0 scsi_id 0 SEAGATE  ST373207LC       0002, 68 GB, state ONLINE, flags NONE
ioc0 phy 1 scsi_id 1 SEAGATE  ST373207LC       0002, 68 GB, state ONLINE, flags NONE

The last thing we need to do is make sure the module is loaded upon subsequent reboots. For this we create the /etc/rc.modules file:

[root@xenserver-01 etc]# echo modprobe mptctl >> /etc/rc.modules
[root@xenserver-01 etc]# chmod +x /etc/rc.modules

You can reboot the server and run ‘mpt-status’ again to verify that the module was loaded properly.

DC-4-FILE_OPEN_WARNING

October 12th, 2011 2 comments

I recently upgraded several 2960 series switches to the 15.0 IOS train. 15.0(1)SE, to be exact. Upon boot up I noticed the following entries in the log that weren’t previously there:

*Mar  1 00:00:39.535: %DC-4-FILE_OPEN_WARNING: Not able to open flash:/dc_profile_dir/dc_default_profiles.txt
*Mar  1 00:00:39.535: %DC-6-DEFAULT_INIT_INFO: Default Profiles DB not loaded.

I have also seen those messages on a 3750E.

Searching Google for all or a portion of those 2 messages yielded no results. I also checked the release notes, the bug toolkit and posted to several forums and mailing lists.

There is no definitive information that I can find but it appears that it is just cosmetic and nothing to be concerned about.

I’m still curious as to what this “dc profile” is for…

Categories: Cisco, Networking Tags: , , , , ,

Using Pseudowire and L2tpv3

August 25th, 2011 1 comment

Do you have multiple locations and the want to tunnel layer2 over your IP network via a virtual wire to combine broadcast domains? You are in luck, this can be done utilizing something called Pseudowires and L2tpv3 (Layer 2 Tunneling Protocol Version 3). First, let me explain each of the 2 technologies used here:

- A Pseudowire is a virtual connection using an emulated “wire” that is carried over your IP network. This can be from router to router over a WAN connection or between routers inside your campus or between switches.
- L2tpv3 is the tunneling protocol used to encapsulate the layer 2 frames that will be sent over the Pseudowire.

Have a look at the following sample topology:

You will see that we have 2 sites, connected by a WAN link (a T1, in this example) using Cisco 3745 routers running 12.4(15)T14. At each location, you will see a switch for LAN connectivity. What we will accomplish here is not that dissimilar from what was covered in the article I wrote about “L2protocol and Dot1Q Tunneling.” This, however, is much more robust and will offer much more flexibility.

To start off, we have S0/0 on each router as a WAN connection, already configured.

R1:

interface Serial0/0
 ip address 10.0.0.1 255.255.255.252
 service-module t1 clock source internal
 service-module t1 timeslots 1-24

R2:

interface Serial0/0
 ip address 10.0.0.2 255.255.255.252
 service-module t1 timeslots 1-24

The first thing to do is configure the Loopback interface on each router. This will be the address to which the Pseudowire will terminate. How you route these addresses to the other router(s) is up to you. In this simple example, we will just use a static route, but as more sites are added, you can use the routing protocol of your choice. This is just a proof of concept.

R1:

interface Loopback0
 ip address 192.168.200.1 255.255.255.255

R2

interface Loopback0
 ip address 192.168.200.2 255.255.255.255

Next, we will configure the Pseudowire Class. Here is where we will specify the origin of the Pseudowire as well as the encapsulation to be used. In each case, it is lo0 and l2tpv3.

R1:

pseudowire-class CLASS1
 encapsulation l2tpv3
 ip local interface Loopback0

R2

pseudowire-class CLASS1
 encapsulation l2tpv3
 ip local interface Loopback0

They look the same, right?

Now we will configure the LAN facing interface at each site as the endpoint of the pseudowire using the ‘xconnect’ command to specify the remote endpoint, ie, the lo0 interface of the far router. We also give it a VC (Virtual Circuit) ID, in this example, I used 1.

R1:

interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 xconnect 192.168.200.2 1 encapsulation l2tpv3 pw-class CLASS1

R2:

interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 xconnect 192.168.200.1 1 encapsulation l2tpv3 pw-class CLASS1

To verify the status of the Pseudowire, use the command ‘show xconnect all’

R1:

R1#show xconnect all
Legend: XC ST=Xconnect State, S1=Segment1 State, S2=Segment2 State
UP=Up, DN=Down, AD=Admin Down, IA=Inactive, NH=No Hardware
XC ST  Segment 1                         S1 Segment 2                         S2
------+---------------------------------+--+---------------------------------+--
UP     ac   Fa0/0(Ethernet)              UP l2tp 192.168.200.2:1              UP

R2

R2#show xconnect all
Legend: XC ST=Xconnect State, S1=Segment1 State, S2=Segment2 State
UP=Up, DN=Down, AD=Admin Down, IA=Inactive, NH=No Hardware
XC ST  Segment 1                         S1 Segment 2                         S2
------+---------------------------------+--+---------------------------------+--
UP     ac   Fa0/0(Ethernet)              UP l2tp 192.168.200.1:1              UP

You will see that the Pseudowire is “UP” and you have sucessfully created the cross connect between the 2 Fa0/0 interfaces at each site.

You can verify that the switches have formed a trunk to each other. As you can see, S1 (VLAN100: 192.168.100.1/24) and S2 (VLAN100: 192.168.100.2/24) can ping each other as well:

S1:

S1#show int trunk

Port        Mode         Encapsulation  Status        Native vlan
Fa0/1       on           802.1q         trunking      1

Port      Vlans allowed on trunk
Fa0/1       1-4094

Port        Vlans allowed and active in management domain
Fa0/1       1,100

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/1       1,100
S1#
S1#ping 192.168.100.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

S2:

S2#show int trunk

Port        Mode         Encapsulation  Status        Native vlan
Fa0/1       on           802.1q         trunking      1

Port      Vlans allowed on trunk
Fa0/1       1-4094

Port        Vlans allowed and active in management domain
Fa0/1       1,100

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/1       1,100
S2#
S2#ping 192.168.100.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

As far as clients at each location are concerned, they are on the same subnet. It is as if you ran a physical cable between the 2 switches. Your next step would be to upgrade that T1 to something with a little more throughput (think Metro Ethernet) and probably implement QoS. You can also add more sites and more Pseudowires should you wish. Just be mindful of your WAN connections and the capabilities of your platforms.

I hope you found this both informative and fun.

Prevent VLAN Hopping Attacks

August 20th, 2011 No comments

I wanted to elaborate on an item from a brief article I did a while back about “Access Switch Best Practices

At the time, I wrote that article as a quick reference for best practices, but did not go into much detail. I would like to elaborate on item #5 where I recomend using an unused VLAN ID as the native VLAN for all trunk ports. The reason for this is to help mitigate VLAN hopping attacks whereby someone could double tag a frame before it enters the switch. Once there, the switch will strip off the outside tag and pass the frame along, but it will still have that secondary VLAN tag applied. As such, that still tagged frame will be placed into that second VLAN.

The key for this to work is that the attacking station needs to be in the same VLAN as the native VLAN of the trunk. Switches use VLAN 1 for this by default so it is important to change this.

For example, take a look at the following diagram:

1. The attacking station sends a double tagged frame to Switch 1.
2. Switch 1 will strip off the outer tag (VLAN1) and place it on the trunk which has the native VLAN of 1 by default.
3. Because the frame is in the native VLAN of the trunk, no tag is applied by the switch and it just forwards the frame untouched.
4. The next switch sees the frame with a tag of VLAN2 and places it in said VLAN.
5. Process is complete.

So, how can this be prevented?
- The best way to prevent this from happening is to assign an unused VLAN ID as the native VLAN of trunk ports, and make sure it is not VLAN 1. This way there is no chance of a workstation ending up on the native VLAN of your trunk to perform this attack.
- You could also use the global config command, if supported, of ‘vlan dot1q tag native’. When it is enabled, the switch will always tag frames in the native VLAN before sending them over a trunk. If that were enabled, Switch 1 in the previous example would have applied a tag of VLAN 1 to the frame before sending it over the trunk to Switch 2 where it would have seen that tag, stripped it off and placed it in VLAN 1, not VLAN 2.