L2TP version 3 VLAN-to-VLAN

For a few days ago I had to find a solution for a customer that could provide VLAN-to-VLAN traffic over Internet between 2 locations. I found a solution which I think was really interesting therefore I want to share it here.

Here are the requirements:

    Host 1 (VPC1) in VLAN X  at location A and Host 2(VPC2) in VLAN X in location B should be able to send Multicast traffic to each other as well as unicast traffic
    Host 3 (VPC3) in VLAN Y  at location A and Host 4(VPC4) in VLAN Y in location B should be able to send Multicast traffic to each other as well as unicast traffic
    Host 2 and Host 4 at location B cannot be configured with a default gateway so they must be in the same broadcast domain as Host 1 and Host 2 respectively in location A
    Host 1/2 traffic should completely be isolated from Host 3/4 traffic

First of all I thought of configuring GRE and multicast routing but then I realized that there would be an issue for unicast traffic as Host 2/4 cannot be configured with a default gateway. So one of my colleague told me to use L2TPv3. I haven’t heard about this feature before. I knew EoMPLS but I did not know  that it was possible to send L2 traffic over Internet.

I used GNS3 (my favorite simulating tool) to test it. Here is the setup  used (I am using cisco 2691 with 12.4(15)T11)

 

Here is an output on how the L2TPv3 encapsulation looks like when I ping from VPC1 to VPC2. As you can see below the Cisco implementation of L2TPv3 uses IPv4 encapsulation with an IP protocol ID of 115. Cisco does not support the IPv4/UDP encapsulation form for L2TPv3  which can have the advantage of being friendlier to applications such as NAT. Moreover IPv4 encapsulation only provides header checksum while UDP also provides payload intergrity.

Show Commands:
show l2tunn session -> Provide state of the tunnel(s). Look for esp state which means established
show l2tunn session all -> Provide more detailed information about the tunnel(s)
show xconnect all -> Provide state of the tunnel(s). Look for up state

Debug commands:

debug vpdn l2x-events
debug vpdn l2x-packets

I attach the partial configuration of R1 and R3 if some people are interested in it: R1-R3-L2TPv3-Config

At first I could not make it work when using VLAN1 then after configuring another VLAN it was working.  I am not sure what is going on when using VLAN1 but maybe it is because Cisco router/switch uses VLAN1 for control traffic (VTP,STP,CDP). If anyone as an idea you are really welcome to write a comment.

Read More

Resolving MPLS LDP Troubleshooting Issue

When faced with a troubleshooting ticket involving MPLS you need to clear the basics first to ensure that everything is working from a Label Distribution perspective.

1. First of all you need to establish IGP connectivity between all the routers. 
2. Can you ping all the loopbacks?
3. Are there /32 loopbacks configured on every router and advertised into IGP?
4. Is CEF enabled?
5. Is MPLS IP enabled on the required interfaces?
6. Have the routers discovered any LDP neighbors?

I have put together this quick list of commands that I would run on each router to quickly verify that Label Distribution is working

sh run | inc ip cef
sh run | inc mpls ip
sh mpls interface
sh mpls ldp disco
sh mpls ldp neigh

And also when applied to a router in a working MPLS Core the output must look as per fig. below,

 

    

Read More

Archiving a running-config Automatically Against Any Change

The other day I found a handy script on Cisco EEM scripting community  that can automatically archive the running-config if a a change has been made to it.

The archive feature must be configured first and you should also define an EEM variable for the script to work.
The script use the “Configuration Replace and Rollback” IOS feature to know if a change has been made by comparing the running-config the previous archive. If any differences the device will archive the config and it will be listed as most recent in the output of show archive.

Here is the link to the TCL script from Cisco: Archive_Config_if_Changes.tar.gz

Read More

An Interesting Topic: BGP over GRE

While I was doing some BGP labs I came across an interesting topic which is BGP over GRE. Using automatic tunneling techniques along with BGP is the core of MPLS VPNs and I think it is worth seeing the effect of using manual tunnels along with BGP. Let´s have a look at the following topology which illustrates my example:

The core IGP is EIGRP while BGP is used between AS 100 and AS 200 to advertise both loopback IP. Only router R5 and R1 are running BGP. For the BGP peering R1 IP 100.1.0.1 and R2 IP 200.1.0.5 will be used. When looking at a traceroute output from R1 to R5 the number of hops showed is 3 which means that we will have to use either ebgp multihop or ttl security as EBGP TCP packets are sent with a TTL 1 which means that EBGP peers are supposed to be directly connected. In this example I will use ttl security which while having the same effect as ebgp multihop adds some security. Let´s build the EBGP session between R1 and R5:

 

Read More

Discussing OSPF Version 2 In Detail

OSPF is one of the core topics of the CCIE R&S lab exam and therefore one should be an expert at it before attending the lab exam.

 In this post I would like to explore OSPFv2 and especially how OSPF uses its algorithm to find the best path to a destination. I will try to cover most of the general OSFP topics such as basic configuration, types of LSAs, Path selection, External path selection with LSA Type 5, Default routing, Conditional Default Routing, the different types of Stub areas, Virtual-links, LSA Type 3 filtering and Prefix filtering with route-maps. I have to admit that this post is quite long :-)

Just go through the following topology for more understanding:

Read More

Understanding EIGRP Stub Leak Map

While reviewing IEWB VOL 1 VER 5 labs, I discovered a new feature: EIGRP Stub with Leak Map. I spent some time researching the topic and found out a variation of the feature which is not explored in the workbook. Here I’ll try to demonstrate EIGRP stub routing with leak map as well as what is called strictly controlled Leak Maps.

The basic routing configuration on the routers is as follows.

R4 and R5 are running rip.

R4:
router rip
version 2
passive-interface default
no passive-interface Serial1/0
network 150.1.0.0
no auto-summary

R5:
router rip
version 2
network 5.0.0.0
network 150.1.0.0
no auto-summary

The rip table of R4 is as follows.

R4#sh ip route rip
5.0.0.0/24 is subnetted, 4 subnets
R 5.5.0.0 [120/1] via 150.1.45.5, 00:00:22, Serial1/0
R 5.5.1.0 [120/1] via 150.1.45.5, 00:00:22, Serial1/0
R 5.5.2.0 [120/1] via 150.1.45.5, 00:00:22, Serial1/0
R 5.5.3.0 [120/1] via 150.1.45.5, 00:00:22, Serial1/0

R4:
router eigrp 10
network 150.1.14.4 0.0.0.0
no auto-summary

R1:
router eigrp 10
network 150.1.12.1 0.0.0.0
network 150.1.13.1 0.0.0.0
network 150.1.14.1 0.0.0.0
no auto-summary

R2:
router eigrp 10
network 150.1.12.2 0.0.0.0
no auto-summary

R3:
router eigrp 10
network 150.1.13.3 0.0.0.0
auto-summary


Also at R4 we have mutual distribution between Rip and EIGRP.

R4
router eigrp 10
redistribute rip met 1 1 1 1 1
router rip
redistribute eigrp 10 met 1

Now we examine the routing tables on R2 and R3.
We notice that all eigrp routes, including the external RIP routes are in routing table.

R2#sh ip route eigrp
5.0.0.0/24 is subnetted, 4 subnets
D EX 5.5.0.0 [170/2560537856] via 150.1.12.1, 00:00:18, Serial1/0
D EX 5.5.1.0 [170/2560537856] via 150.1.12.1, 00:00:18, Serial1/0
D EX 5.5.2.0 [170/2560537856] via 150.1.12.1, 00:00:18, Serial1/0
D EX 5.5.3.0 [170/2560537856] via 150.1.12.1, 00:00:18, Serial1/0
150.1.0.0/24 is subnetted, 4 subnets
D 150.1.14.0 [90/2195456] via 150.1.12.1, 00:03:54, Serial1/0
D 150.1.13.0 [90/2195456] via 150.1.12.1, 00:03:54, Serial1/0
D EX 150.1.45.0 [170/2560537856] via 150.1.12.1, 00:00:18, Serial1/0

R3#sh ip route eigrp
5.0.0.0/24 is subnetted, 4 subnets
D EX 5.5.0.0 [170/2560051456] via 150.1.13.1, 00:00:40, Ethernet0/0
D EX 5.5.1.0 [170/2560051456] via 150.1.13.1, 00:00:40, Ethernet0/0
D EX 5.5.2.0 [170/2560051456] via 150.1.13.1, 00:00:40, Ethernet0/0
D EX 5.5.3.0 [170/2560051456] via 150.1.13.1, 00:00:40, Ethernet0/0
150.1.0.0/24 is subnetted, 4 subnets
D 150.1.14.0 [90/307200] via 150.1.13.1, 00:03:50, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.13.1, 00:03:50, Ethernet0/0
D EX 150.1.45.0 [170/2560051456] via 150.1.13.1, 00:00:40, Ethernet0/0

Now we’ll configure R1 as stub.
As a result all external routes should disappear from R2 and R3.

R1
router eigrp 10
eigrp stub connected

R2#sh ip route eigrp
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/2195456] via 150.1.12.1, 00:00:23, Serial1/0
D 150.1.13.0 [90/2195456] via 150.1.12.1, 00:00:23, Serial1/0

R3#sh ip route eigrp
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/307200] via 150.1.13.1, 00:01:15, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.13.1, 00:01:15, Ethernet0/0

All right!

Now we’ll discover different options for leak maps by implementing different routing policies.

Policy 1:

Configure R1 such that R2 and R3 have reach ability to 5.5.0.5 and 5.5.1.5 networks.

For this we’ll match the desired networks in an access-list and then implement EIGRP stub Leak Map.



R1
access-list 1 permit 5.5.0.0 0.0.0.255
access-list 1 permit 5.5.1.0 0.0.0.255
route-map EIGRP_LEAK
match ip address 1
router eigrp 10
eigrp stub connected leak-map EIGRP_LEAK

Now we examine the routing tables on R2 and R3

R2#sh ip route eigrp
5.0.0.0/24 is subnetted, 2 subnets
D EX 5.5.0.0 [170/2560537856] via 150.1.12.1, 00:00:28, Serial1/0
D EX 5.5.1.0 [170/2560537856] via 150.1.12.1, 00:00:28, Serial1/0
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/2195456] via 150.1.12.1, 00:00:28, Serial1/0
D 150.1.13.0 [90/2195456] via 150.1.12.1, 00:00:28, Serial1/0
R2#

R3#sh ip route eigrp
5.0.0.0/24 is subnetted, 2 subnets
D EX 5.5.0.0 [170/2560051456] via 150.1.13.1, 00:00:20, Ethernet0/0
D EX 5.5.1.0 [170/2560051456] via 150.1.13.1, 00:00:20, Ethernet0/0
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/307200] via 150.1.13.1, 00:00:20, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.13.1, 00:00:20, Ethernet0/0
R3#


Policy 2:
Configure R1 such as R3 sees both 5.5.0.0 and 5.5.1.0 networks but R2 cannot.

Here we can use ‘match interface’ option in the route-map.
This is called strictly controlled Leak map.
The login is as follows

1. If “match interface” options is not used, routes are leaked on all interfaces.
2. If “match interface” option is used, routes are ONLY leaked on the interface matched.


So we’ll use match interface argument in the route-map and only match interface Ethernet 0/0, which is connected to R3.

route-map EIGRP_LEAK permit 10
match ip address 1
match interface e0/0

R1#sh route-map
route-map EIGRP_LEAK, permit, sequence 10
Match clauses:
ip address (access-lists): 1
interface Ethernet0/0
Set clauses:
Policy routing matches: 0 packets, 0 bytes




Now we examine the routing tables.


R2#sh ip route eigrp
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/2195456] via 150.1.12.1, 00:02:42, Serial1/0
D 150.1.13.0 [90/2195456] via 150.1.12.1, 00:02:42, Serial1/0




R3#sh ip route eigrp
5.0.0.0/24 is subnetted, 2 subnets
D EX 5.5.0.0 [170/2560051456] via 150.1.13.1, 00:03:55, Ethernet0/0
D EX 5.5.1.0 [170/2560051456] via 150.1.13.1, 00:03:55, Ethernet0/0
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/307200] via 150.1.13.1, 00:03:55, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.13.1, 00:03:55, Ethernet0/0

So, only R3 is seeing the leaked networks now, and R2 hasn’t.



Policy 3:
Allow R3 access to 5.5.0.0/24 and 5.5.1.0/24 networks only.
Allow R4 access to 5.5.2.0/24 and 5.5.3.0/24 only.


So we’ll match the other two routes in another access-list and match that and Interface S1/0

On R1:
route-map EIGRP_LEAK permit 20
match ip address 2
match interface s1/0


R1#sh route-map
route-map EIGRP_LEAK, permit, sequence 10
Match clauses:
ip address (access-lists): 1
interface Ethernet0/0
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map EIGRP_LEAK, permit, sequence 20
Match clauses:
ip address (access-lists): 2
interface Serial1/0
Set clauses:
Policy routing matches: 0 packets, 0 bytes


Now we examine the routing tables.






R3#sh ip route eigrp
5.0.0.0/24 is subnetted, 2 subnets
D EX 5.5.0.0 [170/2560051456] via 150.1.13.1, 00:05:48, Ethernet0/0
D EX 5.5.1.0 [170/2560051456] via 150.1.13.1, 00:05:48, Ethernet0/0
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/307200] via 150.1.13.1, 00:05:48, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.13.1, 00:05:48, Ethernet0/0



R2#sh ip route eigrp
5.0.0.0/24 is subnetted, 2 subnets
D EX 5.5.2.0 [170/2560537856] via 150.1.12.1, 00:00:25, Serial1/0
D EX 5.5.3.0 [170/2560537856] via 150.1.12.1, 00:00:25, Serial1/0
150.1.0.0/24 is subnetted, 3 subnets
D 150.1.14.0 [90/2195456] via 150.1.12.1, 00:05:08, Serial1/0
D 150.1.13.0 [90/2195456] via 150.1.12.1, 00:05:08, Serial1/0

Lets test connectivity




Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.0.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/58/80 ms
R3#ping 5.5.1.5


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/60/84 ms


R2#ping 5.5.2.5


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.2.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/68/96 ms
R2#ping 5.5.3.5


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.3.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/58/80 ms


Policy 4:
Add a loopback0 3.3.0.0/24 on R3. Allow R3 to reach RIP networks when sourced from Loopback 0.

Well this is to emphasize the point that we need to consider all implications of the configuration we make.
Since R1 is a stub connected router, towards R4 it is advertising 150.1.13.0/24 and 150.1.12.0/24 networks which are directly connected, which are then redistributed into RIP and hence R3 and R1 can ping R5’s loopbacks.
But R3’s loopback won’t be advertised to R4 and until we add another route-map entry leaking this network to R4, we won’t be able to reach to R5’s loopback networks from R3’s loopback network.

Lets see this



R3:
int lo 0
ip add 3.3.0.3 255.255.255.0
router eigrp 10
net 3.3.0.3 0.0.0.0


R3#ping 5.5.0.5 source lo 0


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.0.5, timeout is 2 seconds:
Packet sent with a source address of 3.3.0.3
.....

Success rate is 0 percent (0/5)


Now we add another route-map Entry to allow 3.3.0.0/24 network to leak to R4.

R1:
access-list 3 permit 3.3.0.0 0.0.0.255
route-map EIGRP_LEAK permit 30
match ip address 3
match interface e0/1

R4#sh ip route eigrp
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.0.0 [90/435200] via 150.1.14.1, 00:00:28, Ethernet0/0
150.1.0.0/24 is subnetted, 4 subnets
D 150.1.13.0 [90/307200] via 150.1.14.1, 00:01:39, Ethernet0/0
D 150.1.12.0 [90/2195456] via 150.1.14.1, 00:01:39, Ethernet0/0

Now this network will be redistributed into rip and we’ll have connectivity.

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.0.5, timeout is 2 seconds:
Packet sent with a source address of 3.3.0.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/54/68 ms

Read More

Getting Insights Of Third Party Next-Hop

Third-party next-hop concept appears only to distance vector protocol, or in the parts of the link-state protocols that exhibit distance-vector behavior. The idea is that a distance-vector update carries explicit next-hop value, which is used by receiving side, as opposed to the “implicit” next-hop calculated as the sending router’s address – the source address in the IP header carrying the routing update. Such “explicit” next-hop is called “third-party” next-hop IP address, allowing for pointing to a different next-hop, other than advertising router. 

 Intitively, this is only possible if the advertising and receiving router are on a shared segment, but the “shared segment” concept could be generalized and abstracted. Every popular distance-vector protocols support third party next-hop – RIPv2, EIGRP, OSPF and BGP all carry explicit next-hop value. Look at the figure below – it illustrates the situation where two different distance-vector protocols are running on the shared segment, but none of them runs on all routers attached to the segment. The protocols “overlap” at a “pivotal” router and redistribution is used to provide inter-protocol route exchange.

Read More