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.
Friday, December 11, 2015
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:
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.
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.
hostname,devtype=procurvehpv2, arp
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
- 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'
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
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
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)
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
ip multicast-routing
ip pim rp-address 10.10.30.1
!
description *** TO HP1 ***
ip address 10.10.10.1 255.255.255.0
ip pim sparse-mode
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
- 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 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/1description *** TO Cisco2 ***
ip address 10.10.20.1 255.255.255.0
ip pim sparse-mode
!
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 pim neighbor
PIM Neighbors
IP Address VLAN Up Time (sec) Expire Time (sec)
--------------- ---- ------------------ ------------------
10.10.10.1 316 2305990 103
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.
interface Port-channel20
description TO-HP-DT
switchport
switchport mode trunk
switch-interconnect trk10
vlan xxx
tagged trk10
vlan xxx
tagged trk10
...
name "Keep-Alive"
exit
switch-interconnect trk10
vlan xxx
tagged trk10
vlan xxx
tagged trk10
...
name "Keep-Alive"
exit
Some remarks:
- ISC is only supported in MST 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
vlan xxx
tagged trk10
vlan xxx
tagged trk10
...
- Configure the keepalive
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
vlan xxx
tagged trk10
vlan xxx
tagged trk10
...
- Configure the keepalive
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
- ISC is only supported in MST mode
Wednesday, May 20, 2015
Tuesday, May 5, 2015
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
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:
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
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
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
Subscribe to:
Posts (Atom)