GRE over IPsec tunnels (Part 1)

Why a IPsec over a GRE tunnel? A couple of things come to mind. Things like encryption of tunneled traffic and the possibility to send multicast traffic over the tunnel.

GRE on itself only tunnels traffic by encsapsulating the traffic within an additional GRE and IP header. But if you Wireshark the traffic it’s just plain text and therefore readable. In a plain IPsec tunnel it is not possible to send multicast traffic over the IPsec tunnel. But if you’re using OSPF or EIGRP you need to be able to send multicast traffic over the IPsec tunnel.

To prove the above I created a case study. First I will show how to configure a normal GRE tunnel, after that a GRE over IPsec tunnel with static routes. In a separate post I will write about GRE over IPsec tunnel with dynamic routing.

So for this case study I used the topology as shown below.

GRE_over_IPsec

Below the configuration of the HQ router, the branch router is the same but use different IP addresses.

First configure the physical internet facing interface, the vlan interface for the internal subnet and the needed routes.

!
interface FastEthernet1/0
ip address 109.232.100.1 255.255.255.0
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.10.10.1 255.255.255.0
!
ip route 10.10.11.0 255.255.255.0 172.18.2.1
!

Then create the tunnel interface

!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
ip mtu 1400
tunnel source FastEthernet1/0
tunnel destination 109.232.100.2
!
Don’t forget to change the MTU size to 1400, because of the overhead created by the GRE encapsulation.

Now it’s possible to ping from PC1 at HQ to PC3 at the bracnch office. If you look at the traffic you will see it’s encapsulated in a GRE packet, but there is no encryption:
GRE_capture

To create an IPsec connection do the following on the HQ and Branch routers:
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key sjiekismiechdat address 109.232.100.2
!
!
crypto ipsec transform-set test esp-3des esp-md5-hmac
!
!
access-list 101 permit gre host 109.232.100.1 host 109.232.100.2
!
!
crypto map s-2-s 10 ipsec-isakmp
set peer 109.232.100.2
set transform-set test
match address 101
!
!
interface Tunnel0
crypto map s-2-s
!
!
interface FastEthernet1/0
crypto map s-2-s
!

Now send some traffic from PC1 to PC3 and use the “show crypto session” command to verify that the GRE over IPsec connection is established:
crypto_session

Now we know the tunnel is up and it’s possible to exchange traffic between PC1 at the HQ and PC3 at the branch office. Now let’s look at the traffic with Wireshark.
ESP

As you can see there are only ESP packets, in other words the encryption of the IPsec tunnel is working.

In my next post I will talk about dynamic routing with GRE over IPsec.

 

Advertisements

Private vlan’s

This blogpost is about private vlan’s. For  my CCIE study I looked into PVLAN’s. First some terminology. When working with PVLAN’s words like primary vlan, secondary vlan, promiscuous port, isolated port and community port have to sound familiar. If not check the following summary:

  • Primary VLAN: Original vlan, used to forward the actual traffic
  • Secondary VLAN: is configured with one of the following types Isolated or Community
  • Isolated port: A switch port configured as Isolated is only able to communicate with the promiscuous port. It is not able to reach any other destination!
  • Community port: A switchport configured as Community is able to communicate with a server in the same community vlan and the promiscuous port. A community port is not able to communicate with an isolated port.

Below a drawing which describes the above summary.

PVLAN

In the configuration below two laptops are configured in an isolated vlan. Therefor they won’t be able to communicate with each other, but they are able to communicate with the promiscuous port.

PVLAN_isolated

 

In the next configuration the two laptops are configured in a community vlan. because of that they are able to ping each other.

PVLAN_community

 

As you probably noticed, the only configuration change is that the private-vlan host-association changed.

Private vlan’s are very useful to large ISP, because with isolated ports it’s possible to use the same subnets. There is virtually no limit to the number of customers and only one firewall is needed for a lot of customers. The only limiting option is the throughput of the used firewall!

 

** to build this topology I used a Cisco 3560 switch and a Cisco ASA 5505 firewall

Port Access-Lists (PACL)

A while ago I blogged about VACL or Vlan Access-Lists. PACL and VACL are really connected to each other. In this blogpost I will show you how PACL works and how to configure it on a Cisco switch.

First of all, what is PACL. PACL makes it possible to filter incoming traffic on a layer 2 interface using layer 3 or 4 information.

First some restrictions on PACL

  • There can only be one ACL applied to a layer 2 interface per direction
  • PACL don’t filter later 2 traffic like CDP, VTP, DTP, UDLD and STP because this traffic is handled by the Route Processor before the applied ACL takes effect
  • The number of ACL’s that can be configured as part of the PACL configuration is bounded by the hardware resources of the switch
  • A MAC ACL is not applied to IP, MPLS or ARP messages
  • Only named MAC ACL can be used

I spoke earlier about the interaction between PACL and VACL. When they are both used on the switch and the traffic is bridged, PACL will always be applied before VACL’s. PACL will even override a “normal” ACL that is applied to the same interface (for this situation is only one exception, if packets are forewarded in software by the RP. If this is true an ” normal” ACL will take precedence over the PACL). Summarizing the above:

  • PACL for the ingress port
  • VACL for the egress vlan
  • VACL vfor the egress vlan

Below a schematic of this.

*PACL_bridged

It’s fairly easy to configure this, below an example of my lab and how to configure this:

topology

PACL_portconfig

PACL_acl

 

It’s a little different when the traffic is routed. The next is true for routed packets:

  • PACL for the ingress port
  • VACL for the ingress vlan
  • Input Cisco IOS ACL
  • Output Cisco IOS ACL
  • VACL for the egress vlan

Below a schematic of the above:

*PACL_routed

 

PACL can come in handy when you want to deny access of a PC/Server to another PC/Server in the same vlan and you can’t change the vlan of the machines.

 

More information on this topic can be found on the Cisco site (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SY/configuration/guide/sy_swcg/port_acls.pdf).
*=I found the used schematics on the Cisco site and borrowed them!

Differences between HP, 3COM and Cisco

Lately I have been working a lot with HP(2610, 2620), 3COM(4500, 5500) and Cisco switches. For a customer I migrated the 3COM cores switch to a Cisco Coreswitch. Before this job I never worked with HP or 3COM before. Although networking principles and protocols are the same for Cisco, HP and 3Com, there are some substantial differences between them.

First of all you have to understand that “trunking” in Cisco language means that you configure a port to transport several vlan’s. In HP/3COM it means bundeling two or more physical interfaces to one logical interface. Bundeling physical ports to become one logical port is called “port-channeling” in Cisco language.  The equivalent of Cisco’s trunking in HP/3COM language is “port tagging”.

When you configure a trunk port on a Cisco switch, you configure the port to allow trunking of several vlan’s. When configuring port-tagging you create a vlan and add ports to the vlan. An example:

Cisco:
Trunk_Cisco

HP:

HP

3COM:

3com_vlan

3com trunk

 

Since HP bought 3COM in 2010, I was clearly dealing with a lot of old stuff. So the 3COM CLI doesn’t exist anymore on modern switches. It’s all HP now. Nevertheless it is possible you encounter 3COM switches in modern networks. Below a table with some handy show command’s for Cisco and the equivalents for HP and 3COM.

commands

Then there is good old spanning-tree. On the internet you read a lot about horror story’s about spanning-tree between Cisco and HP/3COM. After reading about it, I configured “rapid spannig-tree ” (802.1w) on the Cisco core switchs. On the HP and 3COM switches the equivalent of 802.1w was already configured. After replacing the 3COM core switch with the Cisco model, I did not encounter any problems with spanning-tree!

One other thing that catched my attention, is that the HP 2610 and 2620 only host a maximum of 8 vlan’s and 16 static routes.

Off course there are a lot of other differences between Cisco and HP/3COM, but the ones described as above are the most obvious ones.

 

Web Cache Communication Protocol (WCCP)

A customer implemented a transparant Cisco WSA (Ironport) for the redirection of the http and https traffic. WCCP had to be configured on their Cisco 3750 switch with IOS releas 12.2(55)SE9.
First some background info on WCCP:

The Cisco IOS WCCP feature allows utilization of Cisco Cache Engines (or other caches running WCCP) to localize web traffic patterns in the network, enabling content requests to be fulfilled locally. Traffic localization reduces transmission costs and download time.
WCCP enables Cisco IOS routing platforms to transparently redirect content requests. The main benefit of transparent redirection is that users need not configure their browsers to use a web proxy. Instead, they can use the target URL to request content, and have their requests automatically redirected to a cache engine. The word “transparent” is this case means that the end user does not know that a requested file (such as a web page) came from the cache engine instead of from the originally specified server.
When a cache engine receives a request, it attempts to service it from its own local cache. If the requested information is not present, the cache engine issues its own request to the originally targeted server to get the required information. When the cache engine retrieves the requested information, it forwards it to the requesting client and caches it to fulfill future requests, thus maximizing download performance and substantially reducing transmission costs.
WCCP enables a series of cache engines, called a cache engine cluster, to provide content to a router or multiple routers. Network administrators can easily scale their cache engines to handle heavy traffic loads through these clustering capabilities. Cisco clustering technology enables each cache member to work in parallel, resulting in linear scalability. Clustering cache engines greatly improves the scalability, redundancy, and availability of your caching solution. You can cluster up to 32 cache engines to scale to your desired capacity.

I took the above text from the Cisco website, so if you want to read more on the theory behind WCCP check out: http://www.cisco.com/c/en/us/td/docs/ios/12_2/configfun/configuration/guide/ffun_c/fcf018.html

To configure WCCP on a Cisco 3750 there are some constraints:

  • Make sure SDM prefer is on an routing image
  • Forwarding can only be L2 (in the WSA this is default GRE or L2, configure it hard on L2 only)
  • Assignement method can only be MASK (in the WSA this is default HASH or MASK, configure it hard on MASK only)
  • Make sure clients and WSA are on different vlan’s
  • Forwarding redirect list can only understand PERMIT statements
  • When usig a dynamic WCCP identifier configure in the WSA the ports that have to be redirected, in this example it has to be 80(http) and 443(https)

Configuration will look like below:
First configure the routed vlan’s
!
vlan 100
name WSA
!
vlan 200
name Clients
!
int vlan 100
ip address 10.10.10.254 255.255.255.0
no shut
!
int vlan 200
ip address 172.18.10.254 255.255.255.0
no shut
!

Then configure the access-lists to “catch” the client traffic that has to be redirected:
!
ip access-list extended 100
permit tcp 172.18.10.0 0.0.0.255 any eq www
permit tcp 172.18.10.0 0.0.0.255 any eq 443
!
I used a numbered ACL, so I can debug it. A named list can’t be debugged! Make the ACL as specific as possible!

Then create an ACL for the redirect-list. This ACL consists of the WSA addresses.
!
access-list 10 permit 10.10.10.1
access-list 10 permit 10.10.10.2
!

The actual WCCP configuration consist out of two command.
A global command:
!
ip wccp 100 redirect-list 10
!

And a command on the client vlan interface:
!
int vlan 200
ip wccp 100 redirect in
!

There isn’t more to it. To check if WCCP is functioning use the “show ip wccp 100 [detail|view]” command.
To check a little deeper, use the “debug ip wccp packets” command. If you see the “WCCP2_HERE_I_AM” and “WCCP2_I_SEE_YOU” packets than the WCCP mechanism is functioning.
Even if WCCP functions it’s possible traffic does not get redirected. This can be due to a dozen of problems. First step is to check if the client traffic is redirect at all. This can be done by using the “debug ip packet detail 100” command. If no traffic hits the ACL, traffic won’t be redirected to the WSA.

Cisco Champion 2015!

 

CiscoChampion200PX

I’m proud to announce that I’m elected to be a Cisco Champion in Enterprise Networks. In the future I will post some more info about this program!

My colleague and mentor at Open Line, Rob Rademakers, has been elected to be Cisco Champion for the second year in a row! Congrats!

VSS on Cisco 4500-X

For a customer I recently configured two Cisco 4500-x switches with VSS (Virtual Switching System). VSS makes two 4500-x switches to function as one logical switch. By configuring VSS on botch switches, there is one active RP (Route Processor) and one hot standby RP. When the active RP fails, the hot standby RP will take over operations without the loss of data.

The VSS switches are connected by an VSL (Virtual Switch Link), which is normally build as an etherchannel. The VSL serves as logical connection that carries critical system control information such as hot-standby supervisor programming, line card status, Distributed Forwarding Card (DFC) card programming, system management, diagnostics, and more. In addition, VSL is also capable of carrying user data traffic when necessary.

By using VSS it’s possible to uplink a switch with two uplinks in an etherchannel.This is called a MEC (Multichassis Etherchannel). Because you connect the uplinks to two switches functioning as one, there is no need for spanning-tree to block one of the links. So instead of two uplinks with one blocked by spanning-tree, there are two active links which makes it possible to use a 2 x 1/10/40Gb etherchannel as uplink.

To prevent both switches from becoming active, there is a mechanism called “Dual active detection” or VSLP (Virtual Switch Link Protocol). Two modes are available, PagP and Fast-hello. In the following configuration example, I’ll give an example of VSS with “Fast-hello” dual active detection.

The picture below depicts the written above:
VSS

Now let’s take a look at the configuration:

First configure the switches seperatly
Switch1
!
conf t
!
switch virtual domain 100
switch 1
switch 1 priority 110
mac-address use-virtual
!
int pox
switchport
swi virtual link 1
no shutdown
!
int range tx/x/x – x
channel-group 101 mode on
no shut
!
switch set switch_num 1 local
switch read switch_num 1 local
!
end
!
wr
!

Switch2
!
conf t
!
switch virtual domain 100
switch 2
switch 2 priority 90
mac-address use-virtual
!
int poxx
switchport
sw virtual link 2
no shutdown
!
int range tx/x/x – x
no switchport nonegotiate
channel-group x mode on
no shutdown
!
end
!
switch set switch_num 2 local
switch read switch_num 2 local
!
wr
!

After this give the following command on both switches to convert them to VSS mode:
!
switch convert mode virtual
!

After rebooting the Fast-hello dual active detection can be configured.
Switch1
!
conf t
!
switch vitrual domain 100
dual-active detection fast-hello
!
int tx/x/x
dual-active fast-hello
no shut
!
end
!
wr
!

Switch2
!

conf t
!
switch virtual domain 100
dual-active detection fast-hello
!
!
int tx/x/x
dual-active fast-hello
no shut
!
end
!
wr
!

Make sure u use an IOS XE version higher than:  cat4500euniversal.SPA.03.04.03.SG.151-2.SG3.bin
The IOS XE version above supports only PagP dual active detection!

To be fully complete in the IOS XE version mentioned earlier is a bug. If you try to configure the Fast Ethernet ports for management, the won’t work. It’s possible to configure a IP address and so one. The “show ip int brie” commando will even say the interface is up, but it’s just not possible to ping the interface.
After an IOS upgrade everthing came to life and functioned as intended.