Friday, December 11, 2015

Capture traffic on Cisco switch with EPC (both directions)

Embedded Packet Capture is a powerful tool implemented on certain Cisco devices. With this technology, it's no more mandatory to SPAN traffic in order to capture it. You can capture traffic at differents points of your network with some limitations described in the Cisco documentation.
In my case, I would like capture traffic between 2 machines (only these 2 machines) has described in diagram below:

In order to do this, you can use the following configuration:
ip access-list extended HOST-TO-FILTER
 permit ip host 10.10.10.1 host 10.10.20.1
 permit ip host 10.10.20.1.1 10.10.10.1
!
monitor capture MY-CAPTURE file location flash:mycapture.pcap  size 10 int GigabitEthernet1/0/1 both access-list HOST-TO-FILTER

After that, you can start the capture with the command:
monitor capture MY-CAPTURE start

And stop it:
monitor capture MY-CAPTURE stop


This capture can be export and read with wireshark for example.
!! Warning!!
EPC can consumes CPU and memory. Take care to apply a good filter in order to not overload your router or switch.

Thursday, December 10, 2015

OSPF - Filter redistribution in a Totally NSSA area

In some cases, we can have the ABR which can also be an ASBR. If we are working with a Totally NSSA area we have unnecessary routes. ABR announces a default route and his redistributed routes which are not necessary. In order to solve this case and only announce a default route, we can use the commande below on the ABR:

 area X nssa no-redistribution no-summary

The schema below is anexample of this implementation:



Thursday, November 5, 2015

BGP Route Reflector - Routing advertisements rules

In order to avoid a looping route, the route reflector follows the 3 rules below:

1/ routes learned from an eBGP peers can be announced to eBGP peers, clients and non-clients.

2/ routes learned from a client can be announced to eBGP peers, others clients and non-clients.

3/ routes learned from a non-client can be announced to eBGP peers, clients and they cannot be sent to a non-clients.

Wednesday, November 4, 2015

Track an IP on your Network

Who has never received the following question from a colleague:
- Hey, the network guy, could you find where is this laptop for me ? I have only his IP address.

To resolve this, you start to follow the IP address by looking in the arp and mac-address table of your switchs, routers and firewall. I have finished this boring job by using the following open source tool:
http://netdbtracking.sourceforge.net/

Developpers have alreay preconfigured a VM:
http://sourceforge.net/projects/netdbtracking/files/vmware/

After 30 minutes of the VM installation and some hours (depending of the size of your network) of configuration to enter your different equipment, you can provide a webtools reachable from everybody to track an IP.

You will find below some examples of host configuration.


  • HP Procurve (Layer 3)

hostname,devtype=procurvehpv2, arp


  • HP Procurve (Layer 2):

On this example, I skipped uplinks interfaces (45 and 47). I have also limited to 2 mac address by interface.
hostname,devtype=procurvehpv2,skip_port=45,skip_port=47,use_trunks,max_macs=2

Monday, July 27, 2015

Windows: find the MTU for a specific IP

The following command, give us the MTU for a specific destination:
U:\>netsh interface ipv4 show destinationcache address='IP_addresss'

  • Example on a classic LAN:

U:\>netsh interface ipv4 show destinationcache address=192.168.95.216
Destination              : 192.168.95.216
Next Hop Address         : 192.168.211.254
Source                   : 192.168.211.1
Interface                : Local Area Connection
Path MTU                 : 1500
Upper-layer MTU          : 1480
RTT mean                 : 3000
RTT deviation            : 0
Path transmit speed (Bps): 0
Path receive speed (Bps) : 0
Link transmit Speed (bps): 1000000000
Link receive Speed (bps) : 1000000000


  • Example with an IPsec Tunnel:


U:\>netsh interface ipv4 show destinationcache address=192.168.95.216
Destination              : 192.168.95.216
Next Hop Address         : 192.168.95.216
Source                   : 192.168.243.197
Interface                : Local Area Connection
Path MTU                 : 1400
Upper-layer MTU          : 1380
RTT mean                 : 40
RTT deviation            : 20
Path transmit speed (Bps): 0
Path receive speed (Bps) : 0
Link transmit Speed (bps): 2000000000
Link receive Speed (bps) : 2000000000

Tuesday, July 7, 2015

Configure PIM-sparse mode between Cisco and HP Procurve

This post explains how to configure PIM-sparse mode between a Cisco and HP Procurve environment. In our case, we have the following components:
- Cisco2 (Rendez-vous Point)
- Cisco1 (PIM router)
- HP1 (PIM router and IGMP edge router)




  • Configuration

    • Cisco2 (RP):


ip multicast-routing
ip pim rp-address 10.10.30.1 (we can filter group here with an ACL)
!
interface Gi1/0/1
 description *** TO Cisco1 ***
 ip address 10.10.20.2 255.255.255.0
 ip pim sparse-mode
!
interface Vlan100
 description *** VLAN Source ***
 ip address 10.10.30.1 255.255.255.0
 ip pim sparse-mode

    • Cisco1:

ip multicast-routing
ip pim rp-address 10.10.30.1    
!
interface Gi1/0/1
 description *** TO Cisco2 ***
 ip address 10.10.20.1 255.255.255.0
 ip pim sparse-mode
!
interface Gi1/0/1
 description *** TO HP1 ***
 ip address 10.10.10.1 255.255.255.0
 ip pim sparse-mode

    • HP1:


ip multicast-routing
!
router pim
   enable
   rp-address 10.10.30.1 224.0.0.0 240.0.0.0 (we can filter group here)
   exit
!
vlan 316
   name "To Cisco1"
   untagged A1
   ip address 10.10.10.2 255.255.255.0
   ip pim-sparse
      ip-addr any
      exit
!
vlan 200
   name "200-RECEIVER"
   untagged A1
   tagged A13-A15,B20,Trk1
   ip address 10.10.40.1 255.255.255.0
   ip igmp
   ip pim-sparse
      ip-addr any
      exit

  • Validation

Check PIM neighbors adjacency on HP:

HP1# sho ip pim neighbor

 PIM Neighbors

  IP Address      VLAN Up Time (sec)      Expire Time (sec)
  --------------- ---- ------------------ ------------------
  10.10.10.1      316  2305990            103


The receiver is requesting traffic from the source (IGMP membership report):

HP1# sho ip igmp vlan 200

 IGMP Service Protocol Info

  Total VLANs with IGMP enabled                : 7
  Current count of multicast groups joined     : 1

  IGMP Filter Unknown Multicast: Disabled
  IGMP Filter Unknown Multicast Status: Disabled

  VLAN ID : 200
  VLAN Name : 200-RECEIVER
  IGMP version : 2
  Querier Address [this switch] : 10.10.40.1
  Querier Port :
  Querier UpTime : 129d 3h 48m 43s
  Querier Expiration Time : 0h 0m 58s

  Active Group Addresses Type       Expires         Ports      Reports Queries
  ---------------------- ---------- --------------- ---------- ------- -------
  239.1.1.1              Filter     0h 4m 19s       A1         3       0

HP1# sho ip igmp groups

 IGMP Group Address Information

  VLAN ID Group Address   Expires       UpTime        Last Reporter   | Type
  ------- --------------- ------------- ------------- --------------- + ------
  200     239.1.1.1       0h 3m 27s     0h 2m 4s      10.10.40.2    | Filter

Check mroute on HP and Cisco:

HP1# sho ip pim mroute

 IP Multicast Route Entries

  Total number of entries : 1

  Group Address   Source Address  Neighbor        VLAN
  --------------- --------------- --------------- ----
  239.1.1.1       10.10.30.2      10.10.10.1      316


Cisco2#show  ip mroute
IP Multicast Routing Table
...

(*, 239.1.1.1), 00:02:43/00:02:46, RP 10.10.30.1, flags: S
  Incoming interface: GigaEthernet1/0/2, RPF nbr 10.10.20.2
  Outgoing interface list:
    GigaEthernet1/0/1, Forward/Sparse, 00:02:43/00:02:46

(10.10.30.1, 239.1.1.1), 00:02:43/00:00:16, flags: T
  Incoming interface: GigaEthernet1/0/2, RPF nbr 10.10.20.2
  Outgoing interface list:
    Port-channel3, Forward/Sparse, 00:02:43/00:02:46



Monday, July 6, 2015

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

Monday, March 9, 2015

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

Wednesday, January 14, 2015

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