Wednesday, November 19, 2014

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'

Friday, October 24, 2014

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

Thursday, October 23, 2014

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"

Cisco and Freeradius configuration

 Installation description

    In our case, the Freeradius aims to authenticate a remote access on network equipment. I have decided to use an existing database (Active directory).

    FreeRadius paquets installations:
    apt-get install freeradius
    apt-get install freeradius-utils
    apt-get install freeradius-ldap


    Configure the radiusd.conf file

    Modify the file radiusd.conf (/etc/freeradius/radiusd.conf) in order to specify the listen ports:
    -          Authentification (2050)
    -          Accounting (2051)

     listen {
            type = auth
            ipaddr = *       
           port = 2050
    }
    listen {
            ipaddr = *
            port = 2051
            type = acct
    }
           auth = yes

     Uncomment the following lines in order to have more details in logs messages:
            msg_goodpass = "Host %n"
            msg_badpass = "Host %n"

    Configure the Users file

    Modify the file users (/etc/freeradius/users) .

    This file includes users which are authorized to take control on 'client' (network equipment for us).
    - We can use a local database:
    Username Cleartext-Password := "Password"
           Service-Type = NAS-Prompt-User,
           Cisco-AVPair = "shell:priv-lvl=15"

    - Or an external database. In this example, only members of groups 'Group_Network_Admin' (Active Directory) are authorized to access:
    DEFAULT         LDAP-Group == "Group_Network_Admin"
                    Service-Type = Administrative-User,
                    Cisco-AVPair = "shell:priv-lvl=15"
    DEFAULT    LDAP-Group != "Group_Network_Admin", Auth-Type := Reject


    Enable authentication via LDAP:

    Modify the file ldap (/etc/freeradius/sites-enabled/ default) by uncommenting the following lines :
    ldap
            Auth-Type LDAP {
                    ldap
            }

    Create clients of the radius server

    Modify the file users (/etc/freeradius/users). Clients are hosts which forward request of authentication to the radius server (ex: Cisco switch).
    In the example below, I have added a complete subnet. All hosts in this subnet are authorized to send request.
    We also defined the share key in this file:

    client 10.110.22.0/24 {
            secret          = SharedKey
            nastype         = cisco
            shortname       = SWITCH-Branch-London
    }


    Configure request to Active Directory

    Modify the file ldap (/etc/freeradius/modules/ldap). You will find below an example of configuration :
    ldap {
            server = 'ldap://mydomain.com'
            identity = "Username@mydomain.com"
            password = "Password"
            basedn = "DC=mydomain,DC=com"
            filter = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})"
      
           groupname_attribute = cn
           groupmembership_attribute = "memberOf"
    Uncomment the following lines:
           chase_referrals = yes
            rebind = yes

    Monday, October 13, 2014

    Command Line Tricks for HP Procurve Switchs

    Below some helpful commands.

    • Display logs or debug on current session:
      • terminal monitor (Cisco)
      • debug destination session (HP Procurve)
    • By default HP Procurve switch don't display packets drops by queue. You can enable the monitoring only on 1 interface with the command below:
      • qos watch-queue xx out (where XX is the interface you want to monitor)
    • Obtain 'show tech':
      • copy command-output "show tech all" sftp user ftpuser 10.10.10.10 show-tech.txt
    • Filter a 'show runnning' command:
      • Like Cisco, it's possible to use '|' after the 'show running'
    Switch# show running-config | include router
    ip router-id 1.1.1.1
    router ospf
    router vrrp

    Switch# show running-config | begin router
    ip router-id 1.1.3.1


    Wednesday, September 3, 2014

    Play with MACSEC on copper interface with 3750X

    The Cisco documentation is not clear on the switch-to-switch (via copper) macsec feasibility.
    Also, I have decided to test it between two 3750x:

    • 3750X-24TS (without service module)
    • 3750X-48TS (without service module)


    I have applied the following configuration on each switch:


    I have plugged the cable between this 2 switchs and checked that SAP 'succeeded':

    Interface is up and configuration looks fine. But I have prefer checked by myself that the traffic is well encrypted. The best way to do this is to use a hub. But this equipment has disappeared from IT services and is very rare!! Also we have designed our own RJ45 TAP:).

    I have used this magic TAP and wireshark to sniff the traffic between our both switchs.
    Below, you can see the result of a packet when it's encrypted by MACSEC (802.1ae). We can see the Ethertype (88e5) used by this protocol.

    To resume, MACSEC is available on Cisco Switch (switch-to-switch) on copper interface without Service Module. This configuration is not available on 3560X. I guess, the service module is mandatory for it.