Configure Distributed Trunking on HP Procurve and MEC on Cisco VSS

Distributed Trunking is the 'equivalent' of the vPC on the Cisco Nexus Series. It's a link aggregation technique which can be used even if the host is connected on 2 differents switchs. The following design has been built between 2 HP 5400 and 2 Cisco 4500 in VSS mode.

• Configuration on the Cisco Switch:

interface Port-channel20
 description TO-HP-DT
 switchport
 switchport mode trunk

!

interface TenGigabitEthernet1/5/4

 description TO-HP-DT-1

 switchport mode trunk

 channel-group 20 mode active

!

interface TenGigabitEthernet2/5/4

 description TO-HP-DT-2

 switchport mode trunk

 channel-group 20 mode active

• Configuration of the HP 1:
• Configure ISC

trunk B7,E8 trk10 lacp

switch-interconnect trk10
vlan xxx
 tagged trk10
vlan xxx
 tagged trk10
...

• Configure the keepalive 

interface D20
   name "Keep-Alive"
   exit

vlan 900

   name "VLAN900"

   untagged D20

   ip address 192.168.100.1 255.255.255.0

   exit

distributed-trunking peer-keepalive vlan 900

distributed-trunking peer-keepalive destination 192.168.100.2

• Configure the dt-lacp between the VSS and the HP:

trunk A1,B1 trk1 dt-lacp

• Configuration of the HP 2:
• Configure ISC

trunk B7,E8 trk10 lacp

switch-interconnect trk10
vlan xxx
 tagged trk10
vlan xxx
 tagged trk10
...

• Configure the keepalive 

interface D20
   name "Keep-Alive"
   exit

vlan 900

   name "VLAN900"

   untagged D20

   ip address 192.168.100.2 255.255.255.0

   exit

distributed-trunking peer-keepalive vlan 900

distributed-trunking peer-keepalive destination 192.168.100.1

• Configure the dt-lacp between the VSS and the HP:

trunk A1,B1 trk1 dt-lacp

• Validation:

HP-1# show switch-interconnect

Port         : Trk10

Status       : Up

Active VLANs : 1,100,200,300

HP-1# show distributed-trunking statistics peer-keepalive

DT peer-keepalive Status : Up

HP-1# show  distributed-trunking consistency-parameters trunk trk1

Allowed VLANs on Local : 1,100,200,300

Allowed VLANs on Peer  : 1,100,200,300

HP-1# show  lacp distributed

                             Distributed LACP

Local Port Status:

       LACP    Trunk   Port            LACP    Admin  Oper

  Port Enabled Group   Status  Partner Status  Key    Key

  ---- ------- ------- ------- ------- ------- ------ ------

  A1   Active  Trk1    Up      Yes     Success 0      290

Remote Port Status:

          LACP      Trunk     Port                LACP      Oper

   Port   Enabled   Group     Status    Partner   Status    Key

   ----   -------   -------   -------   -------   -------   ------

   A1     Active    Trk1      Up        Yes       Success   20

C4510-VSS-Core#show  lacp 20 neighbor

Partner's information:

                  LACP port                        Admin  Oper   Port    Port

Port      Flags   Priority  Dev ID          Age    key    Key    Number  State

Te1/5/4   SA      0         40a8.f07b.a400   2s    0x0    0x0    0x271F  0x3D

Te2/5/4   SA      0         40a8.f07b.a400   4s    0x0    0x0    0x271A  0x3D

Some remarks:
- ISC is only supported in MST mode

IPsec Overhead Calculator from Cisco

https://cway.cisco.com/tools/ipsec-overhead-calc/ipsec-overhead-calc.html

Graphical view of Auto Qos on Cisco 4k5

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