To configure an IP tunnel:
This interface acts as an anchor for the source of the tunnel.
![]() |
Note: On SM interfaces, issue only the commands listed below. Do not configure protocols such as Multilink PPP or Multilink Frame Relay on SM interfaces. |
interface tunnel
- host1(config)#interface tunnel dvmrp:boston-tunnel-1
transport-virtual-router boston
![]() |
Note: When you delete a virtual router that has been configured as a transport virtual router for a DVMRP tunnel, the show configuration output displays No Router for the transport virtual router. To remove the DVMRP tunnel interface, simply omit any reference to the transport virtual router. For example, to delete interface tunnel dvmrp:boston-tunnel-1 transport-virtual-router No Router from the configuration, issue the command, no interface tunnel dvmrp:boston-tunnel-1. bws: added @ 8.2.0 per gneyens; no plan to fix Defect ID 44810 |
tunnel checksum
- host1(config)#interface tunnel gre:tunnel2
- host1(config-if)#tunnel checksum
tunnel destination
- host1(config)#interface tunnel dvmrp:tunnel2
- host1(config-if)#tunnel destination 192.13.7.1
- host1(config)#interface tunnel dvmrp:tunnel2
- host1(config-if)#tunnel destination remoteHost
tunnel mtu
- host1(config-if)#tunnel mtu 7500
tunnel source
- host1(config)#interface tunnel dvmrp:boston-tunnel-1
- host1(config-if)#tunnel source 192.10.2.1
- host1(config)#interface tunnel dvmrp:boston-tunnel-1
- host1(config-if)#tunnel source atm 5/0.12
- host1(config)#interface tunnel dvmrp:boston-tunnel-1
- host1(config-if)#tunnel source atm 5/1/0.12
In this example, two GRE tunnel interfaces are configured on different virtual routers of an E-series router. The source of the first tunnel interface matches the destination of the second tunnel interface and vice versa.
![]() |
Note: This example contains an ATM interface configuration for an ERX-7xx model, ERX-14xx model, or ERX-310 router that uses the slot/port format. |
- host1#virtual-router boston
The IP address of this interface appears in the header of tunneled frames and is used for forwarding traffic.
- host1:boston#interface atm 12/0.5
- host1:boston(config-if)#ip address 10.5.5.5
255.255.255.0
- host1:boston(config)#interface tunnel gre:ChicagoTunnel
- host1:boston(config-if)#tunnel source 10.5.5.5
- host1:boston(config-if)#tunnel destination
10.6.6.6
- host1:boston(config-if)#tunnel mtu 8000
- host1:boston(config-if)#ip address 10.7.7.7
255.255.255.0
- host1(config)#virtual-router chicago
- host1:chicago(config)#interface atm 12/1.5
- host1:chicago(config-if)#ip address 10.6.6.6
255.255.255.0
The name of the tunnel interface can differ from the tunnel interface configured in Step 3.
- host1:chicago(config-if)#interface tunnel
gre:BostonTunnel
The destination of this tunnel interface matches the source of the tunnel interface configured in Step 3 and vice versa.
- host1:chicago(config-if)#tunnel source 10.6.6.6
- host1:chicago(config-if)#tunnel destination
10.5.5.5
The MTU must match the MTU configured in Step 3.
- host1:chicago(config-if)#tunnel mtu 8000
- host1:chicago(config-if)#ip address 10.9.9.9
255.255.255.0
When a line module receives IP frames destined for a tunnel, the module forwards the frames to a tunnel-service module. Tunnel-service modules include SMs and modules that support the use of shared tunnel-server ports.
The tunnel-service module encapsulates the frames and forwards them to the tunnel through an interface determined by a route lookup of an IP frame. The source and destination addresses in the IP frame are the source and destination addresses of the tunnel.
Similarly, when a line module receives traffic from a tunnel, the module forwards the traffic to the tunnel-service module for deencapsulation. After deencapsulation, the tunnel-service module forwards the resulting IP frames to an interface determined by a route lookup.
When you have configured a tunnel interface, treat it in the same way as any IP interface on the router. For example, you can configure static IP routes or enable routing protocols on the tunnel interface. The IP configurations you apply to the tunnels control how traffic travels through the network.
If routing information about the tunnel network combines with routing information about the transport networks (the networks that the tunnel services), a recursive tunnel can occur. In this case, the routing table defines the tunnel itself as the best path to a tunnel destination. To prevent recursive tunnels, differentiate routing information for the tunnel network and the transport networks with one or both of the following techniques:
![]() |
Note: If you define a static route to a tunnel destination, be careful not to create routing loops. |
Figure 20 illustrates how to prevent recursive tunnels by using different routing protocols for the tunnel network and the transport networks.
Figure 20: Transport and Tunnel Networks Using Different Routing Protocols

For information about configuring multicast VPNs using GRE tunnels, see Configuring PIM for IPv4 Multicast in JUNOSe Multicast Routing Configuration Guide.