Connect to OSPF area 0 over GRE tunnel

We all know that all OSPF areas have to be connected to area 0. But sometimes you encounter
a situation where it is not possible to connect an area to area 0. This can happen because of
poor network design or because two or more networks merge together. There are several options
to deal with this problem. In the CCNP curriculum you learn that a virtual-link is the way
to go on this problem. But there is an other option which is not as popular, but in my opinion
is even more elegant. I’m talking about a GRE tunnel solution.

Let’s take the topology as shown in the picture below.

OSPF_GRE_TOPOLOGY

Router R2 is connected to R1 in area 0. R2 and R3 are connected in area 1 and R3 is connected
to R4 in area 2. Which means that R3 has no connection to area 0.

Below the configurations of routers R1 to R4 before the configuration of the GRE tunnel.

R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
switchport access vlan 10
!
!
interface FastEthernet2/0
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.100.100.254 255.255.255.0
!
router ospf 10
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 10.0.0.0 0.0.0.3 area 0
network 10.100.100.0 0.0.0.255 area 0
!
R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
!
interface FastEthernet1/0
ip address 10.0.1.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.0.2 255.255.255.252
duplex auto
speed auto
!
!
router ospf 10
router-id 2.2.2.2
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 1
network 10.0.0.0 0.0.0.3 area 0
network 10.0.1.0 0.0.0.3 area 1
!
R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
!
interface FastEthernet1/0
ip address 10.0.1.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.3.1 255.255.255.252
duplex auto
speed auto
!
!
router ospf 10
router-id 3.3.3.3
log-adjacency-changes
network 3.3.3.3 0.0.0.0 area 1
network 10.0.1.0 0.0.0.3 area 1
network 10.0.3.0 0.0.0.3 area 2
!
R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
switchport access vlan 10
!
!
interface FastEthernet2/0
ip address 10.0.3.2 255.255.255.252
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.200.200.254 255.255.255.0
!
!
router ospf 10
router-id 4.4.4.4
log-adjacency-changes
network 4.4.4.4 0.0.0.0 area 2
network 10.0.3.0 0.0.0.3 area 2
network 10.200.200.0 0.0.0.255 area 2
!

To make this topology work there needs to be a connection from R3 to area 0. To make this happen
make the following configurations to router R2 and R3.

R2
!
interface Tunnel0
ip address 172.18.2.1 255.255.255.0
tunnel source Loopback0
tunnel destination 3.3.3.3
!
!
router ospf 10
network 172.18.2.0 0.0.0.255 area 0
!
R3
!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
tunnel source Loopback0
tunnel destination 2.2.2.2
!
!
router ospf 10
network 172.18.2.0 0.0.0.255 area 0
!

If you do a “show ip ospf neighbors” on R2 you can see there is a full neighborship between router
R2 and R3 in area 0.

show ip ospf neighbors R2-R3
And with the “show ip route” command you see the network from “area 2” is now in the table.

show ip route R2-R3
Now ping from PC1 to PC2 and this will succeed.

ping PC2-PC2

More interesting is a traceroute from PC1 to PC2, this will show the traffic is actually going
trough the GRE Tunnel!

traceroute PC1-PC2

Advertisements

GRE over IPsec tunnels (Part 2)

In my last post I wrote about GRE over IPsec, but only with static routes. One of the benefits of GRE over IPsec tunnels is that you can send multicast traffic  over the tunnel. With a plain IPsec tunnel this is not possible. So to prove that multicast traffic can cross the GRE over IPsec tunnel I took the topology of my last post and removed the static routes from the configuration of the HQ and Branch routers.
Below the used topology:
GRE_over_IPsec

Then configure the EIGRP configuration on both routers.

R1#sh run | se eigrp
router eigrp 10
network 10.10.10.0 0.0.0.255
network 172.18.2.0 0.0.0.255
no auto-summary
R1#

The syslog below confirms that the EIGRP adjacency is up and running:
EIGRP_adj

Then use the “debug ip packet detail” command to verify that multicast is used and allowed:
EIGRP_multicast

To prove the solution is working check the routing table.
sh_ip_route

And that’s all there to configure dynamic routing over a GRE over IPsec tunnel.

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.

 

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!

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.

 

Protect your network against CDP attacks!

As a network consultant/engineer you should be aware of network security risks. Today it is fairly simple to take down a network with the use of Kali Linux. There, it has been said: Kali Linux. This Linux distro is a hackers dream. It has all the necessary tools on board to damage a network very very hard! A hacker only needs a free outlet that is patched to a switch. Within minutes a company can be down on it’s knees!

First of all I’m writing this series of postings to point out the need for security on the network layer, not to make a hackers life easy! In this post I will describe how to use Kali Linux, but more important are the security solutions I give to prevent attacks on your network. This post will be about protecting your network against CDP attacks.

How do I test Kali, you probably guest it already when you read my earlier posts, I use GNS3 for it. Below the topology I use for testing.
topology

R1 and R2 are configured as two multilayer switches, with several (routed) vlan’s. For reference below the config of R1.

R1
!
interface FastEthernet0/0
description Trunk to R2
switchport mode trunk
!
!
interface FastEthernet0/4
switchport access vlan 11

!
!
interface Vlan10
ip address 10.0.0.252 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.252 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.252 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.252 255.255.255.0
standby 13 ip 192.168.80.254
!

CDP Flooding
CDP (Cisco Discovery Protocol) is a great tool when you have to make documentation of a network and most cases CDP is globally enabled on every switch en every switchport on the network. Great, but then a any given moment you check the cdp status on your switch and see this:

cdp_flood

and this:
proc_cpu

As you can see the cdp table is flooded with bogus entry’s and because of the ongoing stream of bogus cdp packets, the cpu spikes to 100%. It’s just a matter of time before the switch will reboot. Problem is, when the switch is rebooted it will be just the same because the stream of cdp packets just keeps going on.

How is this possible you think, well it’s really easy. Install Kali Linux, start the Yersinia program and click attack. Is it that easy I hear you think? Yes it’s that easy! Check it out:

Start Kali Linux:
kali

Start Yersinia
start yersinia

Click the cdp tab, click Launch Attack, choose “flooding CDP table” and click “OK”.
start attack

 

That’s it, your cdp table will be flood with bogus cdp packets. Now check your switch with the “show cdp table”, “show cdp traffic” and “show proc cpu sorted” command:
cdp_flood

proc_cpu

cdp traffic

Within two minutes my switch crashed and rebooted, so this is a real threat to the stability of your network.
To prevent this kind of attacks a couple of things can be done:

First of all, place switchports that are not in use in a dummy vlan and give them an admin down
Second, disable cdp on switchports that don’t need it. For example access ports that only contain a computer or a IP phone which don’t need the CDP protocol to function!
Third, ports that can’t be disabled, configure Port Security on them!