Implementing Tunnels

BSTUN

A Block Serial Tunnel (BSTUN) enables support for devices using the Bisync data-link protocol. This protocol enables enterprises to transport Bisync traffic over the same network that supports their Systems Network Architecture (SNA) and multiprotocol traffic, eliminating the need for separate Bisync facilities.

For more details about configuring BSTUN, see the "Configuring Serial Tunnel and Block Serial Tunnel" module in the Cisco IOS Bridging and IBM Networking Configuration Guide.

CLNS

The ISO Connectionless Network Service (CLNS) protocol is a standard for the network layer of the OSI model. IP traffic can be transported over CLNS; for instance, on the data communications channel (DCC) of a SONET ring. An IP over CLNS tunnel (CTunnel) is a virtual interface that enhances interactions with CLNS networks, allowing IP packets to be tunneled through the Connectionless Network Protocol (CLNP) to preserve TCP/IP services. CLNS can also be used as a transport protocol with GRE as a carrier protocol (GRE/CLNS), carrying both IPv4 and IPv6 packets.

DLSw+

Data-link switching plus (DLSw+) is Cisco's implementation of the DLSw standard for Systems Network Architecture (SNA) and NetBIOS devices, and it supports several additional features and enhancements. DLSw+ is a means of transporting SNA and NetBIOS traffic over a campus or WAN. The end systems can attach to the network over Token Ring, Ethernet, Synchronous Data Link Control (SDLC), Qualified Logical Link Control (QLLC), or Fiber Distributed Data Interface (FDDI). DLSw+ switches between diverse media and locally terminates the data links, keeping acknowledgments, keepalives, and polling off the WAN.

For more details about configuring DLSw+, see the "Configuring Data-Link Switching Plus" module in the Cisco IOS Bridging and IBM Networking Configuration Guide .

GRE

Generic routing encapsulation (GRE) is defined in RFC 2784. GRE is a carrier protocol that can be used with a variety of underlying transport protocols, and GRE can carry a variety of passenger protocols. RFC 2784 also covers the use of GRE with IPv4 as the transport protocol and the passenger protocol. Cisco IOS software supports GRE as the carrier protocol with many combinations of passenger and transport protocols.

For more details about GRE, see the Generic Routing Encapsulation.

IP-in-IP

IP-in-IP is a Layer 3 tunneling protocol--defined in RFC 2003--that alters the normal routing of an IP packet by encapsulating it within another IP header. The encapsulating header specifies the address of a router that would not ordinarily be selected as a next-hop router on the basis of the real destination address of the packet. The intermediate node decapsulates the packet, which is then routed to the destination as usual.

IPsec

In simple terms, IP Security (IPsec) provides secure tunnels between two peers, such as two routers. You define which packets are considered sensitive and should be sent through these secure tunnels, and you define the parameters that should be used to protect these packets by specifying characteristics of these tunnels. IPsec peers set up a secure tunnel and encrypt the packets that traverse the tunnel to the remote peer.

IPsec also works with the GRE and IP-in-IP, L2F, L2TP, and DLSw+ tunneling protocols; however, multipoint tunnels are not supported. Other Layer 3 tunneling protocols may not be supported for use with IPsec.

For more details about configuring IPSec, see the "Configuring Security for VPNs with IPSec" module in the Cisco IOS Security Configuration Guide.

IPv6

IP version 6 (IPv6) is a new version of the Internet Protocol based on and designed as the successor to IP version 4. IPv6 adds a much larger address space--128 bits--and improvements such as a simplified main header and extension headers. IPv6 is described initially in RFC 2460, Internet Protocol, Version 6 (IPv6) . The use of IPv6 as a carrier protocol is described in RFC 2473, Generic Packet Tunneling in IPv6 Specification .

L2F

Layer 2 Forwarding (L2F) tunneling is used in virtual private dialup networks (VPDNs). A VPDN allows separate and autonomous protocol domains to share common access infrastructure including modems, access servers, and ISDN routers by the tunneling of link-level (Layer 2) frames. Typical L2F tunneling use includes Internet service providers (ISPs) or other access service creating virtual tunnels to link to remote customer sites or remote users with corporate intranet or extranet networks.

L2TP

Layer 2 Tunneling Protocol (L2TP) is an open standard created by the Internet Engineering Task Force (IETF) that uses the best features of L2F and Point-to-Point Tunneling Protocol (PPTP). L2TP is designed to secure the transmission of IP packets across uncontrolled and untrusted network domains, and it is an important component of Virtual Private Networks (VPNs). VPNs extend remote access to users over a shared infrastructure while maintaining the same security and management policies as a private network.

For more details about configuring L2TP, see the Cisco IOS Dial Technologies Configuration Guide.

MPLS

Multiprotocol Label Switching (MPLS) is a high-performance packet forwarding technology that integrates the performance and traffic management capabilities of data-link-layer (Layer 2) switching with the scalability, flexibility, and performance of network-layer (Layer 3) routing. The MPLS architecture has been designed to allow data to be transferred over any combination of Layer 2 technologies, to support all Layer 3 protocols, and to scale. Using CEF, MPLS can efficiently enable the delivery of IP services over an ATM switched network. MPLS is an integration of Layer 2 and Layer 3 technologies. By making traditional Layer 2 features available to Layer 3, MPLS enables traffic engineering.

For more details about how MPLS traffic engineering uses tunnels, see the Cisco IOS Multiprotocol Label Switching Configuration Guide.

PPPoA

PPP over ATM (PPPoA) is mainly implemented as part of Asymmetric Digital Subscriber Line (ADSL). It relies on RFC 1483, operating in either Logical Link Control-Subnetwork Access Protocol (LLC-SNAP) or VC-Mux mode. A customer premises equipment (CPE) device encapsulates the PPP session based on this RFC for transport across the ADSL loop and the digital subscriber line access multiplexer (DSLAM).

PPPoE

RFC 2516 defines PPP over Ethernet (PPPoE) as providing the ability to connect a network of hosts over a simple bridging access device to a remote access concentrator or aggregation concentrator. As customers deploy ADSL, they must support PPP-style authentication and authorization over a large installed base of legacy bridging customer premises equipment (CPE). Using a form of tunneling encapsulation, PPPoE allows each host to use its own PPP stack, thus presenting the user with a familiar user interface. Access control, billing, and type of service (ToS) can be done on a per-user, rather than a per-site, basis.

For more details about configuring PPPoE, see the Cisco IOS Broadband Access Aggregation and DSL Configuration Guide.

PPTP

Point-to-Point Tunneling Protocol (PPTP) is a network protocol that enables the secure transfer of data from a remote client enterprise server by creating a VPN across TCP/IP data networks. PPTP supports on-demand, multiprotocol virtual private networking over public networks such as the Internet.

RBSCP

Rate-Based Satellite Control Protocol (RBSCP) was designed for wireless or long-distance delay links with high error rates, such as satellite links. Using tunnels, RBSCP can improve the performance of certain IP protocols, such as TCP and IP Security (IPsec), over satellite links without breaking the end-to-end model.

SSL Tunnels

Secure Socket Layer (SSL) is designed to make use of TCP sessions to provide a reliable end-to-end secure service. The main role of SSL is to provide security for web traffic. Security includes confidentiality, message integrity, and authentication. SSL achieves these elements of security through the use of cryptography, digital signatures, and certificates. SSL protects confidential information through the use of cryptography. Sensitive data is encrypted across public networks to achieve a level of confidentiality.

SSL is implemented using the Cisco Application and Content Networking System (ACNS). For more details about configuring SSL, see the latest Cisco ACNS Software Deployment and Configuration Guide .

STUN

Cisco's Serial Tunneling (STUN) implementation allows Synchronous Data Link Control (SDLC) protocol devices and High-Level Data Link Control (HDLC) devices to connect to one another through a multiprotocol internetwork rather than through a direct serial link. STUN encapsulates SDLC frames in either the TCP/IP or the HDLC protocol. STUN provides a straight passthrough of all SDLC traffic (including control frames, such as Receiver Ready) end-to-end between Systems Network Architecture (SNA) devices.

For more details about configuring STUN, see the "Configuring Serial Tunnel and Block Serial Tunnel" module in the Cisco IOS Bridging and IBM Networking Configuration Guide .

UDLR Tunnels

Unidirectional link routing (UDLR) provides mechanisms for a router to emulate a bidirectional link to enable the routing of unicast and multicast packets over a physical unidirectional interface, such as a broadcast satellite link. However, there must be a back channel or other path between the routers that share a physical unidirectional link (UDL). A UDLR tunnel is a mechanism for unicast and multicast traffic; Internet Group Management Protocol (IGMP) UDLR is a related technology for multicast traffic.

For more details, see Cisco IOS IP Multicast Configuration Guide.

PE to PE GRE Tunnels

In the PE to PE GRE tunnels scenario, a customer does not generally transition any part of the core to MPLS but prefers to offer EoMPLS and basic MPLS VPN services. Hence, GRE tunneling of the MPLS labeled traffic is done between PEs. This is the most common scenario seen in various customers networks.

P to P GRE Tunnels

The P to P GRE tunnels scenario is one where MPLS has been enabled between PE and P routers, but the network core may have non-MPLS-aware routers or IP encryption boxes. In this scenario, GRE tunneling of the MPLS labeled packets is done between P routers.

PE to P GRE Tunnels

The PE to P GRE tunnels scenario demonstrates a network where the P to P nodes are MPLS-aware, while GRE tunneling is done between a PE to P non MPLS network segment.

The following features are required for the deployment of scenarios described above:

GRE Specific:

• Tunnel endpoints can be loopbacks or physical interfaces.
• Configurable tunnel keepalive timer parameters per end point, and syslog message must be generated when the keepalive timer expires.
• BFD support for tunnel failures and for IGPs using tunnels.
• IGP loadsharing across GRE tunnels.
• IGP redundancy across GRE tunnels.
• Fragmentation across GRE tunnels.
• Ability to pass jumbo frames.
• Support for all IGP control plane traffic.
• Support for IP TOS preservation across tunnel.
• Tunnel should be independent of endpoint physical interface types such as POS, Gig, TenGig, and ATM.
• Support for up to 100 GRE tunnels.

EoMPLS Specific:

• Port mode EoMPLS.
• VLAN mode EoMPLS.
• Pseudowire redundancy.
• AToM sequencing.
• Tunnel selection--ability to map a specific pseudowire or pw-class to a GRE tunnel.
• IGP loadsharing and redundancy. See below for more information.
• Support for up to 200 EoMPLS VCs.

MPLS-VPN Specific:

• Support for PE Role with IPv4 VRFs
• Support for all PE-CE protocols
• Load sharing through multiple tunnels and equal-cost IGP paths with a single tunnel
• Support for redundancy via unequal-cost IGP paths with a single tunnel
• Support for the IP Precedence value being copied onto the EXP bits field of the MPLS label, and then onto the Precedence bits on the outer IPv4 ToS field of the GRE packet.

For a sample configuration sequence of EoMPLS over GRE, see Example Configuring EoMPLS over GRE. For more details about EoMPLS over GRE, see Deploying and Configuring MPLS Virtual Private Networks In IP Tunnel Environments .

Example

2001:0DB8:1234:5678:0000:5EFE:0AAD:8108

RBSCP tunnels can be configured for any of the following features:

• Time Delay --One of the RBSCP routers can be configured to hold frames due for transmission through the RBSCP tunnel. The delay time increases the RTT at the end host and allows RBSCP time to retransmit lost TCP frames or other protocol frames. If the retransmission is successful, it prevents lost frame events from reaching the end host where congestion procedures would be enabled. In some cases, the retransmission can be completed by RBSCP without inserting the delay. This option should be used only when the RTT of the satellite link is greater than 700 milliseconds.
• ACK Splitting --Performance improvements can be made for clear-text TCP traffic using acknowledgement (ACK) splitting in which a number of additional TCP ACKs are generated for each TCP ACK received. TCP will open a congestion window by one maximum transmission unit (MTU) for each TCP ACK received. Opening the congestion window results in increased bandwidth becoming available. Configure this feature only when the satellite link is not using all the available bandwidth. Encrypted traffic cannot use ACK splitting.
• Window Stuffing --Clear-text TCP and SCTP traffic can benefit from the RBSCP window stuffing feature. RBSCP can buffer traffic so that the advertised window can be incremented up to the available satellite link bandwidth or the available memory in the router. The end host that sends the packets is fooled into thinking that a larger window exists at the receiving end host and sends more traffic. Use this feature with caution because the end host may send too much traffic for the satellite link to handle and the resulting loss and retransmission of packets may cause link congestion.
• SCTP Drop Reporting --SCTP uses an appropriate byte counting method instead of ACK counting to determine the size of the transmission window, so ACK splitting does not work with SCTP. The RBSCP tunnel can generate an SCTP packet-dropped report for packets dropped across the satellite but not as a result of congestion loss. This SCTP drop reporting is on by default and provides a chance to retransmit the packet without affecting the congestion window size. Actual congestion losses are still reported, and normal recovery mechanisms are activated.

Before configuring a tunnel, you must determine what type of tunnel you need to create.

Perform this task to configure a GRE tunnel on an IPv6 network. GRE tunnels can be configured to run over an IPv6 network layer and transport IPv6 and IPv4 packets through IPv6 tunnels.

This task explains how to configure the source and destination of a tunnel to belong to any virtual private network (VPN) routing/forwarding (VRFs) tables

Note

Cisco 10000 Series Routers The VRF associated with the tunnel vrf command is the same as the VRF associated with the physical interface over which the tunnel sends packets (outer IP packet routing). The VRF associated with the tunnel by using the ip vrf forwarding command is the VRF that the packets are to be forwarded in as the packets exit the tunnel (inner IP packet routing). The Cisco 10000 series router does not support the fragmentation of multicast packets passing through a multicast tunnel. >

This task explains how to configure a manual IPv6 overlay tunnel.

This task explains how to configure a 6to4 overlay tunnel.

This task explains how to configure an IPv4-compatible IPv6 overlay tunnel.

This task describes how to configure an ISATAP overlay tunnel.

Perform this task to configure the RBSCP tunnel. Remember to configure the router at each end of the tunnel.

This optional task explains how to verify tunnel configuration and operation. The commands contained in the task steps can be used in any sequence and may need to be repeated. The following commands can be used for GRE tunnels, IPv6 manually configured tunnels, and IPv6 over IPv4 GRE tunnels. This process includes the following general steps (details follow):

• On Router A, ping the IP address of the CTunnel interface of Router B.
• On Router B, ping the IP address of the CTunnel interface of Router A.

The following example shows a simple configuration of GRE tunneling. Note that Ethernet interface 0/1 is the tunnel source for Router A and the tunnel destination for Router B. Fast Ethernet interface 0/1 is the tunnel source for Router B and the tunnel destination for Router A.

Router A

interface Tunnel0
 ip address 10.1.1.2 255.255.255.0
 tunnel source Ethernet0/1
 tunnel destination 192.168.3.2
 tunnel mode gre ip
!
interface Ethernet0/1
 ip address 192.168.4.2 255.255.255.0

Router B

interface Tunnel0
 ip address 10.1.1.1 255.255.255.0
 tunnel source FastEthernet0/1
 tunnel destination 192.168.4.2
 tunnel mode gre ip
!
interface FastEthernet0/1
 ip address 192.168.3.2 255.255.255.0

The following example configures a GRE tunnel running both IS-IS and IPv6 traffic between Router A and Router B.

Router A

ipv6 unicast-routing
clns routing
!
interface Tunnel0
 no ip address
 ipv6 address 2001:0DB8:1111:2222::1/64
 ipv6 router isis 
 tunnel source Ethernet0/0
 tunnel destination 10.0.0.2
 tunnel mode gre ip
!
interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.0
!
router isis 
 network 49.0000.0000.000a.00

Router B

ipv6 unicast-routing
clns routing
!
interface Tunnel0
 no ip address
 ipv6 address 2001:0DB8:1111:2222::2/64
 ipv6 router isis 
 tunnel source Ethernet0/0
 tunnel destination 10.0.0.1
 tunnel mode gre ip
!
interface Ethernet0/0
 ip address 10.0.0.2 255.255.255.0
!
router isis 
 network 49.0000.0000.000b.00
 address-family ipv6
 redistribute static
 exit-address-family

The following example shows how to configure a GRE tunnel over an IPv6 transport. In this example, Ethernet0/0 has an IPv6 address, and this is the source address used by the tunnel interface. The destination IPv6 address of the tunnel is specified directly. In this example, the tunnel carries both IPv4 and IS-IS traffic.

interface Tunnel0
 ip address 10.1.1.1 255.255.255.0
 ip router isis 
 tunnel source Ethernet0/0
 tunnel destination 2001:DB8:1111:2222::1
 tunnel mode gre ipv6
!
interface Ethernet0/0
 no ip address
 ipv6 address 2001:DB8:1111:1111::1/64
!
router isis 
 net 49.0001.0000.0000.000a.00

In this example, packets received on interface e0 using VRF green, will be forwarded out of the tunnel through interface e1 using VRF blue. The figure below shows a simple tunnel scenario:

Figure 9

GRE Tunnel Diagram

The following example shows the configuration for the tunnel in the figure above.

ip vrf blue
 rd 1:1
ip vrf green
 rd 1:2
interface loopback0
 ip vrf forwarding blue
 ip address 10.7.7.7 255.255.255.255
interface tunnel0
 ip vrf forwarding green
 ip address 10.3.3.3 255.255.255.0
 tunnel source loopback 0
 tunnel destination 10.5.5.5
 tunnel vrf blue
interface ethernet0
 ip vrf forwarding green
 ip address 10.1.1.1 255.255.255.0
interface ethernet1
 ip vrf forwarding blue
 ip address 10.2.2.2 255.255.255.0
 ip route vrf blue 10.5.5.5 255.255.255.0 ethernet 1

The figure below is an example of connecting multiprotocol subnetworks across a single-protocol backbone. The configurations of Router A and Router B follow the figure.

Figure 10

Connecting AppleTalk Networks Across an IP-Only Backbone

Router A

interface ethernet 0
 description physics department AppleTalk LAN
 appletalk cable-range 4001-4001 32
 !
interface fddi 0
 description connection to campus backbone
 ip address 10.0.8.108 255.255.255.0
interface tunnel 0
 tunnel source fddi 0
 tunnel destination 10.0.21.20
 appletalk cable-range 5313-5313 1

Router B

interface ethernet 0
 description chemistry department AppleTalk LAN
 appletalk cable-range 9458-9458 3
 !
interface fddi 0
 description connection to campus backbone
 ip address 10.0.21.20 255.255.255.0
interface tunnel 0
 tunnel source fddi 0
 tunnel destination 10.0.8.108
 appletalk cable-range 5313-5313 2

The figure below is an example of routing a private IP network and a Novell network across a public service provider. The configurations of Router A and Router B follow the figure.

Figure 11

Creating Virtual Private Networks Across WANs

Router A

interface ethernet 0
 description Boston office
 ip address 10.1.1.1 255.255.255.0
 novell network 1e
!
interface serial 0
 description connection to public service provider
 ip address 172.17.2.1 255.255.255.0
!
interface tunnel 0
 tunnel source serial 0
 tunnel destination 172.28.5.2
 ip address 10.1.2.1 255.255.255.0
 novell network 1f

Router B

interface ethernet 0
 description Menlo Park office
 ip address 10.1.3.1 255.255.255.0
 novell network 31
 !
interface serial 4
 description connection to public service provider
 ip address 172.28.5.2 255.255.255.0
 !
interface tunnel 0
 tunnel source serial 4
 tunnel destination 172.17.2.1
 ip address 10.1.2.2 255.255.255.0
 novell network 1f

The figure below illustrates the creation of a CTunnel between Router A and Router B, as accomplished in the configuration examples that follow.

Figure 12

Creation of a CTunnel

Router A

ip routing
clns routing
interface ctunnel 102
 ip address 10.0.0.1 255.255.255.0
 ctunnel destination 49.0001.2222.2222.2222.00
interface Ethernet0/1
 clns router isis 
router isis 
 network 49.0001.1111.1111.1111.00
router rip 
 network 10.0.0.0

Router B

ip routing
clns routing
interface ctunnel 201
 ip address 10.0.0.2 255.255.255.0
 ctunnel destination 49.0001.1111.1111.1111.00
interface Ethernet0/1
 clns router isis 
router isis
 network 49.0001.2222.2222.2222.00
router rip
 network 10.0.0.0

The following example configures a GRE CTunnel running both IS-IS and IPv6 traffic between Router A and Router B in a CLNS network. The ctunnel mode gre command provides a method of tunneling that is compliant with RFC 3147 and should allow tunneling between Cisco equipment and third-party networking devices.

Router A

ipv6 unicast-routing 
clns routing 
interface ctunnel 102 
 ipv6 address 2001:0DB8:1111:2222::1/64
 ctunnel destination 49.0001.2222.2222.2222.00 
 ctunnel mode gre
interface Ethernet0/1 
 clns router isis 
router isis 
 network 49.0001.1111.1111.1111.00

Router B

ipv6 unicast-routing 
clns routing 
interface ctunnel 201 
 ipv6 address 2001:0DB8:1111:2222::2/64 
 ctunnel destination 49.0001.1111.1111.1111.00 
 ctunnel mode gre
interface Ethernet0/1 
 clns router isis 
router isis 
 network 49.0001.2222.2222.2222.00

To turn off GRE mode and restore the CTunnel to the default Cisco encapsulation routing only between endpoints on Cisco equipment, use either the no ctunnel mode command or the ctunnel mode cisco command. The following example shows the same configuration modified to transport only IPv4 traffic.

Router A

ip routing 
clns routing 
interface ctunnel 102 
 ip address 10.2.2.5 255.255.255.0 
 ctunnel destination 49.0001.2222.2222.2222.00 
 ctunnel mode cisco
interface Ethernet0/1 
 clns router isis 
router isis 
 network 49.0001.1111.1111.1111.00 

Router B

ip routing 
clns routing 
interface ctunnel 201 
 ip address 10.0.0.5 255.255.255.0 
 ctunnel destination 49.0001.1111.1111.1111.00 
 ctunnel mode cisco
interface Ethernet0/1 
 clns router isis 
router isis 
 network 49.0001.2222.2222.2222.00

The following example configures a manual IPv6 tunnel between Router A and Router B. In the example, tunnel interface 0 for both Router A and Router B is manually configured with a global IPv6 address. The tunnel source and destination addresses are also manually configured.

Router A

interface ethernet 0
 ip address 192.168.99.1 255.255.255.0
interface tunnel 0
 ipv6 address 2001:0db8:c18:1::3/126
 tunnel source ethernet 0
 tunnel destination 192.168.30.1
 tunnel mode ipv6ip

Router B

interface ethernet 0
 ip address 192.168.30.1 255.255.255.0
interface tunnel 0
 ipv6 address 2001:0db8:c18:1::2/126
 tunnel source ethernet 0
 tunnel destination 192.168.99.1
 tunnel mode ipv6ip

The following example configures a 6to4 tunnel on a border router in an isolated IPv6 network. The IPv4 address is 192.168.99.1, which translates to the IPv6 prefix of 2002:c0a8:6301::/48. The IPv6 prefix is subnetted into 2002:c0a8:6301::/64 for the tunnel interface: 2002:c0a8:6301:1::/64 for the first IPv6 network and 2002:c0a8:6301:2::/64 for the second IPv6 network. The static route ensures that any other traffic for the IPv6 prefix 2002::/16 is directed to tunnel interface 0 for automatic tunneling.

interface Ethernet0
 description IPv4 uplink
 ip address 192.168.99.1 255.255.255.0
!
interface Ethernet1
 description IPv6 local network 1
 ipv6 address 2002:c0a8:6301:1::1/64 
!
interface Ethernet2
 description IPv6 local network 2
 ipv6 address 2002:c0a8:6301:2::1/64 
!
interface Tunnel0
 description IPv6 uplink
 no ip address
 ipv6 address 2002:c0a8:6301::1/64 
 tunnel source Ethernet0
 tunnel mode ipv6ip 6to4
!
ipv6 route 2002::/16 Tunnel0

The following example configures an IPv4-compatible IPv6 tunnel that allows BGP to run between a number of routers without having to configure a mesh of manual tunnels. Each router has a single IPv4-compatible tunnel, and multiple BGP sessions can run over each tunnel, one to each neighbor. Ethernet interface 0 is used as the tunnel source. The tunnel destination is automatically determined by the IPv4 address in the low-order 32 bits of an IPv4-compatible IPv6 address. Specifically, the IPv6 prefix 0:0:0:0:0:0 is concatenated to an IPv4 address (in the format 0:0:0:0:0:0:A.B.C.D or ::A.B.C.D) to create the IPv4-compatible IPv6 address. Ethernet interface 0 is configured with a global IPv6 address and an IPv4 address (the interface supports both the IPv6 and IPv4 protocol stacks).

Multiprotocol BGP is used in the example to exchange IPv6 reachability information with the peer 10.67.0.2. The IPv4 address of Ethernet interface 0 is used in the low-order 32 bits of an IPv4-compatible IPv6 address and is also used as the next-hop attribute. Using an IPv4-compatible IPv6 address for the BGP neighbor allows the IPv6 BGP session to be automatically transported over an IPv4-compatible tunnel.

interface tunnel 0
 tunnel source Ethernet 0
 tunnel mode ipv6ip auto-tunnel
interface ethernet 0
 ip address 10.27.0.1 255.255.255.0
 ipv6 address 3000:2222::1/64
router bgp 65000
 no synchronization
 no bgp default ipv4-unicast
 neighbor ::10.67.0.2 remote-as 65002
address-family ipv6
 neighbor ::10.67.0.2 activate
 neighbor ::10.67.0.2 next-hop-self
 network 2001:2222:d00d:b10b::/64

The following example shows the tunnel source defined on Ethernet 0 and the tunnel mode command used to configure the ISATAP tunnel. Router advertisements are enabled to allow client autoconfiguration.

interface Tunnel1
 tunnel source ethernet 0
 tunnel mode ipv6ip isatap
 ipv6 address 2001:0DB8::/64 eui-64
 no ipv6 nd suppress-ra

In the following example, Router 1 and Router 2 are configured to send traffic through an RBSCP tunnel over a satellite link.

Router 1

interface Tunnel 0
 ip unnumbered ethernet1
 tunnel source ethernet1
 tunnel destination 172.17.2.1
 tunnel bandwidth transmit 1000
 tunnel mode rbscp
 tunnel rbscp ack-split 6
 tunnel rbscp report
!
interface ethernet1
 description Satellite Link
 ip address 172.20.1.2 255.255.255.0

Router 2

interface Tunnel 0
 ip unnumbered ethernet1
 tunnel source ethernet1
 tunnel destination 172.20.1.2
 tunnel bandwidth transmit 1000
 tunnel mode rbscp
 tunnel rbscp ack-split 6
 tunnel rbscp report
!
interface ethernet1
 description Satellite Link
 ip address 172.17.2.1 255.255.255.0

To control the type of traffic that uses the RBSCP tunnel, you must configure the appropriate routing. If you want to direct all traffic through the tunnel, you can configure a static route.

Note	To prevent routing flaps, remember to configure the tunnel interface as passive if dynamic routing protocols are used.

The following example shows how to use policy-based routing to route some specific protocol types through the tunnel. In this example, an extended access list allows TCP, Stream Control Transmission Protocol (SCTP), Encapsulating Security Payload (ESP) protocol, and Authentication Header (AH) traffic to travel through the tunnel. All IP traffic is denied.

Router 1 (Local Side)

interface Tunnel1
 ip unnumbered FastEthernet1/1
 tunnel source FastEthernet1/1
 tunnel destination 10.12.0.20
 tunnel mode rbscp
 tunnel ttl 5
 tunnel bandwidth transmit 30000
 tunnel rbscp window-stuff 1
 tunnel rbscp ack-split 4
!
interface FastEthernet0/0
 ip address 10.13.0.1 255.255.255.0
 ip policy route-map rbscp-pbr
 duplex auto
 speed auto
!
interface FastEthernet1/1
 description Satellite Link
 ip address 10.12.0.1 255.255.255.0
 duplex auto
 speed auto
!
ip route 10.15.0.0 255.255.255.0 FastEthernet1/1
!
ip access-list extended rbscp-acl
 permit tcp any 10.15.0.0 0.0.0.255
 permit 132 any 10.15.0.0 0.0.0.255
 permit esp any 10.15.0.0 0.0.0.255
 permit ahp any 10.15.0.0 0.0.0.255
 deny ip any any
!
route-map rbscp-pbr permit 10
 match ip address rbscp-acl
 set interface Tunnel1

Router 2 (Remote Side)

ip dhcp pool CLIENT
 import all
 network 10.15.0.0 255.255.255.0
 default-router 10.15.0.1
 domain-name engineer.chicago.il.us
 dns-server 10.10.0.252
!
interface Tunnel1
 ip unnumbered FastEthernet0/1
 tunnel source FastEthernet0/1
 tunnel destination 10.12.0.1
 tunnel mode rbscp
 tunnel ttl 5
 tunnel bandwidth transmit 30000
 tunnel rbscp window-stuff 1
 tunnel rbscp ack-split 4
!
interface FastEthernet0/0
 description Local LAN
 ip address 10.15.0.1 255.255.255.0
 ip policy route-map rbscp-pbr
 duplex auto
 speed auto
!
interface FastEthernet0/1
 description Satellite Link
 ip address 10.12.0.20 255.255.255.0
 duplex auto
 speed auto
!
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1
!
ip access-list extended rbscp-acl
 permit tcp any any
 permit 132 any any
 permit esp any any
 permit ahp any any
 deny ip any any
!
route-map rbscp-pbr permit 10
 match ip address rbscp-acl
 set interface Tunnel1

The following sample configuration applies generic traffic shaping (GTS) directly on the tunnel interface. In this example the configuration shapes the tunnel interface to an overall output rate of 500 kbps. For more details on GTS, see the " Regulating Packet Flow Using Traffic Shaping " chapter of the Cisco IOS Quality of Service Solutions Configuration Guide.

interface Tunnel0 
 ip address 10.1.2.1 255.255.255.0 
 traffic-shape rate 500000 125000 125000 1000 
 tunnel source 10.1.1.1 
 tunnel destination 10.2.2.2

The following sample configuration shows how to apply the same shaping policy to the tunnel interface with the Modular QoS CLI (MQC) commands. For more details on MQC, see the "Modular Quality of Service Command-Line Interface" chapter of the Cisco IOS Quality of Service Solutions Configuration Guide .

policy-map tunnel 
 class class-default 
 shape average 500000 125000 125000
! 
interface Tunnel0 
 ip address 10.1.2.1 255.255.255.0 
 service-policy output tunnel 
 tunnel source 10.1.35.1 
 tunnel destination 10.1.35.2

Policing Example

When an interface becomes congested and packets start to queue, you can apply a queueing method to packets that are waiting to be transmitted. Cisco IOS logical interfaces--tunnel interfaces in this example--do not inherently support a state of congestion and do not support the direct application of a service policy that applies a queueing method. Instead, you need to apply a hierarchical policy. Create a "child" or lower-level policy that configures a queueing mechanism, such as low latency queueing with the priority command and class-based weighted fair queueing (CBWFQ) with the bandwidth command.

policy-map child 
 class voice 
 priority 512

Create a "parent" or top-level policy that applies class-based shaping. Apply the child policy as a command under the parent policy because admission control for the child class is done according to the shaping rate for the parent class.

policy-map tunnel 
 class class-default 
 shape average 2000000 
 service-policy child

Apply the parent policy to the tunnel interface.

interface tunnel0 
 service-policy tunnel

In the following example, a tunnel interface is configured with a service policy that applies queueing without shaping. A log message is displayed noting that this configuration is not supported.

interface tunnel1
 service-policy output child
 Class Based Weighted Fair Queueing not supported on this interface

For more details on QoS traffic policing, see the Cisco IOS Quality of Service Solutions Configuration Guide .

The following sample provides the EoMPLS over GRE configuration sequence:

PE1 Configuration

vrf definition VPN1
 rd 100:1
 address-family ipv4
 route-target both 100:1
 exit-address-family
 !
mpls label protocol ldp
mpls ldp neighbor 10.10.10.11 targeted 
mpls ldp router-id Loopback0 force
!
interface Tunnel0
 ip address 100.1.1.11 255.255.255.0
 mpls label protocol ldp
 mpls ip
 keepalive 10 3
 tunnel source TenGigabitEthernet2/1/0
 tunnel destination 50.1.3.2
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.255
 !
interface TenGigabitEthernet2/1/0 
 mtu 9216
 ip address 10.1.1.1 255.255.255.0
!
interface TenGigabitEthernet9/1
 no ip address
!
interface TenGigabitEthernet9/1.11
 vrf forwarding VPN1
 encapsulation dot1Q 300
 ip address 192.168.1.1 255.255.255.0
!
interface TenGigabitEthernet9/2
 mtu 9216
 no ip address
xconnect 10.10.10.11 200 encapsulation mpls
!
router bgp 65000
 bgp log-neighbor-changes
 neighbor 10.10.10.11 remote-as 65000
 neighbor 10.10.10.11 update-source Loopback0
neighbor 192.168.1.2 remote-as 100
 !
address-family vpnv4
  neighbor 10.10.10.11 activate
  neighbor 10.10.10.11 send-community extended
 !
 address-family ipv4 vrf VPN1
  no synchronization
  neighbor 192.168.1.2 remote-as 100
  neighbor 192.168.1.2 activate
  neighbor 192.168.1.2 send-community extended
!
ip route 10.10.10.11 255.255.255.255 Tunnel0
ip route 10.1.3.0 255.255.255.0 10.1.1.2
PE2 Configuration
vrf definition VPN1
 rd 100:1
 address-family ipv4
 route-target both 100:1
exit-address-family
 !
mpls ldp neighbor 10.10.10.10 targeted
mpls label protocol ldp
mpls ldp router-id Loopback0 force
!
interface Tunnel0
 ip address 100.1.1.10 255.255.255.0
 mpls label protocol ldp
 mpls ip
 keepalive 10 3
 tunnel source TenGigabitEthernet3/3/0
 tunnel destination 10.1.1.1
!
interface Loopback0
 ip address 10.10.10.11 255.255.255.255
!
interface TenGigabitEthernet2/1
 mtu 9216
 no ip address
 xconnect 10.10.10.10 200 encapsulation mpls  
!
interface TenGigabitEthernet2/3
 mtu 9216
 no ip address
!
interface TenGigabitEthernet2/3.11
 vrf forwarding VPN1
 encapsulation dot1Q 300
 ip address 192.168.2.1 255.255.255.0
!
interface TenGigabitEthernet3/3/0
 mtu 9216
 ip address 10.1.3.2 255.255.255.0
!
router bgp 65000
 bgp log-neighbor-changes
 neighbor 10.10.10.10 remote-as 65000
 neighbor 10.10.10.10 update-source Loopback0
 neighbor 192.168.2.2 remote-as 200
 !
 address-family vpnv4
  neighbor 10.10.10.10 activate
  neighbor 10.10.10.10 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf VPN1
  no synchronization
  neighbor 192.168.2.2 remote-as 200
  neighbor 192.168.2.2 activate
  neighbor 192.168.2.2 send-community extended
 exit-address-family
¡
ip route 10.10.10.10 255.255.255.255 Tunnel0
ip route 10.1.1.0 255.255.255.0 10.1.3.1