How correct network cabling should look like!

Network cabling in a data centre should not look like in the following picture ūüėČ there you have no¬†structure¬†and makes it difficult for someone else to look through how every server is connected.

To make your life and work easier you just need to think before about what colors you use and then create an cabling standard what you always follow. Basically I choose three colors: blue, red and yellow. Yellow is management traffic, blue and red are main network connections (ports on the server must be teamed to have a redundant connectivity).

Here you clearly see that every server has an redundant connection to one of the switches in the rack. The blue cables are always connected to the top switch in the rack and the red to the second switch.

Here how the complete rack looks like, always look to keep it organised and follow your cabling standard.

 

Cisco IP SLA Configuration

Not everyone knows how powerful the Cisco IP SLA feature is and here an short example what you can do with it.

At first you need to create the monitor in my case I just want to do basic ICMP testings to a specific IP address, you can of course also create other IP SLA operations in the end it just depends for what you need the IP SLA feature.

ip sla monitor 1
 type echo protocol ipIcmpEcho 192.168.1.2 source-interface FastEthernet1/0
 timeout 300
 frequency 3

Then you need to start the IP SLA monitor

ip sla monitor schedule 1 life forever start-time now

With the show command you can look if the tests are successful and then continue with the next step

show ip sla monitor statistics

Here you create the track definition

track 1 rtr 1 reachability

In the end you just need to add the track condition, in my example an static default route

ip route 0.0.0.0 0.0.0.0 192.168.0.2 track 1

When the IP 192.168.1.2 is reachable the static route is within the routing table of the Cisco router, when the IP is unreachable IP SLA deletes the static route from the routing table. I mostly use IP SLA to failover to an back-up internet connection because its very easy to configure.

More information you can find in the Cisco IOS IP SLAs Configuration Guide

GNS3 Network Simulator

Found something really cool today ūüôā

GNS3 is a graphical network simulator where you can set-up complex virtual networks and run Cisco and Juniper routers or switches. The best is that you can also integrate Qemu and Virtualbox into your virtual lab environment what I really love. You can easily test new configurations on devices without having to set-up all these in hardware.

The only little problem is that you need a quite power system¬†to do all of that. Otherwise I tested GNS3 on an 3 year old laptop with Intel Core2Duo and 4 GB RAM and run up to 6 Cisco routers without any big problems what’s enough for me at the moment.

Ah I forgot, you can of course also use Wireshark to capture packets on an link between two devices.

Here the link to the website: www.gns3.net

Cisco Catalyst static CAM table entries

That’s maybe not interesting for everybody but when you use Windows Network¬†Load Balancing in your network you should¬†definitively¬†configure static CAM table entries otherwise your VLAN will be flood with multicast traffic. You can create different VLANs for your Windows NLB instances to separate the traffic but that’s more an work around and with static CAM entries nicer from the design.

The static CAM table entries just restrict the multicast traffic to specific ports on your switch where your Servers are located and keep otherwise the network free.

On your router you will have an entry like that:

arp 10.0.0.100 0300.5e11.1111

An static ARP entry with an multicast MAC address

Now to restrict the multicast traffic you use the following command:

mac-address-table static 0300.5e11.1111 vlan 100 interface gi0/10 gi0/11

Which just means that the multicast traffic for VLAN 100 will be flood through the interfaces Gi0/10 and Gi0/11 and all other interfaces will not see the multicast traffic. Its a bit an administrative overhead and you have to think a little bit about that before you can implement but an clean traffic flow within your network.

If you want to read more about it have a look here: Catalyst Switches for Microsoft Network Load Balancing Configuration Example

Bug in Cisco ASA 8.4(4)1 found

I had a new office set-up in Sao Paulo/Brazil and found a bug what should be already fixed but still exists. You cannot access the management interface (inside) of your ASA when you come over an L2L/RemoteAccess VPN and your NAT statements overlaps the management ip address.

It’s an split-tunneling configuration where VPN traffic keeps the original IP address and when you go into the internet you will translated to the outside IP address. Have a look here at the cisco bug¬†CSCtr16184

I used the following config what didn’t work:

nat (inside,outside) source static inside-subs inside-subs destination static vpn-subs vpn-subs

When you use the NAT statements described in the workaround it works fine:

nat (inside,outside) source static inside-subs inside-subs destination static vpn-subs vpn-subs route-lookup
nat (outside,inside) source static vpn-subs vpn-subs destination static inside-subs inside-subs route-lookup

This behavior should be already fixed in version 8.4(2.3) but in my 8.4(4)1 it still exists.

Here the bug details from Cisco:

To-the-box traffic fails from hosts over vpn after upgrade to 8.4.2.

Symptom:

After upgrading the ASA to 8.4.2, all management traffic to-the-box(including icmp/telnet/ssh/ASDM) from hosts over the VPN (L2L or Remote ACcess VPN) may fail when destined to the management-access interface IP address.

Conditions:

1. Issue is observed if ASA is on 8.4.2. Not observed on 8.4.1.
2. Users directly connected to the internal interfaces face no issues with icmp/telnet/ssh/asdm to their respective interfaces.

Workaround:

The problem can be traced to a Manual NAT statement that overlaps with the management-access interface IP address. The NAT statement must have both the source and destination fields. Adding the “route-lookup” keyword at the end of the NAT statement resolves the issue.