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.

Advertisements

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:

MPLS VPN

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):

R1_config

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=6.6.6.6 to R8=8.8.8.8.
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.

BGP

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.

VRF

 

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.

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 http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/15-mt/mp-l3-vpns-15-mt-book/mp-bgp-mpls-vpn.html

 

Redistribution and Route-Maps (part 2)

In part two of this post I will explain how to make use of route-maps to influence the redistribution process of routing protocols.

First take a look again at the network topology.
Network Layout

As can be seen the redistribution point is between R4 and R5. The actual redistribtion configuration is done on R5.
With the configuration made in part 1 of this post, all routes are known to all routers in the topology. For whatever reason, sometimes you don’t want that all routes are vissible. This is where a route-map comes in handy.
With the use of route-maps I can influence a lot of things, like traffic flow and in this case the redistribution of routes.

Let’s assume the network administrator wants to exclude the ip-address of router R7 (7.7.7.7) from the routing table in the OSPF cloud. To make this happen the next configuration has to be made.

First of all make a standard ACL, in which you permit the 7.7.7.7 traffic
ACL

Then configure the route-map. Give it a name that makes sense to you (document this to make sure future colleagues understand it to!).
route_map

The “deny 10” does what it say’s, deny everything what comes after this line. The “match ip address 1” matches the traffic that hits access-list 1. The “route-map Redis permit 15” is not explicitly necessary, but to make things clear I added it nevertheless.

Now we have to tell the routing protocol to look at the “Redis” route-map. Otherwise the traffic will just flow as before
OSPF_redis
As you can see in the screenshot above, you just make an addition to the redistribution command.

Now take a look at the routing table of let’s say, router R1
Route_table_RM
As you can see there is no entry to the 7.7.7.7 route anymore
To be totally sure, do a ping test to 7.7.7.7
R1_ping_aft_RM

Route maps can be used for a lot of things and influence alsmost everthing. Check the Cisco documentation for more options!

Redistribution and Route-Maps (part 1)

This post will be about redistribution and the use of route-maps to influence the redistribution process.

When companies merge, the network has to merge too. Often the networks don’t use the same routing protocols. Sometimes it’s possible to migrate a netwerk from let’s say OSPF to EIGRP, but when the company’s don’t use Cisco only, it’s is hard to migrate.

To tackle this problem it’s is possible to redistribute the OSPF routes into EIGRP and also the other way around. This means that all the routes from OSPF are known in the EIGRP cloud, and al the EIGRP routes are known in the OSPF cloud. Sometimes it is not necessary for the EIGRP cloud to know al the OSPF routes. That’s when route-maps come in. With a route-map it is possible to make sure certain routes will never get to the routing table.

In the next section a configuration example.

First have a look a the network layout:

Network Layout

Al routers have two intfaces to connect to their neighbours and one loopback interface to identify the router.
Below an example of router R3:

Interfaces R3

After that configure OSPF:

EIGRP_redistribute R3

Make sure you configure these steps on all the OSPF routers.
To make sure the configuration is correct, check if the “show ip ospf neighbours” command shows two neighbours
OSPF_neighbours R3

 

After configuring the correct interfaces, configure EIGRP:

EIGRP R6

The initial configuration is done. Now the redistribution part can be configured. To make redistribution possible there has to be a redistribution point, in other words, there has to be a router which has an interface (or interfaces) in the OSPF aswell as the EIGRP cloud. In this example R5 is the redistribution point.

Below an example of the redistribution between OSPF and EIGRP on R5:

OSPF_redistribute EIGRP_redistribute R3

As shown in the examples the redistribution command has some options. The default values are enough to make the redistribution work.

To make sure the redistribution works, use the command show ip route on for example router R4.

Routes R4 after redistribution

As can be seen in the above example the EIGRP routes are learned as E2 routes. To make sure the connectivity is correct, use the ping command. As can be seen in the next example, the ping command is succesfull from router R1 to router R7.

ping

 

In part 2 I will describe the route-map configuration.