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.


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
duplex auto
speed auto
interface Vlan10
ip address
ip route

Then create the tunnel interface

interface Tunnel0
ip address
ip mtu 1400
tunnel source FastEthernet1/0
tunnel destination
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:

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
crypto ipsec transform-set test esp-3des esp-md5-hmac
access-list 101 permit gre host host
crypto map s-2-s 10 ipsec-isakmp
set peer
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:

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.

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.



MPLS VPN (Part 1)

A part of my CCIE study is MPLS VPN’s. This week I read some MPLS books, like “MPLS Fundamentals” and “MPLS and VPN Architectures, Volume II”. So to test my knowledge of the subject I found a useful case study online.

In the picture beneath the topolgy is shown:


Goal of this case study is to ping from Workstation “PC-COMPA-01” which resides in Company_A-West (as of now “West”) to “PC-COMPA-02” which resides in Company_A-North (as of now “North”).
The Provider core has to be free of BGP and has to be MPLS enabled. The core has to make use of a dynamic routing protocol.

I started with the dynamic routing configuration of the “Provider Core” which exists of the following routers : R1, R3, R2 and R4. Below is the configuration of R1 (R2, R3 and R4 are almost the same):


After configuring the other routers, the routing table of R1 looks like the picture beneath:

ip route

The above steps are needed, because on the PE routers (R6 and R9) BGP will be configured. BGP makes use of the core network, so the routing needs to be in order.
Routers R6 and R9 will also make use of the eigrp protocol. So make sure it is possible to ping from R6= to R8=
In the picture below the configuration of the eigrp configuration of router R6:

Config R6

If this works, the BGP configuration can be made. As we all know BGP makes use of TCP, because of that it is important there is L3 connection from R6 to R8 and everthing in between.
Below the BGP configuration on R6 and R8.


To confirm that BGP functions as intended, use the “show ip bgp neighbors” command. Below the output of the command on R6.

Sh ip bgp neig


Before creating the VRF’s MPLS can be configured. Just give the “mpls ip” (Yes it’s really as simple as that!) command on the interfaces which have to take part in MPLS.
To confirm MPLS is active use the “show mpls forwarding-table” command. Below is the ouput of R1.

sh mpls forwa

Now it’s time to create the VRF’s, VRF stands for “Virtual Routing and Forewarding”. It’s like a virtual routing table which makes it possible to have the same ip subnets on one router. Which, in turn, makes it possible to have different customers with the same ip subnets on one router (or infrastructure for that matter).
To make communication possible between West and North, two VRF’s are created. One on R6 named “Customer_A-West” and one on R8 named “Customer_A-North”. Add the interfaces facing the CE router to the correct VRF.
Below the configuration needed.



Once the VRF’s are created, some changes have to be made on the BGP configuration, to let BGP know there is a VRF. Below the config of R6. The configuration for R8 is the same, only use the R8 ip addresses etc.

bgp vrf


As can be seen in the above picture, a static route has to be configured to make communications possible between routers R6 and R9 and also between R8 and R10. This static route will be configured in the VRF routing table, not in the global routing table! To test connectivity use the “ping VRF <vrf name>” command. With this command the ping originates from within the VRF and not from the global routing table!

Once the above configurations are made, R9 and R10 have to be configured. It’s a pretty straightforward configuration. Below the configuration of R9.


Configure the clients with the correct ip addresses and test the connection between the workstations with the ping command:

pingR9-R10 ping R10 - R9

That’s basically all there is to make a MPLS VPN work!

Check for more info about MPLS VPN’s


SVI’s and Routing on Cisco 2960 switches

As I wrote before, I have been working a lot witch Cisco 2960 switches lately. Although I was aware of the fact that routing was possible on a 2960 switch, I never actually tested this. I never tested this because of the simple fact that routing on an access switch is not done. At least we try to avoid it.

Before Routing is enable on a 2960 switch, you have to change the “SDM” settings, this can be done with the following commands:

switch01# configure terminal
switch01 (config)# sdm prefer lanbase-routing

Now you have to reload the switch to make lanbase-routing active. After reloading the switch you can check the SDM status with the following command:

Switch01#show sdm prefer
The current template is “lanbase-routing” template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 255 VLANs.
  number of unicast mac addresses:                                  4K
  number of IPv4 IGMP groups + multicast routes:               0.25K
  number of IPv4 unicast routes:                                        4.25K
  number of directly-connected IPv4 hosts:                         4K
  number of indirect IPv4 routes:                                       0.25K
  number of IPv4 policy based routing aces:                        0
  number of IPv4/MAC qos aces:                                        0.125k
  number of IPv4/MAC security aces:                                  0.375k

Keep in mind:

  • You need at least IOS release 12.2(55).
  • Only 8 SVI’s are allowed
  • Only 16 static routes are allowed
  • Advanced routing is NOT possible

I was not able to perform a stress test on the switches, but nevertheless, when routing is required I prefer to use a Cisco 3560 switch (with the right license off course) .