Migrate from spanning-tree redundancy to LACP

Just a small memo of how migrate from spanning-tree redundancy to LACP with the minimum of outage.
If you follow these steps, you will normally not loose the control to your remote switch (or just during the spanning-tree convergence time).

Before the beginning of the migration, we have the following topology:

Start of the migration:

Access switch:
interface Gig 0/2
shut

Core switch:
int port-channel 10
shut
!
default interface Gi0/2
!
interface Gi0/2
channel-group 10 mode active
!
int po 10
switchport mode trunk
switchport trunk allowed vlan all

Core switch:
interface Gi0/2
shut

Access switch:
interface port-channel 1
!
default interface Gig 0/2
!
int Gig 0/2
channel-group 1 mode active
!
int po1
switchport mode trunk
switchport trunk allowed vlan all
no shut

Core switch:
interface port-channel 10
no shut

Access switch:
int Gig 0/1
shut

Core switch:
default int Gi0/1
!
int Gi0/1
switchport mode trunk
switchport trunk allowed vlan all
channel-group 10 mode active

Core switch:
int Gi0/1
shut

Access switch:
default int Gig 0/1
!
int Gig 0/1
switchport mode trunk
switchport trunk allowed vlan all
channel-group 1 mode active

Core switch:
int Gi0/1
no shut

Avoid tromboning effect on extended Datacenter

If we want extend a datacenter between 2 sites, we have to have the same vlan on these 2 sites.
And as a virtual machine can be located on DC A or DC B, we cannot have static path between the client and the server. If we consider the diagram below we are facing a tromboning issue when a User on site B tries to reach a VM located in DC B.
The traffic follows the path:
client in site B -> router on DC B -> VM (vlan directly connected) -> Gateway in DC A -> Router DC B -> client in site B

However the optimal is:
client in site B -> router on DC B -> VM (vlan directly connected) -> Gateway in DC B -> Router DC B -> client in site B

In order to have this path, we have to have 2 actives HSRP routers on the same vlan.

This can obtained by filtering HSRP request between site on the port-channel.
This can easily be done with the following PACL:

ip access-list extended HSRP-FILTER
 10 deny udp any 224.0.0.2 0.0.0.0 eq 1985
 20 deny udp any 224.0.0.102 0.0.0.0 eq 1985
 30 permit ip any any
!
interface port-channel 10
 access-group mode prefer port
 ip access-group HSRP-FILTER in

However, we will have a duplicate IP address and logs messages will be generated.
On a Nexus, we can stop this log with the command below on the bvi:
no ip arp gratuitous hsrp duplicate

In my case, I was using Catalyst to interconnect my DC. 'Gratuitous arp' are the source of my problem! This message are sent by the router to announce their IP and their associated MAC. To filter this message and all ARP coming from the HSRP (other site), you can use the PACL to filter it.
As we know how a MAC is built in HSRP, this ACL filter all arp message coming with an address MAC of a HSRP (v1 and v2) source:

mac access-list extended FILTER-ARP-HSRP
 deny 0000.0c07.ac00 0000.0000.00ff any
 deny 0000.0c9f.f000 0000.0000.0fff any
 permit any any
!
int po 10
 mac access-group FILTER-ARP-HSRP in

Connexion to SSH device with python and paramiko

Previously, I was using 'pexpect' in order to connect and gather information from a router or a switch.
However, I have often encountered several issues (timeout, SSH key gestion...).

It's why, now I'm using 'paramiko' (a python SSH library).
You will find below an example of the paramiko utilisation.
This script connects to a switch and returns it version.
Don't hesitate to share examples.

import paramiko
import time

username = 'user'
pwd = 'password'
cmd = 'show version \n'
ip_switch = '10.10.20.17'
remote_conn_pre=paramiko.SSHClient()
remote_conn_pre
remote_conn_pre.set_missing_host_key_policy(paramiko.AutoAddPolicy())
remote_conn_pre.connect(ip_switch, username=username, password=pwd)
remote_conn = remote_conn_pre.invoke_shell()
time.sleep(1)
trash = remote_conn.recv(5000)
remote_conn.send(cmd)
time.sleep(2)
output = remote_conn.recv(5000)
chain = output.split()
print chain[9]

Windows Automatic Metric for IP routes

I was wondering why sometimes my traffic was going on wireless interface and sometimes on copper interface.
This behavior is due to the automatic Metric feature on windows.
As you can see on the table below if I am connected on a 100Mb, my metric on the copper is 20.


On our site, we have 802.11a/g and 802.11a/g/n access points.

• When I'm on an a/g antenna (max 54Mbps) and a 100Mb copper inteface, I have the following routing table:

C:\Users\ABCD>netstat -rn

IPv4 Route Table
========================================================================
Active Routes:
Network      Destination        Netmask          Gateway       Interface  Metric
0.0.0.0          0.0.0.0        10.1.1.254       10.1.1.32     20
0.0.0.0          0.0.0.0        10.1.2.254       10.1.2.68     25

• When I'm on a a/g/n antenna (and my bandwith is more than 200Mb) and a 100Mb copper inteface, I have the following routing table:

C:\Users\ABCD>netstat -rn
IPv4 Route Table
========================================================================
Active Routes:
Network      Destination        Netmask          Gateway       Interface  Metric
0.0.0.0          0.0.0.0        10.1.2.254       10.1.2.68     10
0.0.0.0          0.0.0.0        10.1.1.254       10.1.1.32     20
As you can see the wireless is preferred with a metric of 10. I have chosen the solution to fix by myself the metric on networks interfaces (copper 1 and wireless 20).

start>control Panel>Network and Sharing Center>Change adpater settings
Right click on the Copper card>Properties>Internet Protocol Version 4>Properties>Advanced
Uncheck 'Automatic metric' and fix the metric

For my case, I'm only using the interface metric. But the result in metric seen with the command 'netstat -rn' is the result of an addition (Gateway metric + InterfaceMetric).
In order to find the gateway metric, you can use the command 'netsh int ip show config':
C:\Users\ABCD>netsh int ip show config

Configuration for interface "Local Area Connection"
    DHCP enabled:                         Yes
    IP Address:                           10.1.1.32
    Subnet Prefix:                        10.1.1.0/24 (mask 255.255.255.0)
    Default Gateway:                      10.1.1.254
    Gateway Metric:                       0
    InterfaceMetric:                      20
    DNS servers configured through DHCP:  10.1.2.5
    Register with which suffix:           Primary only
    WINS servers configured through DHCP: None

Configuration for interface "Wireless Network Connection"
    DHCP enabled:                         Yes
    IP Address:                           10.1.2.68
    Subnet Prefix:                        10.1.2.0/25 (mask 255.255.255.0)
    Default Gateway:                      10.1.2.254
    Gateway Metric:                       0
    InterfaceMetric:                      25
    DNS servers configured through DHCP:  10.1.2.5
    Register with which suffix:           Primary only
    WINS servers configured through DHCP: None

Unable to connect to an 802.11n Wi-Fi network if WMM is disabled

If WMM (Wireless Multimedia Extensions) is disabled on a WLAN, devices are not able to connect on 802.11n.

On a Cisco wireless, it's necessary to enable WMM by SSID:
WLANs>Choose WLAN>QoS>WMM>
Choose 'Allowed'

Configure Network Equipment to use Radius for authentication

Following my recent article on 'How to configure install and configure Freeradius', you will find below several examples of 'How to configure network equipment to use Radius for authentication'.

Cisco Catalyst

aaa new-model
ip radius source-interface vlan XXX
radius-server host <IP_address_radius_server> auth-port <port-number> acct-port <port-number>
radius-server key SharedKey
!
aaa authentication login default group radius local
aaa authorization exec default group radius if-authenticated => directly upgrade privilege to 'enable'
!
line vty 0 15
 login authentication default


Switch HP Procurve

radius-server host <IP_address_radius_server> key " SharedKey " acct-port <port-number> auth-port <port-number>
aaa authentication ssh login radius local
aaa authentication ssh enable radius local
aaa authentication login privilege-mode

Switch Nexus

ip radius source-interface mgmt 0
 radius-server host <IP_address_radius_server> auth-port <port-number> acct-port<port-number>
 radius-server key SharedKey
!
aaa group server radius FREE-RADIUS
 server <IP_address_radius_server>
 use-vrf management
 source-interface mgmt 0
!
aaa authentication login default group FREE-RADIUS

Generate logs messages when a MAC address appears on an interface

Today, I was facing an issue on a client network. After some troubleshooting, I was supposing that a MAC address was duplicated on the network and appears randomly on a physical interface.
But as I didn't would like pass my day to check the mac database of the switch for this specific interface, I have decided to use an EEM script. This EEM script detects new entry in MAC database for the specific interface and generates a log message with an alert level of priority. These levels messages are forwarded by the syslog server to my mailbox! Once I have received the message, I can check manually on the switch which MAC appears on the interface. Below, the script used in order to troubleshoot this issue:

event manager applet MAC-ADD
 event mat interface GigabitEthernet0/24 type add
 action 1.0 syslog priority alerts msg "NEW MAC on ADD Gi0/24"
!
event manager applet MAC-DEL
 event mat interface GigabitEthernet0/24 type delete
 action 1.0 syslog priority alerts msg "MAC DELETED on Gi0/24"