Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

header-navigation
keyboard_arrow_up
close
keyboard_arrow_left
MPLS Applications User Guide
Table of Contents Expand all
list Table of Contents

Next-Hop-Based Dynamic Tunnels

date_range 20-Dec-24

Example: Configuring Next-Hop-Based MPLS-Over-UDP Dynamic Tunnels

This example shows how to configure a dynamic MPLS-over-UDP tunnel that includes a tunnel composite next hop. The MPLS-over-UDP feature provides a scaling advantage on the number of IP tunnels supported on a device.

Starting in Junos OS Release 18.3R1, MPLS-over-UDP tunnels are supported on PTX Series routers and QFX Series switches. For every dynamic tunnel configured on a PTX router or a QFX switch, a tunnel composite next hop, an indirect next hop, and a forwarding next hop is created to resolve the tunnel destination route. You can also use policy control to resolve the dynamic tunnel over select prefixes by including the forwarding-rib configuration statement at the [edit routing-options dynamic-tunnels] hierarchy level.

Requirements

This example uses the following hardware and software components:

  • Five MX Series routers with MPCs and MICs.

  • Junos OS Release 16.2 or later running on the provider edge (PE) routers.

Before you begin:

  1. Configure the device interfaces, including the loopback interface.

  2. Configure the router ID and autonmous system number for the device.

  3. Establish an internal BGP (IBGP) session with the remote PE device.

  4. Establish OSPF peering among the devices.

Overview

Starting with Junos OS Release 16.2, a dynamic UDP tunnel supports the creation of a tunnel composite next hop for every UDP tunnel configured. These next-hop-based dynamic UDP tunnels are referred to as MPLS-over-UDP tunnels. The tunnel composite next hop are enabled by default for the MPLS-over-UDP tunnels.

MPLS-over-UDP tunnels can be bidirectional or unidirectional in nature.

  • Bidirectional—When the PE devices are connected over MPLS-over-UDP tunnels in both directions, it is called a bidirectional MPLS-over-UDP tunnel.

  • Unidirectional—When two PE devices are connected over MPLS-over-UDP tunnel in one direction, and over MPLS/IGP in the other direction, it is called an unidirectional MPLS-over-UDP tunnel.

    Unidirectional MPLS-over-UDP tunnels are used in migration scenarios, or in cases where two PE devices provide connectivity to each other over two disjoint networks. Because reverse direction tunnel does not exist for unidirectional MPLS-over-UDP tunnels, you must configure a filter-based MPLS-over-UDP decapsulation on the remote PE device for forwarding the traffic.

Starting in Junos OS Release 18.2R1, on PTX series routers and QFX10000 with unidirectional MPLS-over-UDP tunnels, you must configure the remote PE device with an input filter for MPLS-over-UDP packets, and an action for decapsulating the IP and UDP headers for forwarding the packets in the reverse tunnel direction.

For example, on the remote PE device, Device PE2, the following configuration is required for unidirectional MPLS-over-UDP tunnels:

PE2

content_copy zoom_out_map
[edit firewall filter]
user@host# set Decap_Filter term udp_decap from protocol udp
user@host# set Decap_Filter term udp_decap from destination-port 6635
user@host# set Decap_Filter term udp_decap then count UDP_PKTS
user@host# set Decap_Filter term udp_decap then decapsulate mpls-in-udp
user@host# set Decap_Filter term def then count def_pkt
user@host# set Decap_Filter term def then accept

In the above sample configuration, Decap_Filter is the name of the firewall filter used for MPLS-over-UDP decapsulation. The term udp_decap is the input filter for accepting UDP packets on the core-facing interface of Device PE2, and then decapsulate the MPLS-over-UDP packets to MPLS-over-IP packets for forwarding.

You can use the existing firewall operational mode commands, such as show firewall filter to view the filter-based MPLS-over-UDP decapsulation.

For example:

content_copy zoom_out_map
user@host >show firewall filter Decap_Filter
Filter: Decap_Filter
Counters:
Name                                                Bytes              Packets
UDP_PKTS                                            16744                  149
def_pkt                                             13049                  136
Note:

For unidirectional MPLS-over-UDP tunnels:

  • Only IPv4 address is supported as the outer header. Filter-based MPLS-over-UDP decapsulation does not support IPv6 address in the outer header.

  • Only the default routing instance is supported after decapsulation.

Starting in Junos OS Release 17.1, on MX Series routers with MPCs and MICs, the scaling limit of MPLS-over-UDP tunnels is increased.

Starting in Junos Release 19.2R1, on MX Series routers with MPCs and MICs, carrier supporting carrier (CSC) architecture can be deployed with MPLS-over-UDP tunnels carrying MPLS traffic over dynamic IPv4 UDP tunnels that are established between supporting carrier's PE devices. With this enhancement, the scaling advantage that the MPLS-over-UDP tunnels provided is further increased. The CSC support with MPLS-over-UDP tunnel is not supported for IPv6 UDP tunnel.

The existing dynamic tunnel feature requires complete static configuration. Currently, the tunnel information received from peer devices in advertised routes is ignored. Starting in Junos OS Release 17.4R1, on MX Series routers, the next-hop-based dynamic MPLS-over-UDP tunnels are signaled using BGP encapsulation extended community. BGP export policy is used to specify the tunnel types, advertise the sender side tunnel information, and parse and convey the receiver side tunnel information. A tunnel is created according to the received type tunnel community.

Multiple tunnel encapsulations are supported by BGP. On receiving multiple capability, the next-hop-based dynamic tunnel is created based on the configured BGP policy and tunnel preference. The tunnel preference should be consistent across both the tunnel ends for the tunnel to be set up. By default, MPLS-over-UDP tunnel is preferred over GRE tunnels. If dynamic tunnel configuration exists, it takes precedence over received tunnel community.

When configuring a next-hop-based dynamic MPLS-over-UDP tunnel, be aware of the following considerations:

  • An IBGP session must be configured between the PE devices.

  • A switchover between the next-hop-based dynamic tunnel encapsulations (UDP and GRE) is allowed, and this can impact network performance in terms of the supported IP tunnel scaling values in each mode.

  • Having both GRE and UDP next-hop-based dynamic tunnel encapsulation types for the same tunnel destination leads to a commit failure.

  • For unidirectional MPLS-over-UDP tunnels, you must explicitly configure filter-based MPLS-over-UDP decapsulation on the remote PE device for the packets to be forwarded.

  • Graceful Routing Engine switchover (GRES) is supported with MPLS-over-UDP, and the MPLS-over-UDP tunnel type flags are unified ISSU and NSR compliant.

  • MPLS-over-UDP tunnels are supported on virtual MX (vMX) in Lite mode.

  • MPLS-over-UDP tunnels support dynamic GRE tunnel creation based upon new IPv4-mapped-IPv6 next hops.

  • MPLS-over-UDP tunnel are supported in interoperability with contrail, wherein the MPLS-over-UDP tunnels are created from the contrail vRouter to an MX gateway. To enable this, the following community is required to be advertised in the route from the MX Series router to the contrail vRouter:

    content_copy zoom_out_map
    [edit policy-options community]
    udp members 0x030c:64512:13;
    

    At a given point in time, only one tunnel type is supported on the contrail vRouter—next-hop-based dynamic GRE tunnels, MPLS-over-UDP tunnels, or VXLAN.

  • The following features are not supported with the next-hop-based dynamic MPLS-over-UDP tunnel configuration:

    • RSVP automatic mesh

    • Plain IPV6 GRE and UDP tunnel configuration

    • Logical systems

Topology

Figure 1 illustrates a Layer 3 VPN scenario over dynamic MPLS-over-UDP tunnels. The customer edge (CE) devices, CE1 and CE2, connect to provider edge (PE) devices, PE1 and PE2, respectively. The PE devices are connected to a provider device (Device P1), and an internal BGP (IBGP) session interconnects the two PE devices. A dynamic next-hop-based bidirectional MPL-over-UDP tunnel is configured between the PE devices.

Figure 1: Dynamic MPLS-over-UDP TunnelsDynamic MPLS-over-UDP Tunnels

The MPLS-over-UDP tunnel is handled as follows:

  1. After a MPLS-over-UDP tunnel is configured, a tunnel destination mask route with a tunnel composite next hop is created for the tunnel in the inet.3 routing table. This IP tunnel route is withdrawn only when the dynamic tunnel configuration is deleted.

    The tunnel composite next-hop attributes include the following:

    • When Layer 3 VPN composite next hop is disabled—Source and destination address, encapsulation string, and VPN label.

    • When Layer 3 VPN composite next hop and per-prefix VPN label allocation are enabled—Source address, destination address, and encapsulation string.

    • When Layer 3 VPN composite next hop is enabled and per-prefix VPN label allocation is disabled—Source address, destination address, and encapsulation string. The route in this case is added to the other virtual routing and forwarding instance table with a secondary route.

  2. The PE devices are interconnected using an IBGP session. The IBGP route next hop to a remote BGP neighbor is the protocol next hop, which is resolved using the tunnel mask route with the tunnel next hop.

  3. After the protocol next hop is resolved over the tunnel composite next hop, indirect next hops with forwarding next hops are created.

  4. The tunnel composite next hop is used to forward the next hops of the indirect next hops.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

CE1

content_copy zoom_out_map
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/8
set interfaces lo0 unit 0 family inet address 10.127.0.1/32
set routing-options router-id 10.127.0.1
set routing-options autonomous-system 65200
set protocols bgp group ce1-pe1 export export-loopback-direct
set protocols bgp group ce1-pe1 peer-as 100
set protocols bgp group ce1-pe1 neighbor 10.0.0.2
set policy-options policy-statement export-loopback-direct term term-1 from interface lo0.0
set policy-options policy-statement export-loopback-direct term term-1 from route-filter 10.127.0.1/32 exact
set policy-options policy-statement export-loopback-direct term term-1 then accept

CE2

content_copy zoom_out_map
set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.2/24
set interfaces lo0 unit 0 family inet address 10.127.0.5/32
set routing-options router-id 10.127.0.5
set routing-options autonomous-system 65200
set protocols bgp group ce1-pe1 export export-loopback-direct
set protocols bgp group ce1-pe1 peer-as 65100
set protocols bgp group ce1-pe1 neighbor 203.0.113.1
set policy-options policy-statement export-loopback-direct term term-1 from interface lo0.0
set policy-options policy-statement export-loopback-direct term term-1 from route-filter 10.127.0.5/32 exact
set policy-options policy-statement export-loopback-direct term term-1 then accept

PE1

content_copy zoom_out_map
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.2/8
set interfaces ge-0/0/1 unit 0 family inet address 192.0.2.1/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.127.0.2/32
set routing-options static route 10.33.0/16 next-hop 192.0.2.2
set routing-options router-id 10.127.0.2
set routing-options autonomous-system 65100
set routing-options forwarding-table export pplb
set routing-options dynamic-tunnels gre next-hop-based-tunnel
set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe2 source-address 10.127.0.2
set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe2 udp
set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe2 destination-networks 10.127.0.0/24
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 10.127.0.2
set protocols bgp group IBGP family inet-vpn unicast
set protocols bgp group IBGP neighbor 10.127.0.4
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set routing-instances MPLS-over-UDP-PE1 instance-type vrf
set routing-instances MPLS-over-UDP-PE1 interface ge-0/0/0.0
set routing-instances MPLS-over-UDP-PE1 route-distinguisher 10.127.0.2:1
set routing-instances MPLS-over-UDP-PE1 vrf-target target:600:1
set routing-instances MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 peer-as 65200
set routing-instances MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 neighbor 10.0.0.1 as-override

P1

content_copy zoom_out_map
set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.2/24
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.1/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.127.0.3/32
set routing-options router-id 10.127.0.3
set routing-options autonomous-system 65100
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

PE2

content_copy zoom_out_map
set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.1/24
set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.2/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.127.0.4/8
set routing-options nonstop-routing
set routing-options router-id 10.127.0.4
set routing-options autonomous-system 65100
set routing-options forwarding-table export pplb
set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe1 source-address 10.127.0.4
set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe1 udp
set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe1 destination-networks 10.127.0.0/24
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 10.127.0.4
set protocols bgp group IBGP family inet-vpn unicast
set protocols bgp group IBGP neighbor 10.127.0.2
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set routing-instances MPLS-over-UDP-PE2 instance-type vrf
set routing-instances MPLS-over-UDP-PE2 interface ge-0/0/0.0
set routing-instances MPLS-over-UDP-PE2 route-distinguisher 10.127.0.4:1
set routing-instances MPLS-over-UDP-PE2 vrf-target target:600:1
set routing-instances MPLS-over-UDP-PE2 protocols bgp group ebgp peer-as 65200
set routing-instances MPLS-over-UDP-PE2 protocols bgp group ebgp neighbor 203.0.113.2 as-override

Procedure

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device PE1:

  1. Configure the device interfaces including the loopback interface of the device.

    content_copy zoom_out_map
    [edit interfaces]
    user@PE1# set ge-0/0/0 unit 0 family inet address 10.0.0.2/8
    user@PE1# set ge-0/0/1 unit 0 family inet address 192.0.2.1/24
    user@PE1# set ge-0/0/1 unit 0 family mpls
    user@PE1# set lo0 unit 0 family inet address 10.127.0.2/8
    
  2. Configure a static route for routes from Device PE1 with Device P1 as the next-hop destination.

    content_copy zoom_out_map
    [edit routing-options]
    user@PE1# set static route 10.33.0.0/16 next-hop 192.0.2.2
    
  3. Configure the router-ID and autonomous system number for Device PE1.

    content_copy zoom_out_map
    [edit routing-options]
    user@PE1# set router-id 10.127.0.2
    user@PE1# set autonomous-system 65100
    
  4. (PTX Series only) Configure policy control to resolve the MPLS-over-UDP dynamic tunnel route over select prefixes.

    content_copy zoom_out_map
    [edit routing-options dynamic-tunnels]
    user@PTX-PE1# set forwarding-rib inet.0 inet-import dynamic-tunnel-fwd-route-import
    
  5. (PTX Series only) Configure the inet-import policy for resolving dynamic tunnel destination routes over .

    content_copy zoom_out_map
    [edit policy-options]
    user@PTX-PE1# set policy-statement dynamic-tunnel-fwd-route-import term 1 from route-filter 10.127.0.4/32 exact
    user@PTX-PE1# set policy-statement dynamic-tunnel-fwd-route-import term 1 then accept
    user@PTX-PE1# set policy-options policy-statement dynamic-tunnel-fwd-route-import then reject
    
  6. Configure IBGP peering between the PE devices.

    content_copy zoom_out_map
    [edit protocols]
    user@PE1# set bgp group IBGP type internal
    user@PE1# set bgp group IBGP local-address 10.127.0.2
    user@PE1# set bgp group IBGP family inet-vpn unicast
    user@PE1# set bgp group IBGP neighbor 10.127.0.4
    
  7. Configure OSPF on all the interfaces of Device PE1, excluding the management interface.

    content_copy zoom_out_map
    [edit protocols]
    user@PE1# set ospf area 0.0.0.0 interface ge-0/0/1.0
    user@PE1# set ospf area 0.0.0.0 interface lo0.0 passive
    
  8. Enable next-hop-based dynamic GRE tunnel configuration on Device PE1.

    Note:

    This step is required only for illustrating the implementation difference between next-hop-based dynamic GRE tunnels and MPLS-over-UDP tunnels.

    content_copy zoom_out_map
    [edit routing-options]
    user@PE1# set dynamic-tunnels gre next-hop-based-tunnel
    
  9. Configure the MPLS-over-UDP tunnel parameters from Device PE1 to Device PE2.

    content_copy zoom_out_map
    [edit routing-options]
    user@PE1# set dynamic-tunnels udp-dyn-tunnel-to-pe2 source-address 10.127.0.2
    user@PE1# set dynamic-tunnels udp-dyn-tunnel-to-pe2 udp
    user@PE1# set dynamic-tunnels udp-dyn-tunnel-to-pe2 destination-networks 10.127.0.0/24
    
  10. Configure a VRF routing instance on Device PE1 and other routing instance parameters.

    content_copy zoom_out_map
    [edit routing-instances]
    user@PE1# set MPLS-over-UDP-PE1 instance-type vrf
    user@PE1# set MPLS-over-UDP-PE1 interface ge-0/0/0.0
    user@PE1# set MPLS-over-UDP-PE1 route-distinguisher 10.127.0.2:1
    user@PE1# set MPLS-over-UDP-PE1 vrf-target target:600:1
    
  11. Enable BGP in the routing instance configuration for peering with Device CE1.

    content_copy zoom_out_map
    [edit routing-instances]
    user@PE1# set MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 peer-as 65200
    user@PE1# set MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 neighbor 10.0.0.1 as-override
    

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, show protocols, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

content_copy zoom_out_map
user@PE1# show interfaces
ge-0/0/0 {
    unit 0 {
        family inet {
            address 10.0.0.2/8;
        }
    }
}
ge-0/0/1 {
    unit 0 {
        family inet {
            address 192.0.2.1/24;
        }
        family mpls;
    }
}
lo0 {
    unit 0 {
        family inet {
            address 10.127.0.2/32;
        }
    }
}
content_copy zoom_out_map
user@PE1# show routing-options
static {
    route 10.33.0.0/16 next-hop 192.0.2.2;
}
router-id 10.127.0.2;
autonomous-system 65100;
forwarding-table {
    export pplb;
}
dynamic-tunnels {
    gre next-hop-based-tunnel;
    udp-dyn-tunnel-to-pe2 {
        source-address 10.127.0.2;
        udp;
        destination-networks {
            10.127.0.0/24;
        }
    }
}
content_copy zoom_out_map
user@PE1# show protocols
bgp {
    group IBGP {
        type internal;
        local-address 10.127.0.2;
        family inet-vpn {
            unicast;
        }
        neighbor 10.127.0.4;
    }
}
ospf {
    area 0.0.0.0 {
        interface ge-0/0/1.0;
        interface lo0.0 {
            passive;
        }
    }
}
content_copy zoom_out_map
user@PE1# show routing-instances
MPLS-over-UDP-PE1 {
    instance-type vrf;
    interface ge-0/0/0.0;
    route-distinguisher 10.127.0.2:1;
    vrf-target target:600:1;
    protocols {
        bgp {
            group pe1-ce1 {
                peer-as 65200;
                neighbor 10.0.0.1 {
                    as-override;
                }
            }
        }
    }
}

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the Connection Between PE Devices

Purpose

Verify the BGP peering status between Device PE1 and Device PE2, and the BGP routes received from Device PE2.

Action

From operational mode, run the show bgp summary and show route receive-protocol bgp ip-address table bgp.l3vpn.0 commands.

content_copy zoom_out_map
user@PE1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
bgp.l3vpn.0
                       2          2          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.127.0.4             65100        139        136       0       0       58:23 Establ
  bgp.l3vpn.0: 2/2/2/0
  MPLS-over-UDP-PE1.inet.0: 2/2/2/0
10.10.0.1               65200        135        136       0       0       58:53 Establ
  MPLS-over-UDP-PE1.inet.0: 1/1/1/0
content_copy zoom_out_map
user@PE1> show route receive-protocol bgp 10.127.0.4 table bgp.l3vpn.0
bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.127.0.4:1:127.0.0.5/8
*                         10.127.0.4                  65100        65200 I
Meaning
  • In the first output, the BGP session state is Establ, which means that the session is up and the PE devices are peered.

  • In the second output, Device PE1 has learned a BGP route from Device PE2.

Verify the Dynamic Tunnel Routes on Device PE1

Purpose

Verify the routes in the inet.3 routing table and the dynamic tunnel database information on Device PE1.

Action

From operational mode, run the show route table inet.3, show dynamic-tunnels database terse, show dynamic-tunnels database, and show dynamic-tunnels database summary commands.

content_copy zoom_out_map
user@PE1> show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.127.0.0/24     *[Tunnel/300] 00:21:18
                      Tunnel
127.0.0.4/8     *[Tunnel/300] 00:21:18
                      Tunnel Composite
content_copy zoom_out_map
user@PE1> show dynamic-tunnels database terse
Table: inet.3

Destination-network: 10.127.0.0/24
Destination         Source          Next-hop                  Type        Status
10.127.0.4/8      10.127.0.2     0xb395b10 nhid 613        udp         Up
content_copy zoom_out_map
user@PE1> show dynamic-tunnels database
Table: inet.3
. . .
Tunnel to: 10.127.0.4/32
  Reference count: 2
  Next-hop type: UDP
    Source address: 10.127.0.2 Tunnel Id: 2
    Next hop: tunnel-composite, 0xb395b10, nhid 613
      VPN Label: Push 299776 Reference count: 3
      Traffic Statistics: Packets 0, Bytes 0
      State: Up
content_copy zoom_out_map
user@PE1> show dynamic-tunnels database summary
Dynamic Tunnels,  Total 1 displayed
GRE Tunnel: 
Active Tunnel Mode, Next Hop Base
  IFL Based,  Total 0 displayed, Up 0, Down 0
  Nexthop Based,  Total 0 displayed, Up 0, Down 0
RSVP Tunnel: 
  Total 0 displayed
UDP Tunnel: 
  Total 1 displayed, Up 1, Down 0
Meaning
  • In the first output, because Device PE1 is configured with the MPLS-over-UDP tunnel, a tunnel composite route is created for the inet.3 routing table route entry.

  • In the remaining outputs, the MPLS-over-UDP tunnel is displayed with the tunnel encapsulation type, tunnel next hop parameters, and tunnel status.

Verify the Dynamic Tunnel Routes on Device PE2

Purpose

Verify the routes in the inet.3 routing table and the dynamic tunnel database information on Device PE2.

Action

From operational mode, run the show route table inet.3, and the show dynamic-tunnels database terse commands.

content_copy zoom_out_map
user@PE2> show route table inet.3
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.127.0.0/24      *[Tunnel/300] 00:39:31
                      Tunnel
10.127.0.2/32     *[Tunnel/300] 00:24:53
                      Tunnel Composite
content_copy zoom_out_map
user@PE1> show dynamic-tunnels database terse
Table: inet.3

Destination-network: 127.0.0.0/8
Destination         Source          Next-hop                  Type        Status
10.127.0.2/32      10.127.0.4     0xb395450 nhid 615        udp         Up  
Meaning

The outputs show the MPLS-over-UDP tunnel creation and the next-hop ID assigned as the next-hop interface, similar to Device PE1.

Verifying That the Routes Have the Expected Indirect-Next-Hop Flag

Purpose

Verify that Device PE1 and Device PE2 are configured to maintain the indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table.

Action

From operational mode, run the show krt indirect-next-hop command on Device PE1 and Device PE2.

content_copy zoom_out_map
user@PE1> show krt indirect-next-hop
Indirect Nexthop:
Index: 1048574 Protocol next-hop address: 10.127.0.4
  RIB Table: bgp.l3vpn.0                
  Label: Push 299776           
  Policy Version: 1                     References: 1
  Locks: 3                              0xb2ab630
  Flags: 0x0                              
  INH Session ID: 0x0
  INH Version ID: 0
  Ref RIB Table: unknown
        Tunnel type: UDP, Reference count: 3, nhid: 613
        Destination address: 10.127.0.4, Source address: 10.127.0.2
        Tunnel id: 2, VPN Label: Push 299776, TTL action: prop-ttl
      IGP FRR Interesting proto count : 1
      Chain IGP FRR Node Num          : 1
         IGP Resolver node(hex)       : 0xb3c70dc   
         IGP Route handle(hex)        : 0xb1ae688      IGP rt_entry protocol        : Tunnel
         IGP Actual Route handle(hex) : 0x0            IGP Actual rt_entry protocol : Any
content_copy zoom_out_map
user@PE2> show krt indirect-next-hop
Indirect Nexthop:
Index: 1048575 Protocol next-hop address: 10.127.0.2
  RIB Table: bgp.l3vpn.0                
  Label: Push 299776           
  Policy Version: 1                     References: 2
  Locks: 3                              0xb2ab740
  Flags: 0x0                              
  INH Session ID: 0x0
  INH Version ID: 0
  Ref RIB Table: unknown
        Tunnel type: UDP, Reference count: 3, nhid: 615
        Destination address: 10.127.0.2, Source address: 10.127.0.4
        Tunnel id: 1, VPN Label: Push 299776, TTL action: prop-ttl
      IGP FRR Interesting proto count : 2
      Chain IGP FRR Node Num          : 1
         IGP Resolver node(hex)       : 0xb3d3a28   
         IGP Route handle(hex)        : 0xb1ae634      IGP rt_entry protocol        : Tunnel
         IGP Actual Route handle(hex) : 0x0            IGP Actual rt_entry protocol : Any
Meaning

The outputs show that a next-hop-based dynamic MPLS-over-UDP tunnel is created between the PE devices.

Troubleshooting

To troubleshoot the next-hop-based dynamic tunnels, see:

Troubleshooting Commands

Problem

The next-hop-based dynamic MPLS-over-UDP tunnel configuration is not taking effect.

Solution

To troubleshoot the next-hop-based MPLS-over-UDP tunnel configuration, use the following traceroute commands at the [edit routing-options dynamic-tunnels] statement hierarchy:

  • traceoptions file file-name

  • traceoptions file size file-size

  • traceoptions flag all

For example:

content_copy zoom_out_map
[edit routing-options dynamic-tunnels]
traceoptions {
    file udp_dyn_pe1.wri size 4294967295;
    flag all;
}

Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels Overview

With the rise in deployment of high-scale IP tunnels in data centers, there is a need to add security measures that allow users to limit malicious traffic from compromised virtual machines (VMs). One possible attack is the injecting of traffic into an arbitrary customer VPN from a compromised server through the gateway router. In such cases, anti-spoofing checks on IP tunnels ensure that only legitimate sources are injecting traffic into data centers from their designated IP tunnels.

Next-hop-based dynamic IP tunnels create a tunnel composite next hop for every dynamic tunnel created on the device. Because next-hop-based dynamic tunnels remove the dependency on physical interfaces for every new dynamic tunnel configured, configuring next-hop-based dynamic tunnels provides a scaling advantage over the number of dynamic tunnels that can be created on a device. Starting in Junos OS Release 17.1, anti-spoofing capabilities for next-hop-based dynamic IP tunnels is provided for next-hop-based dynamic tunnels. With this enhancement, a security measure is implemented to prevent injecting of traffic into an arbitrary customer VPN from a compromised server through the gateway router.

Anti-spoofing is implemented using reverse path forwarding checks in the Packet Forwarding Engine. The checks are implemented for the traffic coming through the tunnel to the routing instance. Currently, when the gateway router receives traffic from a tunnel, only the destination lookup us done and the packet is forwarded accordingly. When anti-spoofing protection is enabled, the gateway router also does a source address lookup of the encapsulation packet IP header in the VPN, in addition to the tunnel destination lookup. This ensures that legitimate sources are injecting traffic through their designated IP tunnels. As a result, anti-spoofing protection ensures that the tunnel traffic is received from a legitimate source on the designated tunnels.

Figure 2 illustrates a sample topology with the requirements for anti-spoofing protection.

Figure 2: Anti-Spoofing Protection for Next-Hop-Based Dynamic TunnelsAnti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels

In this example, the gateway router is Router G. Router G has two VPNs—Green and Blue. The two servers, Server A and Server B, can reach the Green and Blue VPNs on Router G through the next-hop-based dynamic tunnels T1 and T2, respectively. Several hosts and virtual machines (P, Q, R, S, and T) connected to the servers can reach the VPNs through the gateway router, Router G. Router G has the virtual routing and forwarding (VRF) tables for Green and Blue VPNs, each populated with the reachability information for the virtual machines in those VPNs.

For example, in VPN Green, Router G uses tunnel T1 to reach host P, tunnel T2 to reach hosts R and S, and load balancing is done between tunnels T1 and T2 to reach the multihomed host Q. In VPN Blue, Router G uses tunnel T1 to reach hosts P and R, and tunnel T2 to reach hosts Q and T.

The check passes for reverse path forwarding when:

  • A packet comes from a legitimate source on its designated tunnel.

    Host P in VPN Green sends a packet to host X using tunnel T1. Because Router G can reach host P through tunnel T1, it allows the packet to pass and forwards the packet to host X.

  • A packet comes from a multihomed source on its designated tunnels.

    Host Q in VPN Green is multihomed on servers A and B, and can reach Router G through tunnels T1 and T2. Host Q sends a packet to host Y using tunnel T1, and a packet to host X using tunnel T2. Because Router G can reach host Q through tunnels T1 and T2, it allows the packets to pass and forwards them to hosts Y and X, respectively.

Layer 3 VPNs do not have anti-spoofing protection enabled by default. To enable anti-spoofing for next-hop-based dynamic tunnels, include the ip-tunnel-rpf-check statement at the [edit routing-instances routing-instance-name routing-options forwarding-table] hierarchy level. The reverse path forwarding check is applied to the VRF routing instance only. The default mode is set to strict, where the packet that comes from a source on a nondesignated tunnel does not pass the check. The ip-tunnel-rpf-check mode can be set as loose, where the reverse path forwarding check fails when the packet comes from a nonexistent source. An optional firewall filter can be configured under the ip-tunnel-rpf-check statement to count and log the packets that failed the reverse path forwarding check.

The following sample output shows an anti-spoofing configuration:

content_copy zoom_out_map
[edit routing-instances routing-instance-name routing-options forwarding-table]
ip-tunnel-rpf-check {
    mode loose;
    fail-filter filter-name;
}

Take the following guidelines under consideration when configuring anti-spoofing protection for next-hop-based dynamic tunnels:

  • Anti-spoofing protection can be enabled for IPv4 tunnels and IPv4 data traffic only. The anti-spoofing capabilities are not supported on IPv6 tunnels and IPv6 data traffic.

  • Anti-spoofing for next-hop-based dynamic tunnels can detect and prevent a compromised virtual machine (inner source reverse path forwarding check) but not a compromised server that is label-spoofing.

  • The next-hop-based IP tunnels can originate and terminate on an inet.0 routing table.

  • Anti-spoofing protection is effective when the VRF routing instance has label-switched interfaces (LSIs) (using the vrf-table-label), or virtual tunnel (VT) interfaces. With per-next-hop label on the VRF routing instance, anti-spoofing protection is not supported.

  • The rpf fail-filter is applicable only to the inner IP packet.

  • Enabling anti-spoofing checks does not affect the scaling limit of the next-hop-based dynamic tunnels on a device.

  • The system resource utilization with anti-spoofing protection enabled for the VRF routing instance is slightly higher than the utilization of next-hop-based dynamic tunnels without the anti-spoofing protection enabled.

  • Anti-spoofing protection requires additional source IP address checks, which has minimal impact on network performance.

  • Graceful Routing Engine switchover (GRES) and in-service software upgrade (ISSU) are supported with anti-spoofing protection.

Example: Configuring Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels

This example shows how to configure reverse path forwarding checks for the virtual routing and forwarding (VRF) routing instance to enable anti-spoofing protection for next-hop-based dynamic tunnels. The checks ensure that legitimate sources are injecting traffic through their designated IP tunnels.

Requirements

This example uses the following hardware and software components:

  • Three MX Series Routers with MICs, each connected to a host device.

  • Junos OS Release 17.1 or later running on one or all the routers.

Before you begin:

  • Enable tunnel services configuration on the Flexible PIC Concentrator.

  • Configure the router interfaces.

  • Configure the router-ID and assign an autonomous system number for the router.

  • Establish an internal BGP (IBGP) session with the tunnel endpoints.

  • Configure RSVP on all the routers.

  • Configure OSPF or any other interior gateway protocol on all the routers.

  • Configure two dynamic next-hop-based IP tunnels between the two routers.

  • Configure a VRF routing instance for every router-to-host connection.

Overview

Starting in Junos OS Release 17.1, anti-spoofing capabilities are added to next-hop-based dynamic IP tunnels, where checks are implemented for the traffic coming through the tunnel to the routing instance using reverse path forwarding in the Packet Forwarding Engine.

Currently, when the gateway router receives traffic from a tunnel, only the destination address lookup is done before forwarding. With anti-spoofing protection, the gateway router does a source address lookup of the encapsulation packet IP header in the VPN to ensure that legitimate sources are injecting traffic through their designated IP tunnels. This is called the strict mode and is the default behavior of anti-spoofing protection. To pass traffic from nondesignated tunnels, the reverse path forwarding check is enabled in the lose mode. For traffic received from nonexistent sources, the reverse path forwarding check fails for both the strict and loose modes.

Anti-spoofing is supported on VRF routing instances. To enable anti-spoofing for dynamic tunnels, include the ip-tunnel-rpf-check statement at the [edit routing-instances routing-instance-name routing-options forwarding-table] hierarchy level.

Topology

Figure 3 illustrates a sample network topology enabled with anti-spoofing protection. Routers R0, R1 and R2 are each connected to hosts Host0, Host1, and Host2, respectively. Two generic routing encapsulation (GRE) next-hop-based dynamic tunnels, Tunnel 1 and Tunnel 2 – connect Router R0 with Routers R1 and R2, respectively. The VRF routing instance is running between each router and its connected host devices.

Figure 3: Anti-Spoofing Protection for Next-Hop-Based Dynamic TunnelsAnti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels

Taking as an example, three packets (Packets A, B, and C) are received on Router 0 from Router R2 through the next-hop-based dynamic GRE tunnel (Tunnel 2). The source IP address of these packets are 172.17.0.2 (Packet A), 172.18.0.2 (Packet B), and 172.20.0.2 (Packet C).

The source IP address of Packets A and B belong to Host 2 and Host 1, respectively. Packet C is a nonexistent source tunnel. The designated tunnel in this example is Tunnel 2, and the nondesignated tunnel is Tunnel 1. Therefore, the packets are processed as follows:

  • Packet A—Because the source is coming from a designated tunnel (Tunnel 2), Packet A passes the reverse path forwarding check and is processed for forwarding through Tunnel 2.

  • Packet B—Because the source is coming from Tunnel 1, which is a nondesinated tunnel, by default, Packet B fails the reverse path forwarding check in the strict mode. If loose mode is enabled, Packet B is allowed for forwarding.

  • Packet C—Because the source is a nonexistent tunnel source, Packet C fails the reverse path forwarding check, and the packet is not forwarded.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Router R0

content_copy zoom_out_map
set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.1/24
set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.1/24
set interfaces ge-0/0/2 vlan-tagging
set interfaces ge-0/0/2 unit 0 vlan-id 1
set interfaces ge-0/0/2 unit 0 family inet address 172.16.0.1/16
set interfaces lo0 unit 0 family inet address 10.1.1.1/32
set routing-options router-id 10.1.1.1
set routing-options autonomous-system 100
set routing-options dynamic-tunnels gre next-hop-based-tunnel
set routing-options dynamic-tunnels T1 source-address 192.0.2.1
set routing-options dynamic-tunnels T1 gre
set routing-options dynamic-tunnels T1 destination-networks 192.0.2.0/24
set routing-options dynamic-tunnels T2 source-address 198.51.100.1
set routing-options dynamic-tunnels T2 gre
set routing-options dynamic-tunnels T2 destination-networks 198.51.100.0/24
set protocols rsvp interface all
set protocols rsvp interface fxp0.0 disable
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 10.1.1.1
set protocols bgp group IBGP family inet-vpn unicast
set protocols bgp group IBGP neighbor 20.1.1.1
set protocols bgp group IBGP neighbor 30.1.1.1
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface all
set routing-instances VPN1 instance-type vrf
set routing-instances VPN1 interface ge-0/0/2.0
set routing-instances VPN1 route-distinguisher 100:100
set routing-instances VPN1 vrf-target target:100:1
set routing-instances VPN1 vrf-table-label
set routing-instances VPN1 routing-options forwarding-table ip-tunnel-rpf-check mode strict
set routing-instances VPN1 protocols bgp group External type external
set routing-instances VPN1 protocols bgp group External family inet unicast
set routing-instances VPN1 protocols bgp group External peer-as 200
set routing-instances VPN1 protocols bgp group External neighbor 172.16.0.1

Router R1

content_copy zoom_out_map
set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.2/24
set interfaces ge-0/0/1 vlan-tagging
set interfaces ge-0/0/1 unit 0 vlan-id 2
set interfaces ge-0/0/1 unit 0 family inet address 172.18.0.1/16
set interfaces lo0 unit 0 family inet address 20.1.1.1/32
set routing-options router-id 20.1.1.1
set routing-options autonomous-system 100
set routing-options dynamic-tunnels gre next-hop-based-tunnel
set routing-options dynamic-tunnels T1 source-address 192.0.2.2
set routing-options dynamic-tunnels T1 gre
set routing-options dynamic-tunnels T1 destination-networks 192.0.2.0/24
set protocols rsvp interface all
set protocols rsvp interface fxp0.0 disable
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 20.1.1.1
set protocols bgp group IBGP family inet-vpn unicast
set protocols bgp group IBGP neighbor 30.1.1.1
set protocols bgp group IBGP neighbor 10.1.1.1
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface all
set routing-instances VPN2 instance-type vrf
set routing-instances VPN2 interface ge-0/0/1.0
set routing-instances VPN2 route-distinguisher 100:200
set routing-instances VPN2 vrf-target target:200:1
set routing-instances VPN2 vrf-table-label

R2

content_copy zoom_out_map
set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.2/24
set interfaces ge-0/0/2 vlan-tagging
set interfaces ge-0/0/2 unit 0 vlan-id 3
set interfaces ge-0/0/2 unit 0 family inet address 172.17.0.1/16
set interfaces lo0 unit 0 family inet address 30.1.1.1/32
set routing-options router-id 30.1.1.1
set routing-options autonomous-system 100
set routing-options dynamic-tunnels gre next-hop-based-tunnel
set routing-options dynamic-tunnels T2 source-address 198.51.100.2
set routing-options dynamic-tunnels T2 gre
set routing-options dynamic-tunnels T2 destination-networks 198.51.100.0/24
set protocols rsvp interface all
set protocols rsvp interface fxp0.0 disable
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 30.1.1.1
set protocols bgp group IBGP family inet-vpn unicast
set protocols bgp group IBGP neighbor 20.1.1.1
set protocols bgp group IBGP neighbor 10.1.1.1
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface all
set routing-instances VPN3 instance-type vrf
set routing-instances VPN3 interface ge-0/0/2.0
set routing-instances VPN3 route-distinguisher 100:300
set routing-instances VPN3 vrf-target target:300:1
set routing-instances VPN3 vrf-table-label

Procedure

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router R0:

  1. Configure Router R0’s interfaces, including the loopback interface.

    content_copy zoom_out_map
    [edit interfaces]
    user@R0# set ge-0/0/0 unit 0 family inet address 192.0.2.1/24
    user@R0# set ge-0/0/1 unit 0 family inet address 198.51.100.1/24
    user@R0# set ge-0/0/2 vlan-tagging
    user@R0# set ge-0/0/2 unit 0 vlan-id 1
    user@R0# set ge-0/0/2 unit 0 family inet address 172.16.0.1/16
    user@R0# set lo0 unit 0 family inet address 10.1.1.1/32
    
  2. Assign the router ID and autonomous system number for Router R0.

    content_copy zoom_out_map
    [edit routing-options]
    user@R0# set router-id 10.1.1.1
    user@R0# set autonomous-system 100
    
  3. Configure IBGP peering between the routers.

    content_copy zoom_out_map
    [edit protocols]
    user@R0# set bgp group IBGP type internal
    user@R0# set bgp group IBGP local-address 10.1.1.1
    user@R0# set bgp group IBGP family inet-vpn unicast
    user@R0# set bgp group IBGP neighbor 20.1.1.1
    user@R0# set bgp group IBGP neighbor 30.1.1.1
    
  4. Configure OSPF on all the interfaces of Router R0, excluding the management interface.

    content_copy zoom_out_map
    [edit protocols]
    user@R0# set ospf traffic-engineering
    user@R0# set ospf area 0.0.0.0 interface lo0.0 passive
    user@R0# set ospf area 0.0.0.0 interface all
    
  5. Configure RSVP on all the interfaces of Router R0, excluding the management interface.

    content_copy zoom_out_map
    [edit protocols]
    user@R0# set rsvp interface all
    user@R0# set rsvp interface fxp0.0 disable
    
  6. Enable next-hop-based dynamic GRE tunnel configuration on Router R0.

    content_copy zoom_out_map
    [edit routing-options]
    user@R0# set dynamic-tunnels gre next-hop-based-tunnel
    
  7. Configure the dynamic GRE tunnel parameters from Router R0 to Router R1.

    content_copy zoom_out_map
    [edit routing-options]
    user@R0# set dynamic-tunnels T1 source-address 192.0.2.1
    user@R0# set dynamic-tunnels T1 gre
    user@R0# set dynamic-tunnels T1 destination-networks 192.0.2.0/24
    
  8. Configure the dynamic GRE tunnel parameters from Router R0 to Router R2.

    content_copy zoom_out_map
    [edit routing-options]
    user@R0# set dynamic-tunnels T2 source-address 198.51.100.1
    user@R0# set dynamic-tunnels T2 gre
    user@R0# set dynamic-tunnels T2 destination-networks 198.51.100.0/24
    
  9. Configure a virtual routing and forwarding (VRF) routing instance on Router R0, and assign the interface connecting to Host 1 to the VRF instance.

    content_copy zoom_out_map
    [edit routing-instances]
    user@R0# set VPN1 instance-type vrf
    user@R0# set VPN1 route-distinguisher 100:100
    user@R0# set VPN1 vrf-target target:100:1
    user@R0# set VPN1 vrf-table-label
    user@R0# set VPN1 interface ge-0/0/2.0
    
  10. Configure an external BGP session with Host 1 for the VRF routing instance.

    content_copy zoom_out_map
    [edit routing-instances]
    user@R0# set VPN1 protocols bgp group External type external
    user@R0# set VPN1 protocols bgp group External family inet unicast
    user@R0# set VPN1 protocols bgp group External peer-as 200
    user@R0# set VPN1 protocols bgp group External neighbor 172.16.0.1
    
  11. Configure anti-spoofing protection for the VRF routing instance on Router R0. This enables reverse path forwarding check for the next-hop-based dynamic tunnels, T1 and T2, on Router 0.

    content_copy zoom_out_map
    [edit routing-instances]
    user@R0# set VPN1 routing-options forwarding-table ip-tunnel-rpf-check mode strict
    

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

content_copy zoom_out_map
user@R0# show interfaces
ge-0/0/0 {
    unit 0 {
        family inet {
            address 192.0.2.1/24;
        }
    }
}
ge-0/0/1 {
    unit 0 {
        family inet {
            address 198.51.100.1/24;
        }
    }
}
ge-0/0/2 {
    vlan-tagging;
    unit 0 {
        vlan-id 1;
        family inet {
            address 172.16.0.1/16;
        }
    }
}
lo0 {
    unit 0 {
        family inet {
            address 10.1.1.1/32;
        }
    }
}
content_copy zoom_out_map
user@R0# show routing-options
router-id 10.1.1.1;
autonomous-system 100;
dynamic-tunnels {
    gre next-hop-based-tunnel;
    T1 {
        source-address 192.0.2.1;
        gre;
        destination-networks {
            192.0.2.0/24;
        }
    }
    T2 {
        source-address 198.51.100.1;
        gre;
        destination-networks {
            198.51.100.0/24;
        }
    }
}
content_copy zoom_out_map
user@R0# show protocols
rsvp {
    interface all;
    interface fxp0.0 {
        disable;
    }
}
bgp {
    group IBGP {
        type internal;
        local-address 10.1.1.1;
        family inet-vpn {
            unicast;
        }
        neighbor 20.1.1.1;
        neighbor 30.1.1.1;
    }
}
ospf {
    traffic-engineering;
    area 0.0.0.0 {
        interface lo0.0 {
            passive;
        }
        interface all;
    }
}
content_copy zoom_out_map
user@R0# show routing-instances
VPN1 {
    instance-type vrf;
    interface ge-0/0/2.0;
    route-distinguisher 100:100;
    vrf-target target:100:1;
    vrf-table-label;
    routing-options {
        forwarding-table {
            ip-tunnel-rpf-check {
                mode strict;
            }
        }
    }
    protocols {
        bgp {
            group External {
                type external;
                family inet {
                    unicast;
                }
                peer-as 200;
                neighbor 172.16.0.1;
            }
        }
    }
}

Verification

Confirm that the configuration is working properly.

Verifying Basic Configuration

Purpose

Verify the OSPF and BGP peering status between the Router R0 and Routers R1 and R2.

Action

From operational mode, run the show ospf neighbor and show bgp summarycommands.

content_copy zoom_out_map
user@R0> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
192.0.2.2        ge-0/0/0.0             Full      20.1.1.1         128    32
198.51.100.2     ge-0/0/1.0             Full      30.1.1.1         128    32

user@R0> show bgp summary
Groups: 2 Peers: 3 Down peers: 1
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
bgp.l3vpn.0          
                       0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
20.1.1.1                100        182        178       0       0     1:20:27 Establ
  bgp.l3vpn.0: 0/0/0/0
30.1.1.1                100        230        225       0       0     1:41:51 Establ
  bgp.l3vpn.0: 0/0/0/0
172.16.0.1              200          0          0       0       0     1:42:08 Establ
Meaning

The OSPF and BGP sessions are up and running between the Routers R0, R1, and R2.

Verifying Dynamic Tunnel Configuration

Purpose

Verify the status of the next-hop-based dynamic GRE tunnels between the Router R0 and Routers R1 and R2.

Action

From operational mode, run the show route table inet.3, and the show dynamic-tunnels database terse commands.

content_copy zoom_out_map
user@R0> show route table inet.3

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.0.2.0/24       *[Tunnel/300] 01:47:57
                      Tunnel
192.0.2.2/24       *[Tunnel/300] 01:47:57
                      Tunnel Composite

198.51.100.0/24    *[Tunnel/300] 01:47:57
                      Tunnel
198.51.100.2/24    *[Tunnel/300] 01:47:57
                      Tunnel Composite
content_copy zoom_out_map
user@R0> show dynamic-tunnels database terse
Table: inet.3

Destination-network: 192.0.2.0/24
Destination 			Source 			Next-hop 					Type 		Status
192.0.2.2/24 	 192.0.2.1 	0xb395e70 nhid 612 		gre 	  Up

Destination-network: 198.51.100.0/24
Destination 			Source 					Next-hop 					Type 		Status
198.51.100.2 	 198.51.100.1 	0xb395e70 nhid 612 		gre 	  Up
Meaning

The two next-hop-based dynamic GRE tunnels, Tunnel 1 and Tunnel 2, are up.

Verifying Anti-Spoofing Protection Configuration

Purpose

Verify that the reverse path forwarding check has been enabled on the VRF routing instance on Router R0.

Action

From the operational mode, run the show krt table VPN1.inet.0 detail.

content_copy zoom_out_map
user@R0> show krt table VPN1.inet.0 detail
KRT tables:
VPN1.inet.0                   : GF: 1 krt-index: 8     ID: 0 kernel-id: 8
        flags: (null)
        tunnel rpf config data : enable, strict, filter [0], 0x2
        tunnel rpf tlv data : enable, strict, filter [0], 0x4
        unicast reverse path: disabled
        fast-reroute-priority: 0
        Permanent NextHops
          Multicast        : 0 Broadcast : 0
          Receive          : 0   Discard   : 0
          Multicast Discard: 0   Reject    : 0
          Local            : 0   Deny      : 0
          Table            : 0
Meaning

The configured reverse path forwarding check is enabled on the VRF routing instance in the strict mode.

Next-Hop-Based Dynamic Tunnel Localization Overview

Next-hop-based dynamic tunnels include generic routing encapsulation (GRE) tunnels and MPLS-over-UDP tunnels. These tunnels provide a scaling advantage over the interface-based tunnels. However, unlike the interface-based tunnels, the next-hop-based dynamic tunnels are anchorless in nature, where the forwarding information of the tunnels is distributed to the Packet Forwarding Engines (PFEs) on every line card on the device. This limits the maximum number of tunnels supported on the device to the tunnel capacity of a single line card. With the support for localization, you can configure next-hop-based dynamic tunnel localization to create the forwarding information only on the PFE of a line card that is designated as the anchor PFE. The PFEs on the other line cards on the device have state forwarding information to steer the packets to the anchor PFE. This provides a scaling advantage by increasing the maximum number of tunnels supported on a device.

Benefits of Next-Hop-Based Dynamic Tunnel Localization

Provides a scaling advantage by increasing the maximum number of tunnels supported on a device.

Use Cases for Next-Hop-Based Dynamic Tunnel Localization

  • The IPsec gateway devices that host a number of MS-MPC are used to terminate IPSec tunnels and are required to support moderate load. This support is affected with the use of next-hop-based dynamic tunnels when the scaling limit of the device is reached. With the localization of next-hop-based dynamic tunnels, the maximum number of the tunnels supported is increased, allowing the device to accommodate more tunnels at the cost of an extra fabric hop.

  • For Internet or VPN gateway devices, such as a virtual public cloud data center, there is a need for the gateway devices to communicate with a large number of servers. The data center servers are reachable through next-hop-based dynamic tunnels. The anchorless property of the dynamic tunnels limits the overall scaling numbers of the device. The gateway devices host multiple MPCs, with increased traffic demands. With the localization of the next-hop-based dynamic tunnels, the tunnels can be spread across the MPCs, thereby facilitating an increase in the tunnel scaling numbers.

Traffic Handling with Localization of Next-Hop-Based Dynamic Tunnels

With support for localization, the next-hop-based dynamic tunnel state is localized to an anchor Packet Forwarding Engine, and the other Packet Forwarding Engine has the tunnel state for steering traffic to the tunnel anchor.

Figure 4 illustrates the forwarding path of next-hop-based dynamic tunnels without localization.

Figure 4: Forwarding Path of Next-Hop-Based Dynamic Tunnels Without LocalizationForwarding Path of Next-Hop-Based Dynamic Tunnels Without Localization

Figure 5 illustrates the forwarding path of next-hop-based dynamic tunnels with localization.

Figure 5: Forwarding Path of Next-Hop-Based Dynamic Tunnels With LocalizationForwarding Path of Next-Hop-Based Dynamic Tunnels With Localization

Configuring Next-Hop-Based Dynamic Tunnels Localization

Localization support can be configured for newly created next-hop-based dynamic tunnels, or for existing non-local dynamic tunnels.

Configuring Localization for New Next-Hop-Based Dynamic Tunnels

The localization of next-hop-based dynamic tunnels uses a policy-based approach to specify prefix groups. In other words, route policies are used to apply the localization properties to the next-hop-based dynamic tunnels. Dynamic tunnel attribute profiles are created and configured under routing options for association with the prefix group using the policy.

  1. Creating dynamic tunnel profiles.

    The dynamic tunnel profile specifies the tunnel type and the anchor Packet Forwarding Engine information. Multiple dynamic tunnel profiles can be created for localization of the dynamic tunnels. The values for the dynamic tunnel type can be GRE, UDP, or BGP-SIGNAL.

    Although BGP-SIGNAL is not a valid tunnel type, on assigning BGP-SIGNAL as the tunnel type, the tunnels created from the BGP-signalled attributes are localized. When using BGP-SIGNAL, the tunnel type is decided based on the type advertised by BGP in its TLV. BGP-SIGNAL tunnels are always next-hop-based tunnels. The GRE tunnels created dynamically by BGP-SIGNAL are always next-hop-based, even if the user has manually configured tunnels created by GRE to use IFLs.

    The anchor Packet Forwarding Engine value is the line card of the anchor Packet Forwarding Engine, for example, pfe-x/y/0. This information can be viewed from the show interfaces terse pfe* command output.

    Sample Configuration:

    content_copy zoom_out_map
    [edit routing-options]
    dynamic-tunnels {
        dynamic-tunnel-attributes attribute-1 {
            dynamic-tunnel-type <GRE | UDP | BGP-SIGNAL>;
            dynamic-tunnel-anchor-pfe pfe-1/0/0;
        }
    }
    
  2. Associating dynamic tunnel profile to prefix list.

    Configuring a policy with dynamic-tunnel-attributes as the action associates the dynamic tunnel to the prefix list. The policy from action allows the creation of tunnel with specified attributes for any matching condition, such as a prefix range, community, or source address of BGP routes, and so on.

    Sample configuration:

    content_copy zoom_out_map
    [edit policy-options]
    policy-statement policy-name {
        term term {
            from {
                <route-filter | next-hop | community>>;
            }
            then {
                dynamic-tunnel-attributes <attribute-name>;
            }
        }
    }
    
  3. Including the tunnel policy under the forwarding table export policy.

    After the policy is configured, it is included in the forwarding table export policy for the parsing of the policy.

    Using the export-policy, the tunnel attributes get associated with the route. Whenever a route from BGP is queued for resolution, the forwarding table export policy is evaluated, and the tunnel attributes are obtained from the policy module based on the applied filters. The obtained tunnel attributes are then attached to the next hop in form of a tunnel composite next hop. The corresponding anchor forwarding structures, based on the Packet Forwarding Engine name and tunnel type, are created and sent to the forwarding table before a tunnel composite next hop is sent. However, if none of the attributes map to the tunnel composite next hop, then the forwarding structure is created on every Packet Forwarding Engine, similar to the non-localized dynamic tunnels.

    Sample configuration:

    content_copy zoom_out_map
    [edit routing-options]
    forwarding-table {
        export  dynamic-tunnel;
    }
    

Configuring Localization for Existing Next-Hop-Based Dynamic Tunnels

CAUTION:

Making on the fly changes to dynamic tunnel attributes can result in an FPC crash due to high memory utilization. Hence, we recommend deactivating the dynamic-tunnels configuration before configuring localization.

To update tunnel attributes for existing next-hop-based dynamic tunnels, the following should be performed:

  1. Deactivate dynamic-tunnels configuration under the [edit routing-options] hierarchy level.

    Sample configuration:

    content_copy zoom_out_map
    [edit routing-options]
    user@host# deactivate dynamic-tunnels
    user@host# commit
    
  2. Change tunnel attributes as required.

  3. Activate dynamic-tunnels configuration under the [edit routing-options] hierarchy level.

    Sample configuration:

    content_copy zoom_out_map
    [edit routing-options]
    user@host# activate dynamic-tunnels
    user@host# commit
    

To configure localization for existing non-local next-hop-based dynamic tunnels:

CAUTION:

Making on the fly changes to configure localization for existing non-local next-hop-based dynamic tunnels can result in an FPC crash due to high memory utilization. Hence, we recommend deactivating the dynamic-tunnels configuration before configuring localization.

  1. Deactivate the dynamic-tunnels configuration at the [edit routing-options] hierarchy level.

  2. Create tunnel-attributes profile and add policy for localizing the dynamic tunnels, similar to new next-hop-based dynamic tunnels.

  3. Activate the dynamic-tunnels configuration.

Troubleshooting Localized Next-Hop-Based Dynamic Tunnels

With localization of next-hop-based dynamic tunnels, the tunnel composite next hops are associated with anchor Packet Forwarding Engine IDs. The following traceroute configuration statements at the [edit routing-options] hierarchy level help in troubleshooting the localized dynamic tunnels:

  • dynamic-tunnels traceoptions flag all—Tracking creation and deletion of tunnel in DTM.

  • resolution traceoptions flag tunnel—Tracking resolver operations on BGP route.

  • forwarding-table traceoptions flag all—Tracking tunnels sent to the kernel.

  • traceoptions flag all—Tracking of route learning process.

The following commands can be used to check if a route is using a localized next-hop-based dynamic tunnel:

  1. show route prefix extensive—To obtain the indirect next hop.

    For example:

    content_copy zoom_out_map
    user@host> show route 1.2.3.4 extensive
    MPLS-over-UDP-PE1.inet.0: 24 destinations, 26 routes (24 active, 0 holddown, 0 hidden)
    1.2.3.4/32 (1 entry, 1 announced)
    TSI:
    KRT in-kernel 1.2.3.4/32 -> {indirect(1048577)}
    Page 0 idx 1, (group pe1-ce1 type External) Type 1 val 0xb209a78 (adv_entry)
       Advertised metrics:
     	Nexthop: Self
     	AS path: [100] I
     	Communities: target:600:1 encapsulation:mpls-in-udp(0xd)
    
  2. show krt indirect-next-hop index indirect-next-hop detail—To check for anchor Packet Forwarding Engine field in the detailed output of the indirect next hop.

    For example:

    content_copy zoom_out_map
    user@host> show krt indirect-next-hop index 1048577 detail
    Indirect Nexthop detail:
    Index: 1048577 Protocol next-hop address: 1.1.1.6
      RIB Table: bgp.l3vpn.0            	Label: Push 299808
      Policy Version: 2                 	References: 11
      Locks: 3                          	0xb227980
      Flags: 0x0
      INH Session ID: 0x0
      Ref RIB Table: unknown
      Export policy detail:
     	(Dynamic tunnel hash : 309985522)
        	Tunnel type: UDP, Reference count: 4, nhid: 1016
        	Destination address: 1.1.1.6, Source address: 1.1.1.2
        	Anchored-PFE: pfe-1/0/0
        	VPN Label: Push 299808, TTL action: prop-ttl
      	IGP FRR Interesting proto count : 11
      	Chain IGP FRR Node Num      	: 1
         	IGP Resolver node(hex)   	: 0xc838b94
         	IGP Route handle(hex)    	: 0xb1d7674  	IGP rt_entry protocol    	: Tunnel
         	IGP Actual Route handle(hex) : 0x0        	IGP Actual rt_entry protocol : Any
    

Unsupported Features for Next-Hop-Based Dynamic Tunnels Localization

Junos OS does not support the following functionality with localization for next-hop-based dynamic tunnels:

  • Chained composite next hops at the [edit routing-options forwarding-table chained-composite-next-hop ingress l3vpn] hierarchy level.

  • Anchor Packet Forwarding Engine resiliency.

    There is no resiliency support for next-hop-based dynamic tunnels with localization. After localization of the next-hop-based dynamic tunnels, the anchor Packer Forwarding Engine becomes the single entity for processing any given tunnel on the device. Although anchor Packer Forwarding Engine resiliency is not supported, for gateway devices, redundancy at the gateway device ensures that when the Packer Forwarding Engine to which the tunnel composite next hop is delegated goes down, the traffic must be rerouted to the redundant gateway device. The routing protocol process monitors the state of the Packer Forwarding Engine, and withdraws BGP advertisement of all the routes pointing to the tunnel composite next hops anchored on that Packer Forwarding Engine.

    Only the anchored Packet Forwarding Engine has the full-fledged tunnel composite next hop and all the other Packet Forwarding Engines have only steering entries to forward traffic to the anchor Packet Forwarding Engine. These steering entries are not withdrawn, when an anchor FPC goes down.

  • Localization of next-hop-based dynamic tunnels is not supported on logical systems.

  • IPv6 is not supported with localization of next-hop-based dynamic tunnels.

  • With localization, the show dynamic-tunnels database summary command does not display accurate tunnels summary when the state of the anchor Packet Forwarding Engine line card is not up. As a workaround, use the show dynamic-tunnels database and show dynamic-tunnels database terse command output.

Overview of Next-Hop-Based Dynamic Tunneling Using IP-Over-IP Encapsulation

Benefits

IP-over-IP tunneling provides the following benefits:

  • Alternative to MPLS over UDP—Can be used as an alternative to MPLS-over-UDP tunneling to provide IP service wherein there is a dedicated device per service.

  • Ability to steer specific traffic—Enables smooth migration when MPLS and IP networks co-exist because routes can be filtered to steer specific traffic over IP tunnels as opposed to MPLS tunnels.

  • Ability to support tunnels at increasing scale—Dynamic tunnel creation using BGP control plane can facilitate tunnel creation at scale.

What is IP-over-IP Dynamic Next Hop-based Tunneling?

An IP network contains edge devices and core devices. To achieve higher scale and reliability among these devices, you need to logically isolate the core network from the external network that the edge devices interact with, by using an overlay encapsulation.

Starting in Junos OS Release 20.3R1, we support an IP-over-IP encapsulation to facilitate IP overlay construction over IP transport network. IP over IP relies on a next hop-based infrastructure to support a higher scale. The feature supports IPv4 encapsulation of IPv6 and IPv4 payload. Among the other overlay encapsulations supported, IP-over-IP encapsulation is the only kind that allows:

  • transit devices to parse the inner payload and use inner packet fields for hash computation

  • customer edge devices to route traffic into and out of the tunnel without any throughput reduction

On MX Series routers, routing protocol daemon (RPD) sends the encapsulation header with tunnel composite nexthop and the Packet Forwarding Engine (PFE) finds the tunnel destination address and forwards the packet. On PTX Series routers and QFX10000 switches, RPD sends fully resolved next hop-based tunnel to the Packet Forwarding Engine. BGP protocol is used to distribute routes and signal dynamic tunnels.

The following illustration depicts how IPv4 or IPv6 traffic are sent from R-1 to R-5 through an IP over IP tunnel established between R-2 and R-4:

IP-over-IP Tunnel Stitching

In Junos OS Release 21.3R1, we introduce IP-over-IP tunnel stitching on MX240, MX480, MX960, PTX1000, PTX10008, PTX10016, and QFX10002. You can use this feature to terminate an IP-over-IP tunnel on a device and initiate another tunnel on the same device. When a device receives the IP-over-IP packet, it de-encapsulates the outer packet header and inner packet lookup occurs. The inner IP packet header then points to another tunnel on the same device, where the same device encapsulates the packet again with another IP-over-IP header.

Example: Configuring Next-Hop-Based IP-Over-IP Dynamic Tunnels

Learn how to configure next hop-based tunnels by using IP-over-IP encapsulation.

Requirements

This example uses the following hardware and software components:

  • 5 MX Series routers.

  • Junos OS Release 20.3R1 or later version.

Overview

Starting in Junos OS Release 20.3R1, we support an IP-over-IP encapsulation to facilitate IP overlay construction over IP transport network. This example shows the establishment of unicast IP-over-IP tunnels between devices with a protocol next hop (PNH) through an IBGP peering between R2 and R4, which are connected over an OSPF core, to exchange routes and signal dynamic tunnels.

Topology

Figure 1 illustrates an IP-over-IP scenario with 5 devices.

In this example, we are exchanging routes from R1 to R5 and vice versa through IP-over-IP dynamic tunnels established between the R2 and R4. Routes from R1 are exported to R2 and routes from R5 are exported to R4, by using the protocol IS-IS. We configure a unicast IPIP tunnel Tunnel-01 from R2 to R4 and another tunnel Tunnel-01 from R4 to R2. Route prefixes that are generated within the network masks from the configured destination-networks of the peer device are used for creating the tunnel and traffic flows in the opposite direction of the routes in the tunnel..

Configuring IP-over-IP Dynamic Tunnels with a Protocol Next Hop

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

R1

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R1-to-R2
set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.1/30
set interfaces xe-0/2/0 unit 0 family iso
set interfaces lo0 unit 0 family inet address 192.168.255.1/32
set interfaces lo0 unit 0 family iso address 49.0001.1920.1682.5501.00
set routing-options router-id 192.168.255.1
set protocols isis interface xe-0/2/0.0
set protocols isis interface lo0.0
set protocols isis level 1 disable

R2

content_copy zoom_out_map
set interfaces xe-0/2/0 description R2-to-R1
set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.2/30
set interfaces xe-0/2/0 unit 0 family iso
set interfaces xe-0/2/1 description R2-to-R3
set interfaces xe-0/2/1 unit 0 family inet address 10.1.23.1/30
set interfaces lo0 unit 0 family inet address 10.1.255.2/32
set interfaces lo0 unit 0 family iso address 49.0001.0010.1255.0002.00
set policy-options policy-statement export-bgp term t1 from protocol bgp
set policy-options policy-statement export-bgp term t1 then accept
set policy-options policy-statement export-isis term t1 from protocol isis
set policy-options policy-statement export-isis term t1 then next-hop self
set policy-options policy-statement export-isis term t1 then accept
set routing-options resolution rib inet.0 resolution-ribs inet.3
set routing-options router-id 10.1.255.2
set routing-options autonomous-system 65000
set routing-options dynamic-tunnels Tunnel-01 source-address 10.1.255.2
set routing-options dynamic-tunnels Tunnel-01 ipip
set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24
set protocols bgp group iBGP type internal
set protocols bgp group iBGP local-address 10.1.255.2
set protocols bgp group iBGP family inet unicast
set protocols bgp group iBGP export export-isis
set protocols bgp group iBGP neighbor 10.1.255.4
set protocols isis interface xe-0/2/0.0 
set protocols isis interface lo0.0
set protocols isis level 1 disable
set protocols isis export export-bgp
set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
set protocols ospf area 0.0.0.0 interface lo0.0

R3

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R3-to-R2
set interfaces xe-0/2/0 unit 0 family inet address 10.1.23.2/30
set interfaces xe-0/2/1 unit 0 description R3-to-R4
set interfaces xe-0/2/1 unit 0 family inet address 10.1.34.1/30
set interfaces lo0 unit 0 family inet address 10.1.255.3/32
set routing-options router-id 10.1.255.3
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0
set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

R4

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R4-to-R3
set interfaces xe-0/2/0 unit 0 family inet address 10.1.34.2/30
set interfaces xe-0/2/1 unit 0 description R4-to-R5
set interfaces xe-0/2/1 unit 0 family inet address 192.168.45.1/30
set interfaces xe-0/2/1 unit 0 family iso
set interfaces lo0 unit 0 family inet address 10.1.255.4/32
set interfaces lo0 unit 0 family iso address 49.0001.0010.1255.0004.00
set policy-options policy-statement export-bgp term t1 from protocol bgp
set policy-options policy-statement export-bgp term t1 then accept
set policy-options policy-statement export-isis term t1 from protocol isis
set policy-options policy-statement export-isis term t1 then next-hop self
set policy-options policy-statement export-isis term t1 then accept
set routing-options resolution rib inet.0 resolution-ribs inet.3
set routing-options router-id 10.1.255.4
set routing-options autonomous-system 65000
set routing-options dynamic-tunnels Tunnel-01 source-address 10.1.255.4
set routing-options dynamic-tunnels Tunnel-01 ipip
set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24
set protocols bgp group iBGP type internal
set protocols bgp group iBGP local-address 10.1.255.4
set protocols bgp group iBGP family inet unicast
set protocols bgp group iBGP export export-isis
set protocols bgp group iBGP neighbor 10.1.255.2
set protocols isis interface xe-0/2/1.0 
set protocols isis interface lo0.0
set protocols isis level 1 disable
set protocols isis export export-bgp
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0
set protocols ospf area 0.0.0.0 interface lo0.0

R5

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R5-to-R4
set interfaces xe-0/2/0 unit 0 family inet address 192.168.45.2/30
set interfaces xe-0/2/0 unit 0 family iso
set interfaces lo0 unit 0 family inet address 192.168.255.5/32
set interfaces lo0 unit 0 family iso address 49.0001.1920.1682.5505.00
set routing-options router-id 192.168.255.5
set protocols isis interface xe-0/2/0.0
set protocols isis interface lo0.0
set protocols isis level 1 disable

Configuring IP-IP dynamic tunnels with a Protocol Next Hop

Step-by-Step Procedure for R1

R1 and R5 have a similar configuration so we will only show the step-by-step procedure for R1.

  1. Enter configuration mode on R1.

  2. Configure the interface connected to R2 and interface lo0. Make sure to configure both family inet and iso. Family iso is needed for protocol IS-IS.

    content_copy zoom_out_map
    [edit]
    user@R1# set interfaces xe-0/2/0 unit 0 description R1-to-R2
    user@R1# set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.1/30
    user@R1# set interfaces xe-0/2/0 unit 0 family iso
    user@R1# set interfaces lo0 unit 0 family inet address 192.168.255.1/32
    user@R1# set interfaces lo0 unit 0 family iso address 49.0001.1920.1682.5501.00
    
  3. Configure the Router ID.

    content_copy zoom_out_map
    [edit]
    user@R1# set routing-options router-id 192.168.255.1
    
  4. Configure protocols IS-IS. Routes are advertised between R1 and R2 using the IS-IS protocol.

    content_copy zoom_out_map
    [edit]
    user@R1# set protocols isis interface xe-0/2/0.0
    user@R1# set protocols isis interface lo0.0
    user@R1# set protocols isis level 1 disable
    
  5. Enter commit on R1 from the configuration mode.

Step-by-Step Procedure for R2

R2 and R4 have a similar configuration so we will only show the step-by-step procedure for R2.

  1. Enter configuration mode on R2.

  2. Configure the interfaces connected to R1 and R3 and interface lo0. Ensure to configure both familyinet and iso on the interface connected to R1 and lo0.

    content_copy zoom_out_map
    [edit]
    user@R2# set interfaces xe-0/2/0 description R2-to-R1
    user@R2# set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.2/30
    user@R2# set interfaces xe-0/2/0 unit 0 family iso
    user@R2# set interfaces xe-0/2/1 description R2-to-R3
    user@R2# set interfaces xe-0/2/1 unit 0 family inet address 10.1.23.1/30
    user@R2# set interfaces lo0 unit 0 family inet address 10.1.255.2/32
    user@R2# set interfaces lo0 unit 0 family iso address 49.0001.0010.1255.0002.00
    
  3. Configure protocols IS-IS for the interface connected to R1. The export policy to advertise BGP routes into IS-IS is shown in the policy configuration step.

    content_copy zoom_out_map
    [edit]
    user@R2# set protocols isis interface xe-0/2/0.0 
    user@R2# set protocols isis interface lo0.0
    user@R2# set protocols isis level 1 disable
    user@R2# set protocols isis export export-bgp
    
  4. Configure the OSPF protocol for the interface connected to R3 for lo0 reachability.

    content_copy zoom_out_map
    [edit]
    user@R2# set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
    user@R2# set protocols ospf area 0.0.0.0 interface lo0.0
    
  5. Configure the router-id and autonomous-system, and IBGP between R2 and R4. The export policy to advertise IS-IS routes into BGP is shown in the policy configuration step.

    content_copy zoom_out_map
    [edit]
    user@R2# set routing-options router-id 10.1.255.2
    user@R2# set routing-options autonomous-system 65000
    user@R2# set protocols bgp group iBGP type internal
    user@R2# set protocols bgp group iBGP local-address 10.1.255.2
    user@R2# set protocols bgp group iBGP family inet unicast
    user@R2# set protocols bgp group iBGP export export-isis
    user@R2# set protocols bgp group iBGP neighbor 10.1.255.4
    
  6. Configure the BGP and IS-IS export policies that were applied during the previous steps. The export-bgp policy is applied to protocols IS-IS as an export to advertise BGP routes into IS-IS and the export-isis policy is applied to BGP as an export to advertise IS-IS routes into BGP. The next-hop self option allows R2 to advertise the IS-IS routes into BGP with R2 as the next-hop instead of the interface next-hop of R1.

    content_copy zoom_out_map
    [edit]
    user@R2# set policy-options policy-statement export-bgp term t1 from protocol bgp
    user@R2# set policy-options policy-statement export-bgp term t1 then accept
    user@R2# set policy-options policy-statement export-isis term t1 from protocol isis
    user@R2# set policy-options policy-statement export-isis term t1 then next-hop self
    user@R2# set policy-options policy-statement export-isis term t1 then accept
    
  7. Configure the IP-IP dynamic tunnel Tunnel-01 from R2 to R4. The configuration option resolution-ribs inet.3 allows for route resolution to take place in inet.3 and is needed to establish the tunnel.

    content_copy zoom_out_map
    [edit]
    user@R2# set routing-options resolution rib inet.0 resolution-ribs inet.3
    user@R2# set routing-options dynamic-tunnels Tunnel-01 source-address 10.1.255.2
    user@R2# set routing-options dynamic-tunnels Tunnel-01 ipip
    user@R2# set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24
    
  8. (Optional) - Alternative configuration for the IP-IP dynamic tunnel Tunnel-01 from R2 to R4. Instead of configuring the resolution-ribs inet.3 you can configure the tunnel preference lower than the protocol next-hop preference for the route to the tunnel endpoint. The route for R4 is learned using OSPF and has a preference of 10 and the default preference of the tunnel is 305. Configure the tunnel preference lower than the OSPF preference allows the tunnel to be preferred and to establish.

    content_copy zoom_out_map
    [edit]
    user@R2# set routing-options dynamic-tunnels Tunnel-01 source-address 10.1.255.2
    user@R2# set routing-options dynamic-tunnels Tunnel-01 ipip
    user@R2# set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24 preference 9
    
  9. Enter commit from the configuration mode on R2.

Step-by-Step Procedure for R3
  1. Enter configuration mode on R3.

  2. Configure the interfaces connected to R2 and R4 and interface lo0.

    content_copy zoom_out_map
    [edit]
    user@R3# set interfaces xe-0/2/0 unit 0 description R3-to-R2
    user@R3# set interfaces xe-0/2/0 unit 0 family inet address 10.1.23.2/30
    user@R3# set interfaces xe-0/2/1 unit 0 description R3-to-R4
    user@R3# set interfaces xe-0/2/1 unit 0 family inet address 10.1.34.1/30
    user@R3# set interfaces lo0 unit 0 family inet address 10.1.255.3/32
    
  3. Configure the Router ID.

    content_copy zoom_out_map
    [edit]
    user@R3# set routing-options router-id 10.1.255.3
    
  4. Configure the OSPF protocol for the interfaces connected to R2 and R4 for lo0 reachability.

    content_copy zoom_out_map
    [edit]
    user@R3# set protocols ospf area 0.0.0.0 interface xe-0/2/0.0
    user@R3# set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
    user@R3# set protocols ospf area 0.0.0.0 interface lo0.0 passive
    
  5. Enter commit from configuration mode on R3 device.

Results

Verify your configuration by checking the below configurations from devices as follows:

Here's how you can verify configurations on R2:

user@R2# show interfaces

content_copy zoom_out_map
xe-0/2/0 {
    description R2-to-R1;
    unit 0 {
        family inet {
            address 192.168.12.2/30;
        }
        family iso;
    }
}
xe-0/2/1 {
    description R2-to-R3;
    unit 0 {
        family inet {
            address 10.1.23.1/30;
        }
    }
}
lo0 {
    unit 0 {
        family inet {
            address 10.1.255.2/32;
        }                               
        family iso {
            address 49.0001.0010.1255.0002.00;
        }
    }
}

user@R2# show routing-options

content_copy zoom_out_map
resolution {
    rib inet.0 {
        resolution-ribs inet.3;
    }
}
router-id 10.1.255.2;
autonomous-system 65000;
dynamic-tunnels {
    Tunnel-01 {
        source-address 10.1.255.2;
        ipip;
        destination-networks {
            10.1.255.0/24;
        }
    }
}

user@R2# show protocols

content_copy zoom_out_map
bgp {
    group iBGP {
        type internal;
        local-address 10.1.255.2;
        family inet {
            unicast;
        }
        export export-isis;
        neighbor 10.1.255.4;
    }
}
isis {
    interface xe-0/2/0.0;
    interface lo0.0;
    level 1 disable;
    export export-bgp;
}
ospf {
    area 0.0.0.0 {
        interface xe-0/2/1.0;
        interface lo0.0;
    }
}

user@R2# show policy-options

content_copy zoom_out_map
policy-statement export-bgp {
    term t1 {
        from protocol bgp;
        then accept;
    }
}
policy-statement export-isis {
    term t1 {
        from protocol isis;
        then {
            next-hop self;
            accept;
        }
    }
}

Verification

Verify Dynamic Tunnel Database
Purpose

To verify the dynamic tunnel database information, use the show dynamic-tunnels database operational mode command.

Action
content_copy zoom_out_map
user@R2> show dynamic-tunnels database
*- Signal Tunnels #- PFE-down
Table: inet.3

Destination-network: 10.1.255.0/24

Tunnel to: 10.1.255.4/32
  Reference count: 3
  Next-hop type: IPoIP (forwarding-nexthop)
    Source address: 10.1.255.2
    Next hop: tunnel-composite, 0x76b6c50, nhid 515
      Reference count: 2
      Ingress Route: [OSPF] 10.1.255.4/32, via metric 2
      Traffic Statistics: Packets 0, Bytes 0 
      State: Up
  Aggregate Traffic Statistics:
    Tunnel Encapsulation: Dest 10.1.255.4, Src 10.1.255.2, IPoIP, Tunnel-Id 1
    Traffic Statistics: Packets 0, Bytes 0 
content_copy zoom_out_map
user@R4> show dynamic-tunnels database
*- Signal Tunnels #- PFE-down
Table: inet.3       

Destination-network: 10.1.255.0/24

Tunnel to: 10.1.255.2/32
  Reference count: 3
  Next-hop type: IPoIP (forwarding-nexthop)
    Source address: 10.1.255.4
    Next hop: tunnel-composite, 0x76b6c50, nhid 513
      Reference count: 2
      Ingress Route: [OSPF] 10.1.255.2/32, via metric 2
      Traffic Statistics: Packets 0, Bytes 0 
      State: Up
  Aggregate Traffic Statistics:
    Tunnel Encapsulation: Dest 10.1.255.2, Src 10.1.255.4, IPoIP, Tunnel-Id 1
    Traffic Statistics: Packets 0, Bytes 0
Meaning

The output indicates that an IPoIP tunnel is established between R2 (192.168.0.21 source) and R4 (192.168.0.41 destination) and another IPoIP tunnel is established between R4 (192.168.0.41 source) and R2 (192.168.0.21 destination).

Verify Route Table in inet.3
Purpose

To verify routes generated on inet.3 table, use the show route table inet.3 operational mode command.

Action
content_copy zoom_out_map
user@R2> show route table inet.3

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.255.0/24      *[Tunnel/305] 02:02:44
                       Tunnel
10.1.255.4/32      *[Tunnel/305] 02:02:44, metric 2
                       Tunnel Composite, IPoIP (src 10.1.255.2 dest 10.1.255.4)
content_copy zoom_out_map
user@R4> show route table inet.3 

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.255.0/24      *[Tunnel/305] 6d 01:35:50
                       Tunnel
10.1.255.2/32      *[Tunnel/305] 6d 01:35:48, metric 2
                       Tunnel Composite, IPoIP (src 10.1.255.4 dest 10.1.255.2)
Meaning

The output indicates the route used for resolving the BGP traffic that will use the tunnel.

Verify BGP Routes Using the Tunnel
Purpose

To verify BGP routes received on R2 and R4 for R1 and R5 are using the tunnel.

Action
content_copy zoom_out_map
user@R2> show route protocol bgp

inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.255.5/32   *[BGP/170] 02:42:48, MED 10, localpref 100, from 10.1.255.4
                      AS path: I, validation-state: unverified
                    >  via Tunnel Composite, IPoIP (src 10.1.255.2 dest 10.1.255.4)

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
content_copy zoom_out_map
user@R4> show route protocol bgp

inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.255.1/32   *[BGP/170] 00:13:30, MED 10, localpref 100, from 10.1.255.2
                      AS path: I, validation-state: unverified
                    >  via Tunnel Composite, IPoIP (src 10.1.255.4 dest 10.1.255.2)

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Meaning

The output indicates that R2 is using the tunnel for the BGP route to R5, and R4 is using the tunnel for the BGP route to R1.

Verify End-to-End Reachability
Purpose

Verify R1 can ping R5 by using the ping 192.168.255.5 source 192.168.255.1 count 2 operational mode command.

Action
content_copy zoom_out_map
user@R1>ping 192.168.255.5 source 192.168.255.1 count 2
PING 192.168.255.5 (192.168.255.5): 56 data bytes
64 bytes from 192.168.255.5: icmp_seq=0 ttl=62 time=5.565 ms
64 bytes from 192.168.255.5: icmp_seq=1 ttl=62 time=5.957 ms

--- 192.168.255.5 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.565/5.761/5.957/0.196 ms
Meaning

The output from R1 shows that R1 can ping R5.

Example: Configure an IPoIP Tunnel in an MPLS Environment with LDP tunnel, Resolved Through inetcolor.0 Using Static Configuration

By default, MPLS has a higher preference than IP. For example, with MPLS and LDP configured among R2, R3, and R4, wherein R2 is reachable with R4 through LDP, routes from R2 will get resolved over LDP, instead of IP-over-IP, because of the higher preference.

If you prefer to have a particular route to resolve over the IP-over-IP instead of LDP, you can do so by creating an inetcolor table, where IP-over-IP has a higher preference and setting BGP to resolve that route over inetcolor table instead of inet3 table. The following example shows you how to do so by using static configuration.

Topology

In this example, we are exchanging routes from R1 to R5 and vice versa through IP-over-IP dynamic tunnels established between the R2 and R4. Routes from R1 are exported to R2 and routes from R5 are exported to R4, by using the protocol IS-IS. We configure a unicast IPIP tunnel Tunnel-01 from R2 to R4 and another tunnel Tunnel-01 from R4 to R2. Route prefixes that are generated within the network masks from the configured destination-networks of the peer device are used for creating the tunnel and traffic flows in the opposite direction of the routes in the tunnel.

CLI Quick Configuration

R1

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R1-to-R2
set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.1/30
set interfaces xe-0/2/0 unit 0 family iso
set interfaces lo0 unit 0 family inet address 192.168.255.1/32
set interfaces lo0 unit 0 family iso address 49.0001.1920.1682.5501.00
set routing-options router-id 192.168.255.1
set protocols isis interface xe-0/2/0.0
set protocols isis interface lo0.0
set protocols isis level 1 disable

R2

content_copy zoom_out_map
set interfaces xe-0/2/0 description R2-to-R1
set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.2/30
set interfaces xe-0/2/0 unit 0 family iso
set interfaces xe-0/2/1 description R2-to-R3
set interfaces xe-0/2/1 unit 0 family inet address 10.1.23.1/30
set interfaces xe-0/2/1 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.1.255.2/32
set interfaces lo0 unit 0 family iso address 49.0001.0010.1255.0002.00
set policy-options policy-statement export-bgp term t1 from protocol bgp
set policy-options policy-statement export-bgp term t1 then accept
set policy-options policy-statement export-isis term t1 from protocol isis
set policy-options policy-statement export-isis term t1 then next-hop self
set policy-options policy-statement export-isis term t1 then accept
set policy-options policy-statement ipip-tunnel-color term term-01 from route-filter 192.168.255.5/32 exact
set policy-options policy-statement ipip-tunnel-color term term-01 then community add red
set policy-options policy-statement ipip-tunnel-color term term-01 then accept
set policy-options policy-statement set-dynamic-tunnel-ep term t1 from route-filter 10.1.255.4/32 exact
set policy-options policy-statement set-dynamic-tunnel-ep term t1 then tunnel-end-point-address 10.1.255.4
set policy-options policy-statement set-dynamic-tunnel-ep term t1 then accept
set policy-options community red members color:0:100
set routing-options router-id 10.1.255.2
set routing-options autonomous-system 65000
set routing-options dynamic-tunnels Tunnel-01 source-address 10.1.255.2
set routing-options dynamic-tunnels Tunnel-01 ipip
set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24 dyn-tunnel-attribute-policy set-dynamic-tunnel-ep
set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24 colors 100
set protocols bgp group iBGP type internal
set protocols bgp group iBGP local-address 10.1.255.2
set protocols bgp group iBGP import ipip-tunnel-color
set protocols bgp group iBGP family inet unicast extended-nexthop-color
set protocols bgp group iBGP export export-isis
set protocols bgp group iBGP neighbor 10.1.255.4
set protocols isis interface xe-0/2/0.0
set protocols isis interface lo0.0
set protocols isis level 1 disable
set protocols isis export export-bgp
set protocols ldp interface xe-0/2/1.0
set protocols mpls interface xe-0/2/1.0
set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
set protocols ospf area 0.0.0.0 interface lo0.0

R3

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R3-to-R2
set interfaces xe-0/2/0 unit 0 family inet address 10.1.23.2/30
set interfaces xe-0/2/0 unit 0 family mpls
set interfaces xe-0/2/1 unit 0 description R3-to-R4
set interfaces xe-0/2/1 unit 0 family inet address 10.1.34.1/30
set interfaces xe-0/2/1 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.1.255.3/32
set routing-options router-id 10.1.255.3
set protocols ldp interface xe-0/2/0.0
set protocols ldp interface xe-0/2/1.0
set protocols mpls interface xe-0/2/0.0
set protocols mpls interface xe-0/2/1.0
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0
set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

R4

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R4-to-R3
set interfaces xe-0/2/0 unit 0 family inet address 10.1.34.2/30
set interfaces xe-0/2/0 unit 0 family mpls
set interfaces xe-0/2/1 unit 0 description R4-to-R5
set interfaces xe-0/2/1 unit 0 family inet address 192.168.45.1/30
set interfaces xe-0/2/1 unit 0 family iso
set interfaces lo0 unit 0 family inet address 10.1.255.4/32
set interfaces lo0 unit 0 family iso address 49.0001.0010.1255.0004.00
set policy-options policy-statement export-bgp term t1 from protocol bgp
set policy-options policy-statement export-bgp term t1 then accept
set policy-options policy-statement export-isis term t1 from protocol isis
set policy-options policy-statement export-isis term t1 then next-hop self
set policy-options policy-statement export-isis term t1 then accept
set policy-options policy-statement ipip-tunnel-color term term-01 from route-filter 192.168.255.1/32 exact
set policy-options policy-statement ipip-tunnel-color term term-01 then community add red
set policy-options policy-statement ipip-tunnel-color term term-01 then accept
set policy-options policy-statement set-dynamic-tunnel-ep term t1 from route-filter 10.1.255.2/32 exact
set policy-options policy-statement set-dynamic-tunnel-ep term t1 then tunnel-end-point-address 10.1.255.2
set policy-options policy-statement set-dynamic-tunnel-ep term t1 then accept
set policy-options community red members color:0:100
set routing-options router-id 10.1.255.4
set routing-options autonomous-system 65000
set routing-options dynamic-tunnels Tunnel-01 source-address 10.1.255.4
set routing-options dynamic-tunnels Tunnel-01 ipip
set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24 dyn-tunnel-attribute-policy set-dynamic-tunnel-ep
set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24 colors 100
set protocols bgp group iBGP type internal
set protocols bgp group iBGP local-address 10.1.255.4
set protocols bgp group iBGP import ipip-tunnel-color
set protocols bgp group iBGP family inet unicast extended-nexthop-color
set protocols bgp group iBGP export export-isis
set protocols bgp group iBGP neighbor 10.1.255.2
set protocols isis interface xe-0/2/1.0
set protocols isis interface lo0.0
set protocols isis level 1 disable
set protocols isis export export-bgp
set protocols ldp interface xe-0/2/0.0
set protocols mpls interface xe-0/2/0.0
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0
set protocols ospf area 0.0.0.0 interface lo0.0

R5

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R5-to-R4
set interfaces xe-0/2/0 unit 0 family inet address 192.168.45.2/30
set interfaces xe-0/2/0 unit 0 family iso
set interfaces lo0 unit 0 family inet address 192.168.255.5/32
set interfaces lo0 unit 0 family iso address 49.0001.1920.1682.5505.00
set routing-options router-id 192.168.255.5
set protocols isis interface xe-0/2/0.0
set protocols isis interface lo0.0
set protocols isis level 1 disable

Procedure

Step-by-Step Procedure for R1

R1 and R5 have a similar configuration so we will only show the step-by-step procedure for R1.

  1. Enter configuration mode on R1.

  2. Configure the interface connected to R2 and interface lo0. Make sure to configure both family inet and iso. Family iso is needed for protocol IS-IS.

    content_copy zoom_out_map
    [edit]
    user@R1# set interfaces xe-0/2/0 unit 0 description R1-to-R2
    user@R1# set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.1/30
    user@R1# set interfaces xe-0/2/0 unit 0 family iso
    user@R1# set interfaces lo0 unit 0 family inet address 192.168.255.1/32
    user@R1# set interfaces lo0 unit 0 family iso address 49.0001.1920.1682.5501.00
    
  3. Configure the Router ID.

    content_copy zoom_out_map
    [edit]
    user@R1# set routing-options router-id 192.168.255.1
    
  4. Configure protocols IS-IS. Routes are advertised between R1 and R2 using the IS-IS protocol.

    content_copy zoom_out_map
    [edit]
    user@R1# set protocols isis interface xe-0/2/0.0
    user@R1# set protocols isis interface lo0.0
    user@R1# set protocols isis level 1 disable
    
  5. Enter commit on R1 from the configuration mode.

Step-by-Step Procedure for R2

R2 and R4 have a similar configuration so we will only show the step-by-step procedure for R2.

  1. Enter configuration mode on R2.

  2. Configure the interfaces connected to R1 and R3 and interface lo0. Ensure to configure both familyinet and iso on the interface connected to R1 and lo0, and to configure both familyinet and mpls on the interface connected to R3.

    content_copy zoom_out_map
    [edit]
    user@R2# set interfaces xe-0/2/0 description R2-to-R1
    user@R2# set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.2/30
    user@R2# set interfaces xe-0/2/0 unit 0 family iso
    user@R2# set interfaces xe-0/2/1 description R2-to-R3
    user@R2# set interfaces xe-0/2/1 unit 0 family inet address 10.1.23.1/30
    user@R2# set interfaces xe-0/2/0 unit 0 family mpls
    user@R2# set interfaces lo0 unit 0 family inet address 10.1.255.2/32
    user@R2# set interfaces lo0 unit 0 family iso address 49.0001.0010.1255.0002.00
    
  3. Configure protocols IS-IS for the interface connected to R1. The export policy to advertise BGP routes into IS-IS is shown in the policy configuration step.

    content_copy zoom_out_map
    [edit]
    user@R2# set protocols isis interface xe-0/2/0.0 
    user@R2# set protocols isis interface lo0.0
    user@R2# set protocols isis level 1 disable
    user@R2# set protocols isis export export-bgp
    
  4. Configure the OSPF protocol for the interface connected to R3 for lo0 reachability.

    content_copy zoom_out_map
    [edit]
    user@R2# set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
    user@R2# set protocols ospf area 0.0.0.0 interface lo0.0
    
  5. Configure the LDP and MPLS protocols for the interface connected to R3.

    content_copy zoom_out_map
    [edit]
    user@R2# set protocols ldp interface xe-0/2/1.0
    user@R2# set protocols mpls interface xe-0/2/1.0
    
  6. Configure the router-id and autonomous-system under the routing-options hierarchy, and configure IBGP between R2 and R4. The import policy to add a community to the routes learned using BGP and the export policy to advertise IS-IS routes into BGP is shown in the policy configuration step. Ensure to include extended-nexthop-color option to the family inet unicast configuration to allow resolution using the inetcolor.0 table.

    content_copy zoom_out_map
    [edit]
    user@R2# set routing-options router-id 10.1.255.2
    user@R2# set routing-options autonomous-system 65000
    user@R2# set protocols bgp group iBGP type internal
    user@R2# set protocols bgp group iBGP local-address 10.1.255.2
    user@R2# set protocols bgp group iBGP import ipip-tunnel-color
    user@R2# set protocols bgp group iBGP family inet unicast extended-nexthop-color
    user@R2# set protocols bgp group iBGP export export-isis
    user@R2# set protocols bgp group iBGP neighbor 10.1.255.4
  7. Configure the IP-IP dynamic tunnel Tunnel-01 from R2 to R4. The colors configuration option allows the tunnel to be created in the inetcolor.0 route table. The dyn-tunnel-attribute-policy set-dynamic-tunnel-ep configures a static tunnel endpoint. The policy is shown with the policy configuration step.

    content_copy zoom_out_map
    [edit]
    user@R2# set routing-options dynamic-tunnels Tunnel-01 source-address 10.1.255.2
    user@R2# set routing-options dynamic-tunnels Tunnel-01 ipip
    user@R2# set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24 dyn-tunnel-attribute-policy set-dynamic-tunnel-ep
    user@R2# set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24 colors 100
    
  8. Configure the policies that were applied during the previous configuration steps. The export-bgp policy advertises BGP routes into IS-IS. The export-isis policy advertises IS-IS routes into BGP with changing the next-hop to R2. The ipip-tunnel-color policy applies the community to the route that is matched on in the colors configuration for the dynamic tunnel. The set-dynamic-tunnel-ep policy configures R4 as the tunnel endpoint.

    content_copy zoom_out_map
    [edit]
    user@R2# set policy-options policy-statement export-bgp term t1 from protocol bgp
    user@R2# set policy-options policy-statement export-bgp term t1 then accept
    user@R2# set policy-options policy-statement export-isis term t1 from protocol isis
    user@R2# set policy-options policy-statement export-isis term t1 then next-hop self
    user@R2# set policy-options policy-statement export-isis term t1 then accept
    user@R2# set policy-options policy-statement ipip-tunnel-color term term-01 from route-filter 192.168.255.5/32 exact
    user@R2# set policy-options policy-statement ipip-tunnel-color term term-01 then community add red
    user@R2# set policy-options policy-statement ipip-tunnel-color term term-01 then accept
    user@R2# set policy-options policy-statement set-dynamic-tunnel-ep term t1 from route-filter 10.1.255.4/32 exact
    user@R2# set policy-options policy-statement set-dynamic-tunnel-ep term t1 then tunnel-end-point-address 10.1.255.4
    user@R2# set policy-options policy-statement set-dynamic-tunnel-ep term t1 then accept
    user@R2# set policy-options community red members color:0:100
    
  9. Enter commit from the configuration mode.

Step-by-Step Procedure for R3
  1. Enter configuration mode on R3.

  2. Configure the interfaces connected to R2 and R4 and interface lo0. Ensure to configure both family inet and mpls on the interfaces connected to R2 and R4.

    content_copy zoom_out_map
    [edit]
    user@R3# set interfaces xe-0/2/0 unit 0 description R3-to-R2
    user@R3# set interfaces xe-0/2/0 unit 0 family inet address 10.1.23.2/30
    user@R3# set interfaces xe-0/2/0 unit 0 family mpls
    user@R3# set interfaces xe-0/2/1 unit 0 description R3-to-R4
    user@R3# set interfaces xe-0/2/1 unit 0 family inet address 10.1.34.1/30
    user@R3# set interfaces xe-0/2/1 unit 0 family mpls
    user@R3# set interfaces lo0 unit 0 family inet address 10.1.255.3/32
    
  3. Configure the Router ID.

    content_copy zoom_out_map
    [edit]
    user@R3# set routing-options router-id 10.1.255.3
    
  4. Configure the OSPF protocol for the interfaces connected to R2 and R4 for lo0 reachability.

    content_copy zoom_out_map
    [edit]
    user@R3# set protocols ospf area 0.0.0.0 interface xe-0/2/0.0
    user@R3# set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
    user@R3# set protocols ospf area 0.0.0.0 interface lo0.0 passive
    
  5. Configure the LDP and MPLS protocols for the interfaces connected to R2 and R4.

    content_copy zoom_out_map
    [edit]
    user@R2# set protocols ldp interface xe-0/2/0.0
    user@R2# set protocols ldp interface xe-0/2/1.0
    user@R2# set protocols mpls interface xe-0/2/0.0
    user@R2# set protocols mpls interface xe-0/2/1.0
    
  6. Enter commit from configuration mode on R3 device.

Results

Verify your configuration by checking the below configurations from the devices.

Here's how you can check the configurations on R2:

user@R2# show interfaces

content_copy zoom_out_map
xe-0/2/0 {
    description R2-to-R1;
    unit 0 {
        family inet {
            address 192.168.12.2/30;
        }
        family iso;
    }
}
xe-0/2/1 {
    description R2-to-R3;
    unit 0 {
        family inet {
            address 10.1.23.1/30;
        }
        family mpls;
    }
}
lo0 {
    apply-groups-except global;
    unit 0 {
        family inet {
            address 10.1.255.2/32;
        }
        family iso {
            address 49.0001.0010.1255.0002.00;
        }
    }
}

user@R2# show protocols

content_copy zoom_out_map
bgp {
    group iBGP {
        type internal;
        local-address 10.1.255.2;
        import ipip-tunnel-color;
        family inet {
            unicast {
                extended-nexthop-color;
            }
        }
        export export-isis;
        neighbor 10.1.255.4;
    }
}
isis {
    interface xe-0/2/0.0;
    interface lo0.0;
    level 1 disable;
    export export-bgp;
}
ldp {
    interface xe-0/2/1.0;
}
mpls {
    interface xe-0/2/1.0;
}
ospf {
    area 0.0.0.0 {
        interface xe-0/2/1.0;
        interface lo0.0;
    }
}

user@R2#show routing-options

content_copy zoom_out_map
router-id 10.1.255.2;
autonomous-system 65000;
dynamic-tunnels {
    Tunnel-01 {
        source-address 10.1.255.2;
        ipip;
        destination-networks {
            10.1.255.0/24 {
                dyn-tunnel-attribute-policy set-dynamic-tunnel-ep;
                colors 100;
            }
        }
    }
}

user@R2#show policy-options

content_copy zoom_out_map
policy-statement export-bgp {
    term t1 {
        from protocol bgp;
        then accept;
    }
}
policy-statement export-isis {
    term t1 {
        from protocol isis;
        then {
            next-hop self;
            accept;
        }
    }
}
policy-statement ipip-tunnel-color {
    term term-01 {
        from {
            route-filter 192.168.255.5/32 exact;
        }
        then {
            community add red;
            accept;
        }
    }
}
policy-statement set-dynamic-tunnel-ep {
    term t1 {
        from {
            route-filter 10.1.255.4/32 exact;
        }
        then {
            tunnel-end-point-address 10.1.255.4;
            accept;
        }
    }
}
community red members color:0:100;

Verification

Verify Route Resolution
Purpose

To verify the route resolution of routes in both inet.3 and inetcolor.0 tables, use the show route table inet.3 and show route table inetcolor.0 operational mode commands.

Action
content_copy zoom_out_map
user@R2> show route table inet.3

inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.255.0/24      *[Tunnel/305] 00:12:21
                       Tunnel
10.1.255.3/32      *[LDP/9] 1d 19:37:01, metric 1
                    >  to 10.1.23.2 via xe-0/2/1.0
10.1.255.4/32      *[LDP/9] 1d 19:32:25, metric 1
                    >  to 10.1.23.2 via xe-0/2/1.0, Push 299792
                    [Tunnel/305] 00:13:38, metric 2
                       Tunnel Composite, IPoIP (src 10.1.255.2 dest 10.1.255.4)
content_copy zoom_out_map
user@R2> show route table inetcolor.0

inetcolor.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.255.0-0<c>/24                
                   *[Tunnel/305] 00:13:26
                       Tunnel
10.1.255.4-100<c>/64                
                   *[Tunnel/305] 00:13:26, metric 2
                       Tunnel Composite, IPoIP (src 10.1.255.2 dest 10.1.255.4-100<c>)
Meaning

The R2 output indicates that on inet.3 table, the route 10.1.255.4 is getting resolved by LDP because of higher preference than IP-over-IP. On the other hand, in the newly created inetcolor.0 table, the route 10.1.255.4 is getting resolved through IP-over-IP tunnel with <c> attached.

Verify Dynamic Tunnel Database
Purpose

To verify the IP-over-IP dynamic tunnel created by routes in the inetcolor.0 table, use the show dynamic-tunnels database terse operational mode command.

Action
content_copy zoom_out_map
user@R2>show dynamic-tunnels database terse
*- Signal Tunnels #- PFE-down
Table: inet.3       

Destination-network: 10.1.255.0/24

*- Signal Tunnels #- PFE-down
Table: inetcolor.0  

Destination-network: 10.1.255.0-0<c>/24
Destination                      Source          Next-hop                 Type       Status
10.1.255.4-100<c>/64             10.1.255.2      0x76b71cc nhid 592       IPoIP      Up (via metric 2, tunnel-endpoint 10.1.255.4)
Meaning

The R2 output indicates that the route 192.168.0.41 has created a next-hop-based dynamic tunnel.

Verify Route Next-Hops
Purpose

To verify all next-hops of the route that is set to resolve through IP-over-IP, use the show route 192.168.255.5 extensive expanded-nh operational mode command.

Action
content_copy zoom_out_map
user@R2>show route 192.168.255.5 extensive expanded-nh

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
192.168.255.5/32 (1 entry, 1 announced)
Installed-nexthop:
Indr Composite (0x76b7238) 10.1.255.4-100<c>
  Krt_cnh (0x6fb1928) Index:593
    Krt_inh (0x7164d3c) Index:1048575 PNH: 10.1.255.4-100<c>
      Tun-comp (0x76b71cc) Index:592 IPoIP src 10.1.255.2 dest 10.1.255.4-100<c> tunnel-endpoint 10.1.255.4
TSI:
KRT in-kernel 192.168.255.5/32 -> {composite(593)}
IS-IS level 2, LSP fragment 0
        *BGP    Preference: 170/-101
                Next hop type: Indirect, Next hop index: 0
                Address: 0x76b7238
                Next-hop reference count: 2
                Source: 10.1.255.4
                Next hop type: Tunnel Composite, Next hop index: 592
                Next hop: via Tunnel Composite, IPoIP (src 10.1.255.2 dest 10.1.255.4-100<c> tunnel-endpoint 10.1.255.4), selected
                Protocol next hop: 10.1.255.4-100<c>
                Composite next hop: 0x6fb1928 593 INH Session ID: 0
                Indirect next hop: 0x7164d3c 1048575 INH Session ID: 0
                State: <Active Int Ext> 
                Local AS: 65000 Peer AS: 65000
                Age: 20:14      Metric: 10      Metric2: 2 
                Validation State: unverified 
                Task: BGP_65000.10.1.255.4
                Announcement bits (2): 0-KRT 5-IS-IS 
                AS path: I 
                Communities: color:0:100
                Accepted
                Localpref: 100
                Router ID: 10.1.255.4
                Route-nexthop:
                Indr (0x76b7238) 10.1.255.4-100<c>
                  Krt_cnh (0x6fb1928) Index:593
                    Krt_inh (0x7164d3c) Index:1048575
                      Tun-comp (0x76b71cc) Index:592
                Thread: junos-main 
                Composite next hops: 1
                        Protocol next hop: 10.1.255.4-100<c> Metric: 2
                        Composite next hop: 0x6fb1928 593 INH Session ID: 0
                        Indirect next hop: 0x7164d3c 1048575 INH Session ID: 0
                        Indirect path forwarding next hops: 1
                                Next hop type: Tunnel Composite
                                Tunnel type: IPoIP, (forwarding-nexthop), Reference count: 2, nhid: 592
                                Destination address: 10.1.255.4-100<c>, Source address: 10.1.255.2
                                Tunnel endpoint: 10.1.255.4
                                10.1.255.4-100<c>/64 Originating RIB: inetcolor.0
                                  Metric: 2 Node path count: 1
                                  Forwarding nexthops: 1
                                        Next hop type: Tunnel Composite
                                        Tunnel type: IPoIP, (extended-attr), Reference count: 1, nhid: 0
                                        Destination address: 10.1.255.4-100<c>, Source address: 10.1.255.2
Meaning

The output from R2 shows the expanded next hop for the 192.168.255.5 route. As R2 is an MX Series router, it sends a protocol next hop and an indirect next hop.

Verify End-to-End Reachability
Purpose

Verify R1 can ping R5 by using the ping 192.168.255.5 source 192.168.255.1 count 2 operational mode command.

Action
content_copy zoom_out_map
user@R1>ping 192.168.255.5 source 192.168.255.1 count 2
PING 192.168.255.5 (192.168.255.5): 56 data bytes
64 bytes from 192.168.255.5: icmp_seq=0 ttl=62 time=6.009 ms
64 bytes from 192.168.255.5: icmp_seq=1 ttl=62 time=5.398 ms

--- 192.168.255.5 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.398/5.704/6.009/0.306 ms
Meaning

The output from R1 shows that R1 can ping R5.

Example: Configure an IPoIP Tunnel with LDP tunnel in an MPLS Cloud, Resolved through inetcolor.0 Using BGP Signaling

In an MPLS environment with LDP enabled, BGP routes get resolved through LDP on inet.3 table because MPLS has higher preference than IP.

If you still prefer to have your routes resolved through IP-over-IP in the MPLS environment, you can do so by creating an inetcolor.0 table that assigns higher preference for IP-over-IP and resolve chosen routes through IP-over-IP. To enable this feature by using BGP, the route resolution is performed on the remote end device of the tunnel and with the export policy configured on the remote device, routes are received and advertised through BGP signaling. This example shows how to configure this by using the BGP protocol configuration.

In this example, we are exchanging routes from R1 to R5 and vice versa through IP-over-IP dynamic tunnels established between the R2 and R4. Routes from R1 are exported to R2 and routes from R5 are exported to R4, by using the protocol IS-IS. We configure a unicast IPIP tunnel Tunnel-01 from R2 to R4 and another tunnel Tunnel-01 from R4 to R2. Route prefixes that are generated within the network masks from the configured destination-networks of the peer device are used for creating the tunnel and traffic flows in the opposite direction of the routes in the tunnel.

CLI Quick Configuration

R1

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R1-to-R2
set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.1/30
set interfaces xe-0/2/0 unit 0 family iso
set interfaces lo0 unit 0 family inet address 192.168.255.1/32
set interfaces lo0 unit 0 family iso address 49.0001.1920.1682.5501.00
set routing-options router-id 192.168.255.1
set protocols isis interface xe-0/2/0.0
set protocols isis interface lo0.0
set protocols isis level 1 disable

R2

content_copy zoom_out_map
set interfaces xe-0/2/0 description R2-to-R1
set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.2/30
set interfaces xe-0/2/0 unit 0 family iso
set interfaces xe-0/2/1 description R2-to-R3
set interfaces xe-0/2/1 unit 0 family inet address 10.1.23.1/30
set interfaces xe-0/2/1 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.1.255.2/32
set interfaces lo0 unit 0 family iso address 49.0001.0010.1255.0002.00
set policy-options policy-statement export-bgp term t1 from protocol bgp
set policy-options policy-statement export-bgp term t1 then accept
set policy-options policy-statement export-tunnel-route term t1 from route-filter 192.168.255.1/32 exact
set policy-options policy-statement export-tunnel-route term t1 then tunnel-attribute set tunnel-attr-01
set policy-options policy-statement export-tunnel-route term t1 then next-hop self
set policy-options policy-statement export-tunnel-route term t1 then accept
set policy-options tunnel-attribute tunnel-attr-01 tunnel-type ipip
set policy-options tunnel-attribute tunnel-attr-01 tunnel-color 100
set policy-options tunnel-attribute tunnel-attr-01 remote-end-point 10.1.255.4
set routing-options router-id 10.1.255.2
set routing-options autonomous-system 65000
set routing-options dynamic-tunnels Tunnel-01 source-address 10.1.255.2
set routing-options dynamic-tunnels Tunnel-01 bgp-signal
set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24 colors 100
set protocols bgp group iBGP type internal
set protocols bgp group iBGP local-address 10.1.255.2
set protocols bgp group iBGP family inet unicast extended-nexthop-tunnel
set protocols bgp group iBGP export export-tunnel-route
set protocols bgp group iBGP neighbor 10.1.255.4
set protocols isis interface xe-0/2/0.0 
set protocols isis interface lo0.0
set protocols isis level 1 disable
set protocols isis export export-bgp
set protocols ldp interface xe-0/2/1.0
set protocols mpls interface xe-0/2/1.0
set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
set protocols ospf area 0.0.0.0 interface lo0.0

R3

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R3-to-R2
set interfaces xe-0/2/0 unit 0 family inet address 10.1.23.2/30
set interfaces xe-0/2/0 unit 0 family mpls
set interfaces xe-0/2/1 unit 0 description R3-to-R4
set interfaces xe-0/2/1 unit 0 family inet address 10.1.34.1/30
set interfaces xe-0/2/1 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.1.255.3/32
set routing-options router-id 10.1.255.3
set protocols ldp interface xe-0/2/0.0
set protocols ldp interface xe-0/2/1.0
set protocols mpls interface xe-0/2/0.0
set protocols mpls interface xe-0/2/1.0
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0
set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

R4

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R4-to-R3
set interfaces xe-0/2/0 unit 0 family inet address 10.1.34.2/30
set interfaces xe-0/2/0 unit 0 family mpls
set interfaces xe-0/2/1 unit 0 description R4-to-R5
set interfaces xe-0/2/1 unit 0 family inet address 192.168.45.1/30
set interfaces xe-0/2/1 unit 0 family iso
set interfaces lo0 unit 0 family inet address 10.1.255.4/32
set interfaces lo0 unit 0 family iso address 49.0001.0010.1255.0004.00
set policy-options policy-statement export-bgp term t1 from protocol bgp
set policy-options policy-statement export-bgp term t1 then accept
set policy-options policy-statement export-tunnel-route term t1 from route-filter 192.168.255.5/32 exact
set policy-options policy-statement export-tunnel-route term t1 then tunnel-attribute set tunnel-attr-01
set policy-options policy-statement export-tunnel-route term t1 then next-hop self
set policy-options policy-statement export-tunnel-route term t1 then accept
set policy-options tunnel-attribute tunnel-attr-01 tunnel-type ipip
set policy-options tunnel-attribute tunnel-attr-01 tunnel-color 100
set policy-options tunnel-attribute tunnel-attr-01 remote-end-point 10.1.255.2
set routing-options router-id 10.1.255.4
set routing-options autonomous-system 65000
set routing-options dynamic-tunnels Tunnel-01 source-address 10.1.255.4
set routing-options dynamic-tunnels Tunnel-01 bgp-signal
set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24 colors 100
set protocols bgp group iBGP type internal
set protocols bgp group iBGP local-address 10.1.255.4
set protocols bgp group iBGP family inet unicast extended-nexthop-tunnel
set protocols bgp group iBGP export export-tunnel-route
set protocols bgp group iBGP neighbor 10.1.255.2
set protocols isis interface xe-0/2/1.0 
set protocols isis interface lo0.0
set protocols isis level 1 disable
set protocols isis export export-bgp
set protocols ldp interface xe-0/2/0.0
set protocols mpls interface xe-0/2/0.0
set protocols ospf area 0.0.0.0 interface xe-0/2/0.0
set protocols ospf area 0.0.0.0 interface lo0.0

R5

content_copy zoom_out_map
set interfaces xe-0/2/0 unit 0 description R5-to-R4
set interfaces xe-0/2/0 unit 0 family inet address 192.168.45.2/30
set interfaces xe-0/2/0 unit 0 family iso
set interfaces lo0 unit 0 family inet address 192.168.255.5/32
set interfaces lo0 unit 0 family iso address 49.0001.1920.1682.5505.00
set routing-options router-id 192.168.255.5
set protocols isis interface xe-0/2/0.0
set protocols isis interface lo0.0
set protocols isis level 1 disable

Procedure

Step-by-Step Procedure for R1

R1 and R5 have a similar configuration so we will only show the step-by-step procedure for R1.

  1. Enter configuration mode on R1.

  2. Configure the interface connected to R2 and interface lo0. Make sure to configure both family inet and iso. Family iso is needed for protocol IS-IS.

    content_copy zoom_out_map
    [edit]
    user@R1# set interfaces xe-0/2/0 unit 0 description R1-to-R2
    user@R1# set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.1/30
    user@R1# set interfaces xe-0/2/0 unit 0 family iso
    user@R1# set interfaces lo0 unit 0 family inet address 192.168.255.1/32
    user@R1# set interfaces lo0 unit 0 family iso address 49.0001.1920.1682.5501.00
    
  3. Configure the Router ID.

    content_copy zoom_out_map
    [edit]
    user@R1# set routing-options router-id 192.168.255.1
    
  4. Configure protocols IS-IS. Routes are advertised between R1 and R2 using the IS-IS protocol.

    content_copy zoom_out_map
    [edit]
    user@R1# set protocols isis interface xe-0/2/0.0
    user@R1# set protocols isis interface lo0.0
    user@R1# set protocols isis level 1 disable
    
  5. Enter commit on R1 from the configuration mode.

Step-by-Step Procedure for R2

R2 and R4 have a similar configuration so we will only show the step-by-step procedure for R2.

  1. Enter configuration mode on R2.

  2. Configure the interfaces connected to R1 and R3 and interface lo0. Ensure to configure both familyinet and iso on the interface connected to R1 and lo0, and to configure both familyinet and mpls on the interface connected to R3.

    content_copy zoom_out_map
    [edit]
    user@R2# set interfaces xe-0/2/0 description R2-to-R1
    user@R2# set interfaces xe-0/2/0 unit 0 family inet address 192.168.12.2/30
    user@R2# set interfaces xe-0/2/0 unit 0 family iso
    user@R2# set interfaces xe-0/2/1 description R2-to-R3
    user@R2# set interfaces xe-0/2/1 unit 0 family inet address 10.1.23.1/30
    user@R2# set interfaces xe-0/2/0 unit 0 family mpls
    user@R2# set interfaces lo0 unit 0 family inet address 10.1.255.2/32
    user@R2# set interfaces lo0 unit 0 family iso address 49.0001.0010.1255.0002.00
    
  3. Configure protocols IS-IS for the interface connected to R1. The export policy to advertise BGP routes into IS-IS is shown in the policy configuration step.

    content_copy zoom_out_map
    [edit]
    user@R2# set protocols isis interface xe-0/2/0.0 
    user@R2# set protocols isis interface lo0.0
    user@R2# set protocols isis level 1 disable
    user@R2# set protocols isis export export-bgp
    
  4. Configure the OSPF protocol for the interface connected to R3 for lo0 reachability.

    content_copy zoom_out_map
    [edit]
    user@R2# set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
    user@R2# set protocols ospf area 0.0.0.0 interface lo0.0
    
  5. Configure the LDP and MPLS protocols for the interface connected to R3.

    content_copy zoom_out_map
    [edit]
    user@R2# set protocols ldp interface xe-0/2/1.0
    user@R2# set protocols mpls interface xe-0/2/1.0
    
  6. Configure the router-id and autonomous-system under the routing-options hierarchy, and configure IBGP between R2 and R4. The import policy to add a community to the routes learned using BGP and the export policy to advertise IS-IS routes into BGP and set the tunnel attributes is shown in the policy configuration step. Ensure to include the extended-nexthop-tunnel option with the family inet unicast configuration to allow resolution using the inetcolor.0 table.

    content_copy zoom_out_map
    [edit]
    user@R2# set routing-options router-id 10.1.255.2
    user@R2# set routing-options autonomous-system 65000
    user@R2# set protocols bgp group iBGP type internal
    user@R2# set protocols bgp group iBGP local-address 10.1.255.2
    user@R2# set protocols bgp group iBGP family inet unicast extended-nexthop-tunnel
    user@R2# set protocols bgp group iBGP export export-tunnel-route
    user@R2# set protocols bgp group iBGP neighbor 10.1.255.4
  7. Configure routing options on R2 to create a tunnel from R2 to R4. The bgp-signal option enables the tunnel creation signaled by BGP. The colors configuration option allows the tunnel to be created in the inetcolor.0 route table.

    content_copy zoom_out_map
    [edit]
    user@R2# set routing-options dynamic-tunnels Tunnel-01 source-address 10.1.255.2
    user@R2# set routing-options dynamic-tunnels Tunnel-01 bgp-signal
    user@R2# set routing-options dynamic-tunnels Tunnel-01 destination-networks 10.1.255.0/24 colors 100
    
  8. Configure the policies that were applied during the previous configuration steps. The export-bgp policy advertises BGP routes into IS-IS. The export-tunnel-route policy advertises the IS-IS route from R1 into BGP with the tunnel-attribute and changes the next-hop to R2. The tunnel-attr-01 tunnel-attribute sets the tunnel-type, the tunnel endpoint, and the color matched on in the colors configuration for the dynamic tunnel.

    content_copy zoom_out_map
    [edit]
    user@R2# set policy-options policy-statement export-bgp term t1 from protocol bgp
    user@R2# set policy-options policy-statement export-bgp term t1 then accept
    user@R2# set policy-options policy-statement export-tunnel-route term t1 from route-filter 192.168.255.1/32 exact
    user@R2# set policy-options policy-statement export-tunnel-route term t1 then tunnel-attribute set tunnel-attr-01
    user@R2# set policy-options policy-statement export-tunnel-route term t1 then next-hop self
    user@R2# set policy-options policy-statement export-tunnel-route term t1 then accept
    user@R2# set policy-options tunnel-attribute tunnel-attr-01 tunnel-type ipip
    user@R2# set policy-options tunnel-attribute tunnel-attr-01 tunnel-color 100
    user@R2# set policy-options tunnel-attribute tunnel-attr-01 remote-end-point 10.1.255.4
    
  9. Enter commit from the configuration mode.

Step-by-Step Procedure for R3
  1. Enter configuration mode on R3.

  2. Configure the interfaces connected to R2 and R4 and interface lo0. Ensure to configure both family inet and mpls on the interfaces connected to R2 and R4.

    content_copy zoom_out_map
    [edit]
    user@R3# set interfaces xe-0/2/0 unit 0 description R3-to-R2
    user@R3# set interfaces xe-0/2/0 unit 0 family inet address 10.1.23.2/30
    user@R3# set interfaces xe-0/2/0 unit 0 family mpls
    user@R3# set interfaces xe-0/2/1 unit 0 description R3-to-R4
    user@R3# set interfaces xe-0/2/1 unit 0 family inet address 10.1.34.1/30
    user@R3# set interfaces xe-0/2/1 unit 0 family mpls
    user@R3# set interfaces lo0 unit 0 family inet address 10.1.255.3/32
    
  3. Configure the Router ID.

    content_copy zoom_out_map
    [edit]
    user@R3# set routing-options router-id 10.1.255.3
    
  4. Configure the OSPF protocol for the interfaces connected to R2 and R4 for lo0 reachability.

    content_copy zoom_out_map
    [edit]
    user@R3# set protocols ospf area 0.0.0.0 interface xe-0/2/0.0
    user@R3# set protocols ospf area 0.0.0.0 interface xe-0/2/1.0
    user@R3# set protocols ospf area 0.0.0.0 interface lo0.0 passive
    
  5. Configure the LDP and MPLS protocols for the interfaces connected to R2 and R4.

    content_copy zoom_out_map
    [edit]
    user@R2# set protocols ldp interface xe-0/2/0.0
    user@R2# set protocols ldp interface xe-0/2/1.0
    user@R2# set protocols mpls interface xe-0/2/0.0
    user@R2# set protocols mpls interface xe-0/2/1.0
    
  6. Enter commit from configuration mode on R3 device.

Results

You can check your configurations by using the following show commands from configuration mode.

Here's how you can check the configurations on R2 device:

user@R2# show interfaces

content_copy zoom_out_map
xe-0/2/0 {
    description R2-to-R1;
    unit 0 {
        family inet {
            address 192.168.12.2/30;
        }
        family iso;
    }
}
xe-0/2/1 {
    description R2-to-R3;
    unit 0 {
        family inet {
            address 10.1.23.1/30;
        }
        family mpls;
    }
}
lo0 {
    apply-groups-except global;
    unit 0 {
        family inet {
            address 10.1.255.2/32;
        }
        family iso {
            address 49.0001.0010.1255.0002.00;
        }
    }
}

user@R2# show protocols

content_copy zoom_out_map
bgp {
    group iBGP {
        type internal;
        local-address 10.1.255.2;
        family inet {
            unicast {
                extended-nexthop-tunnel;
            }
        }
        export export-tunnel-route;
        neighbor 10.1.255.4;
    }
}
isis {
    interface xe-0/2/0.0;
    interface lo0.0;
    level 1 disable;
    export export-bgp;
}
ldp {
    interface xe-0/2/1.0;
}
mpls {
    interface xe-0/2/1.0;
}
ospf {
    area 0.0.0.0 {
        interface xe-0/2/1.0;
        interface lo0.0;
    }
}

user@R2# show routing-options

content_copy zoom_out_map
router-id 10.1.255.2;
autonomous-system 65000;
dynamic-tunnels {
    Tunnel-01 {
        source-address 10.1.255.2;
        bgp-signal;
        destination-networks {
            10.1.255.0/24 colors 100;
        }
    }
}

user@R2# show policy-options

content_copy zoom_out_map
policy-statement export-bgp {
    term t1 {
        from protocol bgp;
        then accept;
    }
}
policy-statement export-tunnel-route {
    term t1 {
        from {
            route-filter 192.168.255.1/32 exact;
        }
        then {
            tunnel-attribute set tunnel-attr-01;
            next-hop self;
            accept;
        }
    }
}
tunnel-attribute tunnel-attr-01 {
    tunnel-type ipip;
    tunnel-color 100;
    remote-end-point 10.1.255.4;
}

Verification

Verify BGP Routes

Purpose

Verify routes sent by using BGP protocol.

Action

R2

content_copy zoom_out_map
user@R2> show route protocol bgp

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.255.5/32   *[BGP/170] 01:21:51, MED 10, localpref 100, from 10.1.255.4
                      AS path: I, validation-state: unverified
                    >  via Tunnel Composite, IPoIP (src 10.1.255.2 dest 10.1.255.4-100<c> tunnel-endpoint 10.1.255.2)

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

inetcolor.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
Meaning

The output shows the routes from BGP.

Verify Received Routes

Purpose

Verify the routes received through BGP by using the following operational mode commands.

Action

R2

content_copy zoom_out_map
user@R2> show route receive-protocol bgp 10.1.255.4 192.168.255.5 extensive

inet.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
* 192.168.255.5/32 (1 entry, 1 announced)
     Accepted
     Nexthop: 10.1.255.4
     MED: 10
     Localpref: 100
     AS path: I 
     Tunnel type: ipip, Tunnel color: 100, Remote end point: 10.1.255.2
Meaning

The R2 output indicates the routes received on the devices.

Verify the Dynamic Tunnel

Purpose

Verify the dynamic tunnel is up and BGP signaled.

Action

R2

content_copy zoom_out_map
user@R2> show dynamic-tunnels database
*- Signal Tunnels #- PFE-down
Table: inet.3       

Destination-network: 10.1.255.0/24

*- Signal Tunnels #- PFE-down
Table: inetcolor.0  

Destination-network: 10.1.255.0-0<c>/24

Tunnel to: 10.1.255.4-100<c>/64
  Reference count: 3
  Next-hop type: IPoIP (bgp-signalled forwarding-nexthop)     Tunnel-endpoint: 10.1.255.2
    Source address: 10.1.255.2
    Next hop: tunnel-composite, 0x76b7238, nhid 592
      Reference count: 2
      Ingress Route: [OSPF] 10.1.255.4/32, via metric 2
      Tunnel Endpoint Ingress Route: [Direct] 10.1.255.2/32
      Traffic Statistics: Packets 0, Bytes 0 
      State: Up
  Aggregate Traffic Statistics:
    Tunnel Encapsulation: Dest 10.1.255.2, Src 10.1.255.2, IPoIP, Tunnel-Id 1
    Traffic Statistics: Packets 0, Bytes 0 
Meaning

The R2 output indicates the tunnel is up and BGP signaled.

Verify Route Resolution

Purpose

To verify the route resolution of the route in the inetcolor.0 table, use the show route table inetcolor.0 operational mode commands.

Action
content_copy zoom_out_map
user@R2> show route table inetcolor.0

inetcolor.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.255.0-0<c>/24                
                   *[Tunnel/305] 01:33:33
                       Tunnel
10.1.255.4-100<c>/64                
                   *[Tunnel/305] 01:28:44, metric 2
                       Tunnel Composite, BGP-Signal (src 10.1.255.2 dest 10.1.255.4-100<c>)
Meaning

The R2 output indicates the tunnel to 10.1.255.4 is BGP signaled.

Verify End-to-End Reachability

Purpose

Verify R1 can ping R5 by using the ping 192.168.255.5 source 192.168.255.1 count 2 operational mode command.

Action
content_copy zoom_out_map
user@R1>ping 192.168.255.5 source 192.168.255.1 count 2
PING 192.168.255.5 (192.168.255.5): 56 data bytes
64 bytes from 192.168.255.5: icmp_seq=0 ttl=63 time=2.784 ms
64 bytes from 192.168.255.5: icmp_seq=1 ttl=63 time=1.904 ms

--- 192.168.255.5 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.904/2.344/2.784/0.440 ms
Meaning

The output from R1 shows that R1 can ping R5.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
19.2R1
Starting in Junos Release 19.2R1, on MX Series routers with MPCs and MICs, carrier supporting carrier (CSC) architecture can be deployed with MPLS-over-UDP tunnels carrying MPLS traffic over dynamic IPv4 UDP tunnels that are established between supporting carrier's PE devices.
18.3R1
Starting in Junos OS Release 18.3R1, MPLS-over-UDP tunnels are supported on PTX Series routers and QFX Series switches.
18.2R1
Starting in Junos OS Release 18.2R1, on PTX series routers and QFX10000 with unidirectional MPLS-over-UDP tunnels, you must configure the remote PE device with an input filter for MPLS-over-UDP packets, and an action for decapsulating the IP and UDP headers for forwarding the packets in the reverse tunnel direction.
17.4R1
Starting in Junos OS Release 17.4R1, on MX Series routers, the next-hop-based dynamic MPLS-over-UDP tunnels are signaled using BGP encapsulation extended community.
17.1R1
Starting in Junos OS Release 17.1, on MX Series routers with MPCs and MICs, the scaling limit of MPLS-over-UDP tunnels is increased.
footer-navigation