Cisco IOS URL filter

An URL filter is a mechanism to restrict or control access to any website. The URL filter determines what content will be available or perhaps more often what content will be blocked.

Cisco IOS provides us with many different ways to accomplish an URL filter implementation. I'll discuss various techniques and present example configurations.

To perform the HTTP content filtering, the first three methods classify traffic use Cisco's Modular QoS CLI feature. Where after various ways can be applied to filter out the MQC marked traffic.  

With both the Context-Based Access Control and Zone Based Firewall method the decision which URLs to filter can be made by the router itself or by a content filtering server. In this post I will only show examples of locally configured URL filtering.

Access Control List content filter

This method uses an ACL on the output interface to drop the packets marked by MQC. The packets - containing the website requests - are marked on the interface from which the websites are requested. 

!

class-map match-any URL_BLOCK

 match protocol http host "example.com"

!

policy-map MARK_URL

 class URL_BLOCK

  set ip dscp 1

!

interface FastEthernet0/0

 description WAN interface

 ip access-group 100 out

!

access-list 100 deny   ip any any dscp 1 log

access-list 100 permit ip any any

!

interface FastEthernet0/1

 description LAN interface

 service-policy input MARK_URL

considerations

• Disable sending IP unreachable messages with the no ip unreachable interface-level command to avoid causing the router to expend excessive resources.
• Does NOT inform users, that the website is blocked and why.
• IOS allows only one ACL per direction, per protocol, per interface. So it may not be practical.

Class-Based Policy content filter

The Class-Based Method, requires even less configuration. It uses the policy-map to drop the marked packets - containing the website requests. 

!

class-map match-any URL_BLOCK

 match protocol http host "example.com"

!

policy-map MARK_URL

 class URL_BLOCK

  drop

!

interface FastEthernet0/0

 description WAN interface

!

interface FastEthernet0/1

 description LAN interface

 service-policy input MARK_URL

considerations

• Disable sending IP unreachable messages with the no ip unreachable interface-level command to avoid causing the router to expend excessive resources.
• Does NOT inform users, that the website is blocked and why.

Policy-Based Routing (PBR) content filter

This method, actually gives us two options, either route the to the Null interface, to just drop the website requests for the blocked URLs. Or route the websites marked by MQC, to a local web-server that is configured to reply with a standard page to inform users that their web request is blocked.

!

class-map match-any URL_BLOCK

 match protocol http host "example.com"

!

policy-map MARK_URL

 class URL_BLOCK

  set ip dscp 1

!

access-list 100 deny   ip any any dscp 1 log

access-list 100 permit ip any any

!

route-map test URL_REDIRECT 10

 match ip address 100

 set ip next-hop 192.168.100.100

!

!

interface FastEthernet0/0

 description WAN interface

 ip policy route-map URL_REDIRECT

!

interface FastEthernet0/1

 description LAN interface

 service-policy input MARK_URL

considerations

• If the route-map forwards filtered traffic to interface Null0, disable sending IP unreachable messages with the no ip unreachable interface-level command to avoid causing the router to expend excessive resources, 
• If the route-map forwards traffic to interface Null0, users are NOT informed that the website is blocked and why.
• If the route-map forwards the filtered traffic to a web server, to present an information page to the users, it must be configured as a catch all server. This means that a default virtual host needs to be configured. And it requires that the destination IP address of the HTTP requests are rewritten to the IP address of the server (e.i. destination NAT).

Context-Based Access Control (CBAC) content filter

This method relies on the CBAC Deep Packet Inspection (DPI) to decide which web requests are allowed or denied. The configuration is only a couple of lines. 

!

ip inspect name URL_FILTER http urlfilter

ip urlfilter allow-mode on

ip urlfilter exclusive-domain deny example.com

ip urlfilter audit-trail

!

interface FastEthernet0/0

 description WAN interface

!

interface FastEthernet0/1

 description LAN interface

 ip inspect URL_FILTER in

considerations

• Users are informed that their website request was denied via a 'HTTP 403 - Forbidden' error page.
• Only provides the ability to filter on domain names. It does NOT provide the ability to filter on other variables, like file names, or particular directories of the allowed or denied domains.

Zone Based Firewall (ZBF) content filter

With this method DPI analyses the traffic between (security) zones and the ZBF decides based on a policy map if the traffic is allowed.

!
parameter-map type urlfpolicy local URL_FILTER
 block-page message "You do NOT have permission to view this page"
!
parameter-map type urlf-glob EXAMPLE
 pattern example.com
parameter-map type urlf-glob ALLOW
 pattern *
!
class-map type urlfilter match-any BLOCK
 match  server-domain urlf-glob EXAMPLE
class-map type urlfilter match-any ALLOW
 match  server-domain urlf-glob ALLOW
!
class-map type inspect match-any HTTP
 match protocol http
class-map type inspect match-any HTTPS
 match protocol https
class-map type inspect match-any DNS
 match protocol dns
!
policy-map type inspect urlfilter URL_FILTER
 parameter type urlfpolicy local URL_FILTER
 class type urlfilter BLOCK
  log
  reset
 class type urlfilter ALLOW
  allow
!
policy-map type inspect URLs
 class type inspect HTTP
  inspect
  service-policy urlfilter URL_FILTER
 class type inspect HTTPS
  inspect
 class type inspect DNS
  inspect
 class class-default
  drop
!
zone security LAN
zone security WAN
!
zone-pair security LAN_OUT source LAN destination WAN
 service-policy type inspect URLs
!
interface FastEthernet0/0
 description WAN interface
 zone-member security WAN
!
interface FastEthernet0/1
 description LAN interface

 zone-member security LAN

considerations

• Users are informed that their website request was denied via a customizable error page. 
• Requires complete configuration of Zone Based Firewall, for all security policies.

Conclusion

As we have seen there are many different ways to configure an URL filter, also known as a content filter, on a router. Some considerations which should be made before choosing a method. Do you want to inform users, that they are violating company policy? What type of other security measures are in place, or are planned in the near future. Except domain names, what other criteria do you want to filter. 

Everything you need to know about Ping, and more

Ping is one of - or maybe it is - the first network diagnostic tools invented, and usually the first used in the analyses network issues. 

How does it work

Ping makes use of timed IP/ICMP Echo and Echo Reply messages, as defined by RFC 792 to probe a network host.

Network reachability

An Echo message is simply called a 'ping'. The Echo Reply message is the 'ping reply'. A few simple pings will show if the 2 hosts have their TCP/IP stacks configured correctly and if there are any problems with the routes packets are taking in order to get to the other side, and back (e.i. reachability).

On the right we can look inside such an Echo message before it is send. We see the IP header, which is 20 bytes. It indicates, the source and destination IP addresses, and that it carries an ICMP packet.

Next we see the ICMP header, which is 8 bytes. The ICMP header includes the type information, an Echo Request.

And lastly we see the payload portion, which is indicated as Raw. I'll come back to it later.

On the left we see the ICMP Echo Reply message. Again the first 20 bytes is the IP header, containing the source and destination addresses. Which are now reversed.

Next, the ICMP header, again 8 bytes long, indicating that the message type is an Echo Reply. After the ICMP type field, there is a ICMP code field. The error code, or the type of error. (0<= Code <= 16).

On the right, you see an example of the use of the ICMP code field. In this example I pinged google.com again, but set the Time To Live to 5. Which means that the IP packet is allowed to jump 5 layer-3 hops. Google.com is further away than 5 hops. 

The router 5 hops away who was the last to receive the ICMP Echo packet, responds to indicated, to the sender that it was not able to send the ping to the intended destination. In the IP header, we see the source address of that router.

In he ICMP header contains a ICMP type 11 Time Exceeded message. And it includes the ICMP type code 0: "time to live exceeded in transit". 

Next we see a block called IP in ICMP, this is part of the payload portion which I promised we would come back to. This contains the original IP header plus the first 64 bits or 8 byte of the original datagram's data. Since the ICMP header is 8 bytes, that is what is included in the block called ICMP in ICMP. This data is used by the original sender to match the message to the appropriate process.

In the example on the left we see an ICMP Destination Unreachable message, as a response to a ping that had the 'Do not Fragment' bit set, and exceeded the Maximum Transmission Unit.

Again the IP header contains the source and destination addresses. The source is the router that informs us, that it could not forward the original ICMP Echo message. 

The ICMP header contains the type 3 Destination Unreachable message. And includes the ICMP type code 4: "fragmentation needed and DF set"

And as in the previous example the IP in ICMP and ICMP in ICMP are the original IP and ICMP header.

These examples are obviously just a few of the many possible ICMP message types.

On Cisco routers, characters are used to indicate what type of ICMP reply message was sent back. In the table below you will find an overview of the characters and their description.

Network performance measurement

Apart from connectivity testing ping is also used to measure two types of network performance indicators, latency and bandwidth.

Latency

Latency is the delay data traveling over the network experiences, usually measured in milliseconds.

After the sender of ICMP Echo receives a ICMP Echo Reply message, it compares the time it sent the Echo to the time it received the Echo Reply, and calculates the time difference between the two. This is called the Round Trip Time, more commonly referred to as RTT.

R1#ping 192.168.100.100 size 1500 repeat 2 df-bit

Type escape sequence to abort.
Sending 2, 1500-byte ICMP Echos to 192.168.100.100, timeout is 2 seconds:
Packet sent with the DF bit set
!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 2/16/29 ms

NOTE: Routers make use of queues to store the electrical - or laser - pulses until enough of them are received to have enough information to analyse them. After which the data is sent from these queues to the processor of the router, which also make use of separate queues - commonly known as cache - to store data which it is analyzing. ICMP packets have a low priority. If the router is handling traffic near its capacity it will drop ICMP packet from its queues. 

Available bandwidth 

Ping can also be used to measure the available bandwidth per second. Which becomes less as the latency increases, this will become glaringly obvious from the following example where we will do a ping to IP 192.168.100.100, on a 54Mbit/s 802.11g connection.

54Mbit/s = 54000Kbit/s

(54000Kbit/s / 8bit) / 18 kbyte = 375 packets

R1#ping 192.168.100.100 size 18000 repeat 375

Type escape sequence to abort.

Sending 375, 18000-byte ICMP Echos to 192.168.100.100, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (375/375), round-trip min/avg/max = 12/20/256 ms

We calculate the available bandwidth by dividing the bandwidth by the latency, while compensating for the comma shift. Notice that the bandwidth will drop if packet loss occurs.

((18000 byte X 8 bit X 375 received packets) / 100) / 0.020 xseconds = 27Mbit/s

(54Mbit/s / 100) / 0.020 seconds = 27Mbit/s

0,54 / 0.020 seconds = 27Mbit/s

Size Matters

Keep in mind that there are differences between how different vendors handle the size option of the ping command.

On Cisco equipment the size option specifies the size of the total ping packet, that is IP header, ICMP header, and payload. 

R1#ping 192.168.100.100 size 1500 repeat 2 df-bit

Type escape sequence to abort.
Sending 2, 1500-byte ICMP Echos to 192.168.100.100, timeout is 2 seconds:
Packet sent with the DF bit set
!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 2/16/29 ms

On Juniper equipment, the size option only specifies the payload. So when you want to ping with the DF bit set, at 1500 bytes use the following command:

root@olive> ping 192.168.100.100 size 1472 count 2 do-not-fragment   
PING 192.168.222.100 (192.168.100.100): 1472 data bytes
1480 bytes from 192.168.100.100: icmp_seq=0 ttl=255 time=27.549 ms
1480 bytes from 192.168.100.100: icmp_seq=1 ttl=255 time=34.765 ms

--- 192.168.100.100 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 27.549/31.157/34.765/3.608 ms



Microsoft Windows follows that same logic. The size option only specifies the payload, as seen below:

C:\Users\>ping 192.168.100.100 -l 1472 -n 2 -f

Pinging 192.168.100.100 with 1472 bytes of data:
Reply from 192.168.100.100: bytes=1472 time=3ms TTL=255
Reply from 192.168.100.100: bytes=1472 time=29ms TTL=255

Ping statistics for 192.168.100.100:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:

    Minimum = 3ms, Maximum = 29ms, Average = 16ms

Linux agrees and the size option there also only applies to the payload, as seen below:

$ ping -c 2 -s 1472 -M do 192.168.100.100

PING 192.168.100.100 (192.168.100.100) 1472(1500) bytes of data.

1480 bytes from 192.168.100.100: icmp_seq=1 ttl=255 time=20.6 ms

1480 bytes from 192.168.100.100: icmp_seq=2 ttl=255 time=11.5 ms

--- 192.168.100.100 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 11.566/16.133/20.661/4.549 ms

Ping of Death

The Ping of Death is a ICMP Echo that violates the maximum length of an IP packet as defined in RFC 791 to be 65,535 octets long, including the header. As discussed earlier a IP packet exceeding the MTU, will be fragmented. A lot of operating systems, did not process the IP packet until they had all fragments and then tried to reassemble it. This lead to the overflow of the 16-bit packet buffer, and thus to system crashes, reboots, and kernel panics.

Most operating systems after 1998 are hardened against Ping of Death attacks and even attempt to prevent you from sending one.

The only tool on Windows that allows you to send a Ping of Death packet is Scapy, which you can find here. From the CLI of Scapy you can send the 'special' ping with this command:

>>>send(fragment(IP(dst="192.168.100.100")/ICMP()/("F"*65530)))

Smurf Attack

The Smurf Attack, is an ICMP Echo messages to a broadcast address, with a spoofed source address. Basically burring the uplink of the victim with ping Echo Reply messages of all the hosts on that broadcast domain.

Today's computers, and network equipment is secured against this type of attack. Most operating systems by default, do not reply to ICMP messages directed to the network broadcast address. Also ISPs have taken steps to prevent their customers from sending traffic with an incorrect IP source address. Lastly, both the equipment manufacturers and ISPs are denying any traffic send to broadcast addresses. 
  

You can craft a Smurf Attack packet with Scapy, using the following command:

>>>send(IP(src="192.168.100.100", dst="192.168.100.255")/ICMP())

With Nping, use the following command:

nping --icmp -S 192.168.100.100 192.168.100.255

ICMP Nuke

An ICMP Nuke is denial of service attack, based on a spoofed ICMP Destination Unreachable message or a spoofed ICMP Time Exceeded message. The aim of this attack is that target system breaks communications with existing connection(s). Technically it is not a "ping", but was sometimes called a Ping Nuke.


An ICMP Nuke can require some brute-forcing depending on the communication protocol attacked. For both TCP and UDP protocols, the source port needs to be guessed. And for the TCP based protocols, the sequence number needs to be guessed.

This type was a very popular type of attack against IRC channel operators, where the hacker had the aim to takeover the the channel. On the right you see an example of such an ICMP Nuke packet directed at the host IP 192.168.100.100.

Today this type of attack is more difficult to perform, because most routers are rate-limiting ICMP Destination Unreachable, and ICMP Time Exceeded messages. And modern operating system also implement random sequence number generation, making it difficult to predict them accurately.

Ping Tunnel

A ping tunnel (also known as ICMPTX), is a tunneling where the payload portion of ping packets are used to carry TCP sessions, between a client and a proxy server. This is usually done to circumvent a firewall. You can find the original implementation of this protocol here.

Transparent Ethernet over an IP network

In today's corporate networks the layer-2 domain is collapsed down to the access layer - at least it should be, in most cases -, and there is virtually no requirement for a contiguous layer-2 domain passed the access layer switches.

However there are corner cases where extending the layer-2 domain across a layer-3 network is a requirement. For example server visualization may require the storage network to be on the same layer-2 domain. Or when a layer-2 interconnect circuit is backed up by a cheap(er) layer-3 circuit. 

I'll discuss various technologies to accomplish transparent Ethernet over an IP network and present sample configurations, for them.

In the topology we will be using for the sample configurations are two routers (i.e R1 and R2) connected back-to-back. R1 will have a loopback interface configured with the IP 1.1.1.1 and R2 will have a loopback with the IP 2.2.2.2. The physical back-to-back interfaces are configured on the 10.0.0.0/30 subnet, R1 has the IP 10.0.0.1 and R2 - how surprising - has 10.0.0.2. The routing is done through a static route, pointing to the IP address of other router's physical interface.

GRE Tunnel

Generic Routing Encapsulation (GRE) is a mechanism for encapsulating any network layer protocol over any other network layer protocol, developed by Cisco. The general specification is described in RFC 2784 (obsoletes earlier RFC 1701 and RFC 1702). 

Configuration example:

R1:

!

bridge irb

!

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

 no ip address

 bridge-group 1

!

interface Tunnel0

 no ip address

 tunnel source Loopback0

 tunnel destination 2.2.2.2

 bridge-group 1

!

interface Serial0/0

 ip address 10.0.0.1 255.255.255.252

!

ip route 2.2.2.2 255.255.255.255 10.0.0.2

!

R2:

!
bridge irb
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 bridge-group 1
!
interface Tunnel0
 no ip address
 tunnel source Loopback0
 tunnel destination 1.1.1.1
 bridge-group 1
!
interface Serial0/0
 ip address 10.0.0.2 255.255.255.252
!
ip route 1.1.1.1 255.255.255.255 10.0.0.1
!

considerations

• Supports Dot1Q, and ISL VLAN trunking, depending on the routing platform.
• Integrated Routing and Bridging does NOT support transparent tunneling of CDP, STP, VTP, LLDP, PAgP, LACP, and UDLD.
• The MTU of the sending device may need to be adjusted, Integrated Routing and Bridging does NOT support fragmentation.
• Native support for tunneling over an IPv6 network.

More information about Generic Routing Encapsulation on the Cisco website can be found here.

DLSw+ circuit

Data-Link Switching is an almost forgotten technology, originally developed to tunnel non-routable, non-IP based protocols such as IBM Systems Network Architecture (SNA) and NetBIOS/NetBEUI across IP networks, described in RFC 1434 (updated by RFC 2166). 

DLSw+ is Cisco's proprietary implementation of DLSw, with following extensions:

• Choice of transport option, including TCP, FST (fast-sequenced transport), and direct encapsulation.
• Scalability enhancements through: peer groups, on-demand peers, explorer firewalls, and location learning.
• Media conversion between local and remote LANs and SDLC or Ethernet.

One of the more popular uses of DLSw+, was bridging Token ring networks over other media. 

DLSw+ is a flexible, though dated technology that can transport of Ethernet frames across an IP network.

Configuration example:


R1:

!
bridge irb
!
dlsw local-peer peer-id 1.1.1.1
dlsw remote-peer 0 tcp 2.2.2.2
dlsw bridge-group 1
!

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

 no ip address

 bridge-group 1

!

interface Serial0/0

 ip address 10.0.0.1 255.255.255.252

!

ip route 2.2.2.2 255.255.255.255 10.0.0.2

!

R2:

!
bridge irb
!
dlsw local-peer peer-id 2.2.2.2
dlsw remote-peer 0 tcp 1.1.1.1
dlsw bridge-group 1
!

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet0/0

 no ip address

 bridge-group 1

!

interface Serial0/0

 ip address 10.0.0.2 255.255.255.252

!

ip route 1.1.1.1 255.255.255.255 10.0.0.1

!

considerations

• Supports Dot1Q, and ISL VLAN trunking, depending on the routing platform.
• Integrated Routing and Bridging does NOT support transparent tunneling of CDP, STP, VTP, LLDP, PAgP, LACP, and UDLD.
• The MTU of the sending device may need to be adjusted, Integrated Routing and Bridging does NOT support fragmentation.
• NO native support for tunneling over an IPv6 network.
• DLSw+ is process switched.
• NO support for DLSw+, on any Cisco IOS XE, IOS RX, or NX-OS platform.
• Support for DLSw+ is only available on legacy Multi-Layer Switches, for example the CAT4500, and the CAT6000.

More information about Data-Link Switching (DLSw) and Data-Link Switching Plus (DLSw+) on the Cisco website can be found here.

L2TP Tunnel

Layer-2 Tunneling Protocol, described in RFC 2661, is based on primarily two older tunneling protocols for Point-to-Point communication: Cisco's Layer 2 Forwarding Protocol (L2F) and USRobotics Point-to-Point Tunneling Protocol (PPTP). The original L2TP implementation uses UDP for transport. The newer L2TP version 3, described in RFC 3931 (updated by RFC 5641), uses IP as transport - just like GRE -, that can be implemented on any IP-aware network. L2TPv3 has two 'modes' point-to-point and point-to-multipoint. We will be focusing exclusively on L2TPv3 point-to-point mode tunneling.

Configuration example:

R1:

!

pseudowire-class TEST

 encapsulation l2tpv3

 ip local interface Loopback0

!

interface Loopback0

 ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

 no ip address

 no cdp enable

 xconnect 2.2.2.2 1 encapsulation l2tpv3 pw-class TEST

!

interface Serial0/0

 ip address 10.0.0.1 255.255.255.252

!

ip route 2.2.2.2 255.255.255.255 10.0.0.2

!

R2:

!

pseudowire-class TEST

 encapsulation l2tpv3

 ip local interface Loopback0

!

interface Loopback0

 ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet0/0

 no ip address

 no cdp enable

 xconnect 1.1.1.1 1 encapsulation l2tpv3 pw-class TEST

!

interface Serial0/0

 ip address 10.0.0.2 255.255.255.252

!

ip route 1.1.1.1 255.255.255.255 10.0.0.1

!

considerations

• Cisco Express Forwarding must be enabled. The xconnect configuration mode is inaccessible until CEF is enabled.
• Native support for tunneling over an IPv6 network.
• The MTU of the sending device may need to be adjusted, to prevent fragmentation. The ingress router receives an Ethernet frame and encapsulates the packet by removing the preamble, the start of frame delimiter (SFD), and the frame check sequence (FCS), inserts the frame into a L2TPv3 packet and transmits the packet to its peer.
• You may need to configure the l2protocol-tunnel command to enable or disable tunneling of Layer 2 protocols (e.i. CDP, STP, VTP, LLDP, PAgP, LACP, and UDLD) depending on the platform. In my test environment (GNS3, c3725, IOS 124-15.T8) CDP was tunneled transparently.

More information about Layer Two Tunnel Protocol (L2TP) on the Cisco website can be found here.

EoMPLS over GRE Tunnel

Ethernet over Multi Protocol Label Switching is a mechanism to encapsulate and transport Ethernet Protocol Data Units (PDUs) over an MPLS network, and is described in RFC 4448 (updated by RFC 5462). Basically a frame is received on a switch, MPLS labels the frame, transportes it via MPLS labels over an IP routed network, and the receiving switch removes the MPLS label, and switches the frame out the appropriate port(s).

EoMPLS is the most common method Internet Service Providers use to implement Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS), on their networks.

MPLS requires every hop in the path to be an MPLS router. Here is where the GRE Tunnel comes in to play. We will use GRE to tunnel the MPLS traffic, end-to-end.

Configuration example:

R1:

!
ip cef
!
mpls ip 
!
interface Tunnel0
 ip address 172.16.1.1 255.255.255.252
 mpls ip
 tunnel source Serial1/0
 tunnel destination 192.168.100.4
!
interface FastEthernet0/0
 no ip address
 no cdp enable
 xconnect 172.16.1.2 1 encapsulation mpls
!
interface Serial1/0
 ip address 192.168.100.1 255.255.255.0
!
mpls ldp router-id Tunnel0 force
!

R2:

!
ip cef
!
mpls ip 
!
interface Tunnel0
 ip address 172.16.1.2 255.255.255.252
 mpls ip
 tunnel source Serial1/0
 tunnel destination 192.168.100.1
!
interface FastEthernet0/0
 no ip address
 no cdp enable
 xconnect 172.16.1.1 1 encapsulation mpls
!
interface Serial1/0
 ip address 192.168.100.4 255.255.255.0
!
mpls ldp router-id Tunnel0 force

!

NOTE: In the configuration above I used the 172.16.1.0/30 IP address range on the tunnel interface. Also the Tunnel interface on the platform used defaults to tunnel mode gre ip.

considerations

• Cisco Express Forwarding must be enabled. The xconnect configuration mode is inaccessible until CEF is enabled.
• Native support for tunneling over an IPv6 network.
• The MTU of the sending device may need to be adjusted, to prevent fragmentation. The ingress router receives an Ethernet frame and encapsulates the packet by removing the preamble, the start of frame delimiter (SFD), and the frame check sequence (FCS), inserts the frame into a MPLS packet and transmits the packet to its peer.
• You may need to configure the l2protocol-tunnel command to enable or disable tunneling of Layer 2 protocols (e.i. CDP, STP, VTP, LLDP, PAgP, LACP, and UDLD) depending on the platform. In my test environment (GNS3, c7200, IOS 150-1.M) CDP was tunneled transparently.

More information about Multi Protocol Label Switching (MPLS) on the Cisco website can be found here.

Conclusion

Both the 'vanilla' GRE Tunnel and the DLSw+ circuit use the Integrated Routing and Bridging feature to span the Ethernet across the layer-3 network. And therefore these two methods carry the same limitations as a single router bridging two layer-2 domains, using the IRB feature. You can either bridge a normal Ethernet connection, a single VLAN or a Trunk, per bridge group. Since the router is not a switch it does not support DTP or VTP, nor will it transparently carry those and other layer-2 protocols (e.g. CDP, STP) - since the router is a layer-2 hop, just like a switch.

For more information about Integrated Routing and Bridging (IRB) see the Cisco website here.

As mentioned earlier DLSw+ in not supported on any of the Cisco IOS XE, IOS RX, or NX-OS platforms. Also the protocol is process switched which may require extensive tuning, you can find an excellent post about tuning DLSw performance here, on the Packetpushers website.

Of all the methods described, L2TPv3 and EoMPLS over GRE are the most powerful and flexible, providing truly transparent Ethernet, allowing you to implement it as a trunk or per VLAN. The per VLAN method allows you to transport different VLANs to different endpoints, or even mix layer-2 and layer-3 features on a single port, using sub-interfaces. Big downsides are - yes, there are downsides - that It also may also tempt you as a network engineer to be too clever; creating a real unholy mess of layer-2 over layer-3 confusion, which is not fun to troubleshoot.