Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Multiprotocol BGP

 

Understanding Multiprotocol BGP

Multiprotocol BGP (MP-BGP) is an extension to BGP that enables BGP to carry routing information for multiple network layers and address families. MP-BGP can carry the unicast routes used for multicast routing separately from the routes used for unicast IP forwarding.

To enable MP-BGP, you configure BGP to carry network layer reachability information (NLRI) for address families other than unicast IPv4 by including the family inet statement:

To enable MP-BGP to carry NLRI for the IPv6 address family, include the family inet6 statement:

On routers only, to enable MP-BGP to carry Layer 3 virtual private network (VPN) NLRI for the IPv4 address family, include the family inet-vpn statement:

On routers only, to enable MP-BGP to carry Layer 3 VPN NLRI for the IPv6 address family, include the family inet6-vpn statement:

On routers only, to enable MP-BGP to carry multicast VPN NLRI for the IPv4 address family and to enable VPN signaling, include the family inet-mvpn statement:

To enable MP-BGP to carry multicast VPN NLRI for the IPv6 address family and to enable VPN signaling, include the family inet6-mvpn statement:

For more information about multiprotocol BGP-based multicast VPNs, see the Multicast Protocols Feature Guide .

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

Note

If you change the address family specified in the [edit protocols bgp family] hierarchy level, all current BGP sessions on the routing device are dropped and then reestablished.

In Junos OS Release 9.6 and later, you can specify a loops value for a specific BGP address family.

By default, BGP peers carry only unicast routes used for unicast forwarding purposes. To configure BGP peers to carry only multicast routes, specify the multicast option. To configure BGP peers to carry both unicast and multicast routes, specify the any option.

When MP-BGP is configured, BGP installs the MP-BGP routes into different routing tables. Each routing table is identified by the protocol family or address family indicator (AFI) and a subsequent address family identifier (SAFI).

The following list shows all possible AFI and SAFI combinations:

  • AFI=1, SAFI=1, IPv4 unicast

  • AFI=1, SAFI=2, IPv4 multicast

  • AFI=1, SAFI=128, L3VPN IPv4 unicast

  • AFI=1, SAFI=129, L3VPN IPv4 multicast

  • AFI=2, SAFI=1, IPv6 unicast

  • AFI=2, SAFI=2, IPv6 multicast

  • AFI=25, SAFI=65, BGP-VPLS/BGP-L2VPN

  • AFI=2, SAFI=128, L3VPN IPv6 unicast

  • AFI=2, SAFI=129, L3VPN IPv6 multicast

  • AFI=1, SAFI=132, RT-Constrain

  • AFI=1, SAFI=133, Flow-spec

  • AFI=1, SAFI=134, Flow-spec

  • AFI=3, SAFI=128, CLNS VPN

  • AFI=1, SAFI=5, NG-MVPN IPv4

  • AFI=2, SAFI=5, NG-MVPN IPv6

  • AFI=1, SAFI=66, MDT-SAFI

  • AFI=1, SAFI=4, labeled IPv4

  • AFI=2, SAFI=4, labeled IPv6 (6PE)

Routes installed in the inet.2 routing table can only be exported to MP-BGP peers because they use the SAFI, identifying them as routes to multicast sources. Routes installed in the inet.0 routing table can only be exported to standard BGP peers.

The inet.2 routing table should be a subset of the routes that you have in inet.0, since it is unlikely that you would have a route to a multicast source to which you could not send unicast traffic. The inet.2 routing table stores the unicast routes that are used for multicast reverse-path-forwarding checks and the additional reachability information learned by MP-BGP from the NLRI multicast updates. An inet.2 routing table is automatically created when you configure MP-BGP (by setting NLRI to any).

When you enable MP-BGP, you can do the following:

Limiting the Number of Prefixes Received on a BGP Peer Session

You can limit the number of prefixes received on a BGP peer session, and log rate-limited messages when the number of injected prefixes exceeds a set limit. You can also tear down the peering when the number of prefixes exceeds the limit.

To configure a limit to the number of prefixes that can be received on a BGP session, include the prefix-limit statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

For maximum number, specify a value in the range from 1 through 4,294,967,295. When the specified maximum number of prefixes is exceeded, a system log message is sent.

If you include the teardown statement, the session is torn down when the maximum number of prefixes is exceeded. If you specify a percentage, messages are logged when the number of prefixes exceeds that percentage of the specified maximum limit. After the session is torn down, it is reestablished in a short time (unless you include the idle-timeout statement). If you include the idle-timeout statement, the session can be kept down for a specified amount of time, or forever. If you specify forever, the session is reestablished only after the you issue a clear bgp neighbor command.

Note

In Junos OS Release 9.2 and later, you can alternatively configure a limit to the number of prefixes that can be accepted on a BGP peer session. For more information, see Limiting the Number of Prefixes Accepted on a BGP Peer Session.

Limiting the Number of Prefixes Accepted on a BGP Peer Session

In Junos OS Release 9.2 and later, you can limit the number of prefixes that can be accepted on a BGP peer session. When that specified limit is exceeded, a system log message is sent. You can also specify to reset the BGP session if the limit to the number of specified prefixes is exceeded.

To configure a limit to the number of prefixes that can be accepted on a BGP peer session, include the accepted-prefix-limit statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

For maximum number, specify a value in the range from 1 through 4,294,967,295.

Include the teardown statement to reset the BGP peer session when the number of accepted prefixes exceeds the configured limit. You can also include a percentage value from 1 through 100 to have a system log message sent when the number of accepted prefixes exceeds that percentage of the maximum limit. By default, a BGP session that is reset is reestablished within a short time. Include the idle-timeout statement to prevent the BGP session from being reestablished for a specified period of time. You can configure a timeout value from 1 through 2400 minutes. Include the forever option to prevent the BGP session from being reestablished until you issue the clear bgp neighbor command.

Note

When nonstop active routing (NSR) is enabled and a switchover to a backup Routing Engine occurs, BGP peers that are down are automatically restarted. The peers are restarted even if the idle-timeout forever statement is configured.

Note

Alternatively, you can configure a limit to the number of prefixes that can be received (as opposed to accepted) on a BGP peer session. For more information, see Limiting the Number of Prefixes Received on a BGP Peer Session.

Configuring BGP Routing Table Groups

When a BGP session receives a unicast or multicast NLRI, it installs the route in the appropriate table (inet.0 or inet6.0 for unicast, and inet.2 or inet6.2 for multicast). To add unicast prefixes to both the unicast and multicast tables, you can configure BGP routing table groups. This is useful if you cannot perform multicast NLRI negotiation.

To configure BGP routing table groups, include the rib-group statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Resolving Routes to PE Routing Devices Located in Other ASs

You can allow labeled routes to be placed in the inet.3 routing table for route resolution. These routes are then resolved for provider edge (PE) routing device connections where the remote PE is located across another autonomous system (AS). For a PE routing device to install a route in the VPN routing and forwarding (VRF) routing instance, the next hop must resolve to a route stored within the inet.3 table.

To resolve routes into the inet.3 routing table, include the resolve-vpn statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Allowing Labeled and Unlabeled Routes

You can allow both labeled and unlabeled routes to be exchanged in a single session. The labeled routes are placed in the inet.3 or inet6.3 routing table, and both labeled and unlabeled unicast routes can be sent to or received by the routing device.

To allow both labeled and unlabeled routes to be exchanged, include the rib statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Example: Configuring IPv6 BGP Routes over IPv4 Transport

This example demonstrates how to export both IPv6 and IPv4 prefixes over an IPv4 connection where both sides are configured with an IPv4 interface.

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

Keep the following in mind when exporting IPv6 BGP prefixes:

  • BGP derives next-hop prefixes using the IPv4-mapped IPv6 prefix. For example, the IPv4 next-hop prefix 10.19.1.1 translates to the IPv6 next-hop prefix ::ffff:10.19.1.1.

    Note

    There must be an active route to the IPv4-mapped IPv6 next hop to export IPv6 BGP prefixes.

  • An IPv6 connection must be configured over the link. The connection must be either an IPv6 tunnel or a dual-stack configuration. Dual stacking is used in this example.

  • When configuring IPv4-mapped IPv6 prefixes, use a mask that is longer than 96 bits.

  • Configure a static route if you want to use normal IPv6 prefixes. This example uses static routes.

Figure 1 shows the sample topology.

Figure 1: Topology for Configuring IPv6 BGP Routes over IPv4 Transport
Topology for Configuring IPv6
BGP Routes over IPv4 Transport

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device R1

Device R2

Device R3

Configuring Device R1

Step-by-Step Procedure

The following example requires you to 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 R1:

  1. Configure the interfaces, including both an IPv4 address and an IPv6 address.
  2. Configure EBGP.
  3. Enable BGP to carry IPv4 unicast and IPv6 unicast routes. .

    IPv4 unicast routes are enabled by default. The configuration is shown here for completeness.

  4. Configure the routing policy.
  5. Configure some static routes.
  6. Configure the autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-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.

If you are done configuring the device, enter commit from configuration mode. Repeat the configuration on Device R2 and Device R3, changing the interface names and IP addresses, as needed.

Verification

Confirm that the configuration is working properly.

Checking the Neighbor Status

Purpose

Make sure that BGP is enabled to carry IPv6 unicast routes.

Action

From operational mode, enter the show bgp neighbor command.

user@R2> show bgp neighbor

Meaning

The various occurrences of inet6-unicast in the output shows that BGP is enabled to carry IPv6 unicast routes.

Checking the Routing Table

Purpose

Make sure that Device R2 has BGP routes in its inet6.0 routing table.

Action

From operational mode, enter the show route protocol bgp inet6.0 command.

user@R2> show route protocol bgp table inet6.0

Advertising IPv4 Routes over BGP IPv6 Sessions Overview

In an IPv6 network, BGP typically advertises IPv6 network layer reachability information over an IPv6 session between BGP peers. In earlier releases, Junos OS supported the exchange of inet6 unicast, inet6 multicast, or inet6 labeled-unicast address families only. This feature allows the exchange of all BGP address families. In a dual-stack environment that has IPv6 in its core. this feature enables BGP to advertise IPv4 unicast reachability with IPv4 next hop over an IPv6 BGP session.

This feature is for BGP IPv6 sessions only, where IPv4 is configured at both endpoints. The local-ipv4-address can be a loopback address or any ipv4 address for an IBGP or multiple-hop EBGP session. For single-hop external BGP speakers that are not part of BGP confederations, if the configured local IPv4 address is not directly connected, the BGP session is closed and remains idle and an error is generated, which is displayed in the output of the show bgp neighbor command.

To enable IPv4 route advertising over IPv6 session, configure local-ipv4-address as follows:

Note

You cannot configure this feature for the inet6 unicast, inet6 multicast, or inet6 labeled-unicast address families because BGP already has the capability to advertise these address families over an IPv6 BGP session.

The configured local-ipv4-address is used only when BGP advertises routes with self-next hop. When IBGP advertises routes learned from EBGP peers or the route reflector advertises BGP routes to its clients, BGP does not change the route next hop, ignores the configured local-ipv4-address, and uses the original IPv4 next hop.

Example: Advertising IPv4 Routes over IPv6 BGP Sessions

This example shows how to advertise IPv4 routes over IPv6 BGP session.In a dual-stack environment that has IPv6 in its core, there is a need to reach remote IPv4 hosts. Therefore, BGP advertises IPv4 routes with IPv4 next hops to BGP peers over BGP sessions using IPv6 source and destination addresses. This feature enables BGP to advertise IPv4 unicast reachability with IPv4 next hop over IPv6 BGP sessions.

Requirements

This example uses the following hardware and software components:

  • Three routers with dual stacking capability

  • Junos OS Release 16.1 or later running on all the devices

Before you enable IPv4 advertisements over IPv6 BGP sessions, be sure to:

  1. Configure the device interfaces.
  2. Configure dual stacking on all devices.

Overview

Beginning with Release 16.1, Junos OS allows BGP to advertise IPv4 unicast reachability with IPv4 next hop over an IPv6 BGP session. In earlier Junos OS releases, BGP could advertise only inet6 unicast, inet6 multicast and inet6 labeled unicast address families over IPv6 BGP sessions. This feature allows BGP to exchange all BGP address families over an IPv6 session. You can enable BGP to advertise IPv4 routes with IPv4 next hops to BGP peers over IPv6 session. The configured local-ipv4-address is used only when BGP advertises routes with self-next hop.

Note

You cannot configure this feature for the inet6 unicast, inet6 multicast, or inet6 labeled-unicast address families because BGP already has the capability to advertise these address families over an IPv6 BGP session.

Topology

In Figure 2, an IPv6 external BGP session is running between Routers R1 and R2. An IPv6 IBGP session is established between Router R2 and Router R3. IPv4 static routes are redistributed to the BGP on R1. To redistribute the IPv4 routes over the IPv6 BGP session, the new feature must be enabled on all routers at the [edit protocols bgp address family] hierarchy level.

Figure 2: Advertising IPv4 Routes over IPv6 BGP Sessions
Advertising IPv4 Routes over IPv6
BGP Sessions

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 R1

Router R2

Router R3

Configuring Router R1

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 R1:

Note

Repeat this procedure for other routers after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the interfaces with IPv4 and IPv6 addresses.
  2. Configure the loopback address.
  3. Configure an IPv4 static route that needs to be advertised.
  4. Configure the autonomous system for BGP hosts.
  5. Configure EBGP on the external edge routers.
  6. Enable the feature to advertise IPv4 adddress 140.1.1.1 over BGP IPv6 sessions.
  7. Define a policy p1 to accept all static routes.
  8. Apply the policy p1 on EBGP group ebgp-v6.

Results

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

If you are done configuring the device, commit the configuration.

Verification

Confirm that the configuration is working properly.

Verifying That the BGP Session Is Up

Purpose

Verify that BGP is running on the configured interfaces and that the BGP session is active for each neighbor address.

Action

From operational mode, run the show bgp summary command on Router R1.

user@R1> show bgp summary

Meaning

The BGP session is up and running, and BGP peering is established.

Verifying That the IPv4 address Is Being Advertised

Purpose

Verify that the configured IPv4 address is being advertised by Router R1 to the configured BGP neighbors.

Action

From operational mode, run the show route advertising-protocol bgp ::150.1.1.2 command on Router R1.

user@R1> show route advertising-protocol bgp ::150.1.1.2

Meaning

The IPv4 static route is being advertised to the BGP neighbor Router R2.

Verifying That the BGP Neighbor Router R2 Receives the Advertised IPv4 Address

Purpose

Verify that Router R2 receives the IPv4 address that Router R1 is advertising to the BGP neighbor over IPv6.

Action

user@R2> show route receive-protocol bgp ::140.1.1.1

Meaning

The presence of the static IPv4 route in Router R2’s routing table indicates that it is receiving the advertised IPv4 routes from Router R1.

Understanding Redistribution of IPv4 Routes with IPv6 Next Hop into BGP

In a network that predominantly transports IPv6 traffic there is a need to route IPv4 routes when required. For example, an Internet Service Provider that has an IPv6-only network, but has customers who still route IPv4 traffic. In this case, it is necessary to cater to such customers and forward IPv4 traffic over an IPv6 network. As described in RFC 5549, Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop IPv4 traffic is tunneled from customer premises equipment (CPE) devices to IPv4-over-IPv6 gateways. These gateways are announced to CPE devices through anycast addresses. The gateway devices then create dynamic IPv4-over-IPv6 tunnels to remote CPE devices and advertise IPv4 aggregate routes to steer traffic.

Note

Dynamic IPv4-over-IPv6 tunnel feature does not support unified ISSU in Junos OS Release 17.3R1.

Route reflectors (RRs) with a programmable interface are connected through IBGP to the gateway routers and host routes with IPv6 address as the next hop. These RRs advertise the IPv4 /32 addresses to inject the tunnel information into the network. The gateway routers create dynamic IPv4-over-IPv6 tunnels to the remote customer provider edge. The gateway router also advertises the IPv4 aggregate routes to steer traffic. The RR then advertises the tunnel source routes to the ISP. When the RR removes the tunnel route, BGP also withdraws the route causing the tunnel to be torn down and the CPE to be unreachable. The gateway router also withdraws the IPv4 aggregate routes and IPv6 tunnel source routes when all the aggregate routes contributor routes are removed. The gateway router sends route withdraw when the anchor Packet Forwarding Engine line card goes down, so that it will redirect traffic to other gateway routers.

The following extensions are introduced to support IPv4 routes with an IPv6 next hop:

BGP Next Hop Encoding

BGP is extended with next hop encoding capability that is used to send IPv4 routes with IPv6 next hops. If this capability is not available on the remote peer, BGP groups the peers based on this encoding capability and removes BGP family without encoding capability from the negotiated network layer reachability information (NLRI) list. Junos OS allows only one resolution table such as inet.0. To permit IPv4 BGP routes with IPv6 next hops BGP creates a new resolution tree. This feature allows a Junos OS routing table to have multiple resolution trees.

Besides RFC 5549, Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop a new encapsulation community specified in RFC 5512, The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute is introduced to determine the address family of the next-hop address. The encapsulation community indicates the type of tunnels that the ingress node needs to create. When BGP receives IPv4 routes with IPv6 next hop address and the V4oV6 encapsulation community, then BGP creates IPv4-over-IPv6 dynamic tunnels. When BGP receives routes without the encapsulation community, BGP routes are resolved without creating the V4oV6 tunnel.

A new policy action dynamic-tunnel-attributes dyan-attribute is available at the [edit policy-statement policy name term then] hierarchy level to support the new extended encapsulation.

Tunnel Localization

The dynamic tunnel infrastructure is enhanced with tunnel localization to support a larger number of tunnels. There is a need for tunnel localization to provide resiliency to handle traffic when the anchor fails. One or more chassis back up one another and let the routing protocol process (rpd) steer traffic away from the failure point to the backup chassis. The chassis advertises only these aggregate prefixes instead of the individual loopback addresses into the network.

Tunnel Handling

IPv4 over IPv6 tunnels use the dynamic tunnel infrastructure along with tunnel anchoring to support the required chassis wide scale. The tunnel state is localized to a Packet Forwarding Engine and the other Packet Forwarding Engines steer the traffic to the tunnel anchor.

Tunnel Ingress

Tunnel ingress or tunnel encapsulation forwards the network traffic towards the customer site. When the tunnel state is present on the Packet Forwarding Engine on which traffic entered the chassis, the routing protocol process (rpd) uses the following procedure to redistribute IPv4 routes over IPv6 tunnels:

Figure 3: Tunnel Ingress Handling when the Tunnel State is Available on the same PFETunnel Ingress Handling when the Tunnel State is Available
on the same PFE
Figure 4: Tunnel Ingress Handling when the Tunnel State is on a Different PFETunnel Ingress Handling when the Tunnel State is on a Different
PFE
  1. Encapsulates IPv4 traffic inside the IPv6 header.

    Maximum transmission unit (MTU) enforcement is performed before encapsulation. If the encapsulated packet size exceeds the tunnel MTU and the IPv4 packet’s DF-bit is not set then the packet is fragmented and these fragments are encapsulated.

  2. Uses hash-based traffic load balancing on inner packet headers.
  3. Forwards traffic to the destination IPv6 address. The IPv6 address is taken from the IPv6 header.

Tunnel Egress

Tunnel egress forwards traffic from the customer premises equipment to the network side.

Figure 5: Tunnel Egress Handling when the Tunnel State is Available on the same PFETunnel Egress
Handling when the Tunnel State is Available on the same PFE
Figure 6: Tunnel Egress Handling when the Tunnel State is Available on a Remote PFETunnel Egress Handling when the Tunnel State is Available on
a Remote PFE
  1. Decapsulates the IPv4 packet present inside the IPv6 packet.
  2. Performs anti-spoof checking to ensure that the IPv6, IPv4 pair matches with the information that was used for setting up the tunnel.
  3. Looks up the IPv4 destination address from the decapsulated packet’s IPv4 header and forwards the packet to the specified IPv4 address.

Tunnel Load Balancing and Anchor Packet Forwarding Engine Failure Handling

The Packet Forwarding Engine failure needs to be handled promptly to avoid black holing of tunnel traffic anchored on the Packet Forwarding Engine. Tunnel localization involves the use of BGP advertisements to repair the failure globally. The tunnel traffic is diverted away from the failure point to other backup chassis that contains the identical tunnel state. For traffic load balancing, the chassis is configured to advertise different multiple exit discriminator (MED) values for each of the prefix sets so that only the traffic for one fourth of the tunnels goes through each chassis. CPE traffic is also handled in a similar manner by configuring the same set of anycast addresses on each chassis and steering only one fourth of traffic towards each chassis.

Anchor Packet Forwarding Engine is the single entity that does all processing for a tunnel. The anchor Packet Forwarding Engine selection is through static provisioning and tied to the Packet Forwarding Engine physical interfaces. When one of the Packet Forwarding Engines goes down, the daemon marks all the Packet Forwarding Engines down on the line card and communicates this information to routing protocol process routing protocol process and other daemons. The routing protocol process sends out BGP withdrawals for the prefixes that are anchored on the failed Packet Forwarding Engine and the IPv6 addresses assigned to the Packet Forwarding Engine that is down. These advertisements reroute traffic to other backup chassis. When the failed Packet Forwarding Engine is up again, the chassis marks the Packet Forwarding Engine as up and updates routing protocol process. The routing protocol process triggers BGP updates to its peers that tunnels anchored to the specific Packet Forwarding Engine are now available for routing traffic. This process might take minutes for large scale tunnel configuration. Therefore, the Ack mechanism is built into the system to ensure minimal traffic loss while switching traffic back to the original chassis.

Tunnel Loopback Stream Statistics

Dynamic tunnel infrastructure uses loopback streams in Packet Forwarding Engine for looping the packet after encapsulation. Since the bandwidth of this loopback stream is limited there is a need to monitor the performance of tunnel loopback streams.

To monitor the statistics of the loopback stream, use the operational command show pfe statistics traffic detail that displays the aggregated loopback stream statistics including forwarding rate, drop packet rate and the byte rate.

Configuring BGP to Redistribute IPv4 Routes with IPv6 Next-Hop Addresses

Starting in Release 17.3R1, Junos OS devices can forward IPv4 traffic over an IPv6-only network, which generally cannot forward IPv4 traffic. As described in RFC 5549, IPv4 traffic is tunneled from CPE devices to IPv4-over-IPv6 gateways. These gateways are announced to CPE devices through anycast addresses. The gateway devices then create dynamic IPv4-over-IPv6 tunnels to remote customer premises equipment and advertise IPv4 aggregate routes to steer traffic. Route reflectors with programmable interfaces inject the tunnel information into the network. The route reflectors are connected through IBGP to gateway routers, which advertise the IPv4 addresses of host routes with IPv6 addresses as the next hop.

Note

Dynamic IPv4-over-IPv6 tunnel feature does not support unified ISSU in Junos OS Release 17.3R1.

Before you begin configuring BGP to distribute IPv4 routes with IPv6 next-hop addresses, do the following:

  1. Configure the device interfaces.
  2. Configure OSPF or any other IGP protocol.
  3. Configure MPLS and LDP.
  4. Configure BGP.

To configure BGP to distribute IPv4 routes with IPv6 next-hop addresses:

  1. Configure the extended next-hop encoding option for BGP groups with IPv6 peers to route IPv4 address families over an IPv6 session.
  2. Configure dynamic IPv4-over-IPv6 tunnels and define their attributes to forward IPv4 traffic over an IPv6-only network. IPv4 traffic is tunneled from CPE devices to IPv4-over-IPv6 gateways.
  3. Configure the tunnel attributes.

    For example, configure a dynamic tunnel, first_tunnel with the following attributes:

  4. Define a policy to associate the configured dynamic tunnel attribute profile to a prefix list or a route filter.

    For example, define dynamic_tunnel_policy policy to associate the dynamic tunnel first_tunnel attributes only to traffic heading to a specific route 2.2.2.2/32.

  5. Export the defined policy.

    For example, export the configured dynamic_tunnel_policy policy.

Enabling Layer 2 VPN and VPLS Signaling

You can enable BGP to carry Layer 2 VPN and VPLS NLRI messages.

To enable VPN and VPLS signaling, include the family statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

To configure a maximum number of prefixes, include the prefix-limit statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

When you set the maximum number of prefixes, a message is logged when that number is reached. If you include the teardown statement, the session is torn down when the maximum number of prefixes is reached. If you specify a percentage, messages are logged when the number of prefixes reaches that percentage. Once the session is torn down, it is reestablished in a short time. Include the idle-timeout statement to keep the session down for a specified amount of time, or forever. If you specify forever, the session is reestablished only after you use the clear bgp neighbor command.

Understanding BGP Flow Routes for Traffic Filtering

A flow route is an aggregation of match conditions for IP packets. Flow routes are propagated through the network using flow-specification network-layer reachability information (NLRI) messages and installed into the flow routing table instance-name.inetflow.0. Packets can travel through flow routes only if specific match conditions are met.

Flow routes and firewall filters are similar in that they filter packets based on their components and perform an action on the packets that match. Flow routes provide traffic filtering and rate-limiting capabilities much like firewall filters. In addition, you can propagate flow routes across different autonomous systems.

Flow routes are propagated by BGP through flow-specification NLRI messages. You must enable BGP to propagate these NLRIs.

Beginning with Junos OS Release 15.1, changes are implemented to extend nonstop active routing (NSR) support for existing inet-flow and inetvpn-flow families and extend route validation for BGP flowspec per draft-ietf-idr-bgp-flowspec-oid-01. Two new statements are introduced as part of this enhancement. See enforce-first-as and no-install.

Note

Beginning with Junos OS Release 16.1, IPv6 support is extended to BGP flow specification that allows propagation of traffic flow specification rules for IPv6 and VPN-IPv6 packets. BGP flow specification automates coordination of traffic filtering rules in order to mitigate distributed denial-of-service attack during nonstop active routing (NSR).

Starting with Junos OS Release 16.1R1, BGP flow specification supports traffic-marking extended-community filtering action. For IPv4 traffic, Junos OS modifies the DiffServ code point (DSCP) bits of a transiting IPv4 packet to the corresponding value of the extended community. For IPv6 packets, Junos OS modifies the first six bits of the traffic class field of the transmitting IPv6 packet to the corresponding value of the extended community.

Match Conditions for Flow Routes

You specify conditions that the packet must match before the action in the then statement is taken for a flow route. All conditions in the from statement must match for the action to be taken. The order in which you specify match conditions is not important, because a packet must match all the conditions in a term for a match to occur.

To configure a match condition, include the match statement at the [edit routing-options flow] hierarchy level.

Table 1 describes the flow route match conditions.

Table 1: Flow Route Match Conditions

Match Condition

Description

destination prefix prefix-offset number

IP destination address field.

You can use the prefix-offset optional field, which is available only on Junos Trio chipset-based devices that are configured for enhanced-ip mode, to specify the number of bits that must be skipped before Junos OS starts matching an IPv6 prefix.

destination-port number

TCP or User Datagram Protocol (UDP) destination port field. You cannot specify both the port and destination-port match conditions in the same term.

In place of the numeric value, you can specify one of the following text synonyms (the port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68), bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443), ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513), mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139), nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), xdmcp (177), zephyr-clt (2103), or zephyr-hm (2104).

dscp number

Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most significant six bits of this byte form the DSCP.

You can specify DSCP in hexadecimal or decimal form.

flow-label numeric-expression

Match the flow label value. The value of this field ranges from 0 through 1048575.

This match condition is supported only on Junos Trio chipset-based devices that are configured for enhanced-ip mode. This match condition is not supported for IPv4.

fragment type

Fragment type field. The keywords are grouped by the fragment type with which they are associated:

  • dont-fragment

    Note: This option is not supported for IPv6.

  • first-fragment

  • is-fragment

  • last-fragment

  • not-a-fragment

This match condition is supported only on Junos Trio chipset-based devices that are configured for enhanced-ip mode. .

icmp-code numbericmp6-code icmp6-code-value;

ICMP code field. This value or keyword provides more specific information than icmp-type. Because the value’s meaning depends upon the associated icmp-type value, you must specify icmp-type along with icmp-code.

In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed). The keywords are grouped by the ICMP type with which they are associated:

  • parameter-problem: ip-header-bad (0), required-option-missing (1)

  • redirect: redirect-for-host (1), redirect-for-network (0), redirect-for-tos-and-host (3), redirect-for-tos-and-net (2)

  • time-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0)

  • unreachable: communication-prohibited-by-filtering (13), destination-host-prohibited (10), destination-host-unknown (7), destination-network-prohibited (9), destination-network-unknown (6), fragmentation-needed (4), host-precedence-violation (14), host-unreachable (1), host-unreachable-for-TOS (12), network-unreachable (0), network-unreachable-for-TOS (11), port-unreachable (3), precedence-cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8), source-route-failed (5)

icmp-type number icmp6-type icmp6-type-value

ICMP packet type field. Normally, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port.

In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): echo-reply (0), echo-request (8), info-reply (16), info-request (15), mask-request (17), mask-reply (18), parameter-problem (12), redirect (5), router-advertisement (9), router-solicit (10), source-quench (4), time-exceeded (11), timestamp (13), timestamp-reply (14), or unreachable (3).

packet-length number

Total IP packet length.

port number

TCP or UDP source or destination port field. You cannot specify both the port match and either the destination-port or source-port match condition in the same term.

In place of the numeric value, you can specify one of the text synonyms listed under destination-port.

protocol number

IP protocol field. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah, egp (8), esp (50), gre (47), icmp (1), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), tcp (6), or udp (17).

This match condition is supported for IPv6 only on Junos Trio chipset-based devices that are configured for enhanced-ip mode.

source prefixprefix-offset number

IP source address field.

You can use the prefix-offset optional field, which is available only on Junos Trio chipset-based devices that are configured for enhanced-ip mode, to specify the number of bits that must be skipped before Junos OS starts matching an IPv6 prefix.

source-port number

TCP or UDP source port field. You cannot specify the port and source-port match conditions in the same term.

In place of the numeric field, you can specify one of the text synonyms listed under destination-port.

tcp-flag type

TCP header format.

Actions for Flow Routes

You can specify the action to take if the packet matches the conditions you have configured in the flow route. To configure an action, include the then statement at the [edit routing-options flow] hierarchy level.

Table 2 describes the flow route actions.

Table 2: Flow Route Action Modifiers

Action or Action Modifier

Description

Actions

accept

Accept a packet. This is the default.

discard

Discard a packet silently, without sending an Internet Control Message Protocol (ICMP) message.

community

Replace any communities in the route with the specified communities.

mark value

Set a DSCP value for traffic that matches this flow. Specify a value from 0 through 63. This action is supported only on Junos Trio chipset-based devices that are configured for enhanced-ip mode.

next term

Continue to the next match condition for evaluation.

routing-instance extended-community

Specify a routing instance to which packets are forwarded.

rate-limit bits-per-second

Limit the bandwidth on the flow route. Express the limit in bits per second (bps). Beginning with Junos OS Release 16.1R4, the rate-limit range is [0 through 1000000000000].

sample

Sample the traffic on the flow route.

Validating Flow Routes

The Junos OS installs flow routes into the flow routing table only if they have been validated using the validation procedure. The Routing Engine does the validation before the installing routes into the flow routing table.

Flow routes received using the BGP network layer reachability information (NLRI) messages are validated before they are installed into the flow primary instance routing table instance.inetflow.0. The validation procedure is described in the draft-ietf-idr-flow-spec-09.txt, Dissemination of Flow Specification Rules. You can bypass the validation process for flow routes using BGP NLRI messages and use your own specific import policy.

To trace validation operations, include the validation statement at the [edit routing-options flow] hierarchy level.

Support for BGP Flow-Specification Algorithm Version 7 and Later

By default, the Junos OS uses the term-ordering algorithm defined in version 6 of the BGP flow specification draft. In Junos OS Release 10.0 and later, you can configure the router to comply with the term-ordering algorithm first defined in version 7 of the BGP flow specification and supported through RFC 5575, Dissemination of Flow Specification Routes.

Best Practice

We recommend that you configure the Junos OS to use the term-ordering algorithm first defined in version 7 of the BGP flow specification draft. We also recommend that you configure the Junos OS to use the same term-ordering algorithm on all routing instances configured on a router.

To configure BGP to use the flow-specification algorithm first defined in version 7 of the Internet draft, include the standard statement at the [edit routing-options flow term-order] hierarchy level.

To revert to using the term-ordering algorithm defined in version 6, include the legacy statement at the [edit routing-options flow term-order] hierarchy level.

Note

The configured term order has only local significance. That is, the term order does not propagate with flow routes sent to the remote BGP peers, whose term order is completely determined by their own term order configuration. Therefore, you should be careful when configuring the order-dependent action next term when you are not aware of the term order configuration of the remote peers. The local next term might differ from the next term configured on the remote peer.

Note

On Junos OS Evolved, next term cannot appear as the last term of the action. A filter term where next term is specified as an action but without any match conditions configured is not supported.

Starting in Release 16.1, Junos OS excludes applying the flowspec filter to traffic received on specific interfaces. A new term is added at the beginning of the flowspec filter that accepts any packet received on these specific interfaces. The new term is a variable that creates an exclusion list of terms attached to the forwarding table filter as a part of the flow specification filter.

To exclude the flowspec filter from being applied to traffic received on specific interfaces, you must first configure a group-id on such interfaces by including the family inet filter group group-id statement at the [edit interfaces] hierarchy level and then attach the flowspec filter with the interface group by including the flow interface-group group-id exclude statement at the [edit routing-options] hiearchy level. You can configure only one group-id per routing instance with the set routing-options flow interface-group group-id statement.

Example: Enabling BGP to Carry Flow-Specification Routes

This example shows how to allow BGP to carry flow-specification network layer reachability information (NLRI) messages.

Requirements

Before you begin:

  • Configure the device interfaces.

  • Configure an interior gateway protocol (IGP).

  • Configure BGP.

  • Configure a routing policy that exports routes (such as direct routes or IGP routes) from the routing table into BGP.

Overview

Propagating firewall filter information as part of BGP enables you to propagate firewall filters against denial-of-service (DOS) attacks dynamically across autonomous systems. Flow routes are encapsulated into the flow-specification NLRI and propagated through a network or virtual private networks (VPNs), sharing filter-like information. Flow routes are an aggregation of match conditions and resulting actions for packets. They provide you with traffic filtering and rate-limiting capabilities much like firewall filters. Unicast flow routes are supported for the default instance, VPN routing and forwarding (VRF) instances, and virtual-router instances.

Import and export policies can be applied to the family inet flow or family inet-vpn flow NLRI, affecting the flow routes accepted or advertised, similar to the way import and export policies are applied to other BGP families. The only difference is that the flow policy configuration must include the from rib inetflow.0 statement. This statement causes the policy to be applied to the flow routes. An exception to this rule occurs if the policy has only the then reject or the then accept statement and no from statement. Then, the policy affects all routes, including IP unicast and IP flow.

The flow route filters are first configured on a router statically, with a set of matching criteria followed by the actions to be taken. Then, in addition to family inet unicast, family inet flow (or family inet-vpn flow) is configured between this BGP-enabled device and its peers.

By default, statically configured flow routes (firewall filters) are advertised to other BGP-enabled devices that support the family inet flow or family inet-vpn flow NLRI.

The receiving BGP-enabled device performs a validation process before installing the firewall filter into the flow routing table instance-name.inetflow.0. The validation procedure is described in RFC 5575, Dissemination of Flow Specification Rules.

The receiving BGP-enabled device accepts a flow route if it passes the following criteria:

  • The originator of a flow route matches the originator of the best match unicast route for the destination address that is embedded in the route.

  • There are no more specific unicast routes, when compared to the destination address of the flow route, for which the active route has been received from a different next-hop autonomous system.

The first criterion ensures that the filter is being advertised by the next-hop used by unicast forwarding for the destination address embedded in the flow route. For example, if a flow route is given as 10.1.1.1, proto=6, port=80, the receiving BGP-enabled device selects the more specific unicast route in the unicast routing table that matches the destination prefix 10.1.1.1/32. On a unicast routing table containing 10.1/16 and 10.1.1/24, the latter is chosen as the unicast route to compare against. Only the active unicast route entry is considered. This follows the concept that a flow route is valid if advertised by the originator of the best unicast route.

The second criterion addresses situations in which a given address block is allocated to different entities. Flows that resolve to a best-match unicast route that is an aggregate route are only accepted if they do not cover more specific routes that are being routed to different next-hop autonomous systems.

You can bypass the validation process for flow routes using BGP NLRI messages and use your own specific import policy. When BGP is carrying flow-specification NLRI messages, the no-validate statement at the [edit protocols bgp group group-name family inet flow] hierarchy level omits the flow route validation procedure after packets are accepted by a policy. You can configure the import policy to match on destination address and path attributes such as community, next-hop, and AS path. You can specify the action to take if the packet matches the conditions you have configured in the flow route. To configure an action, include the statement at the [edit routing-options flow] hierarchy level. The flow specification NLRI type includes components such as destination prefix, source prefix, protocol, and ports as defined in the RFC 5575. The import policy can filter an inbound route using path attributes and destination address in the flow specification NLRI. The import policy cannot filter any other components in the RFC 5575.

The flow specification defines required protocol extensions to address most common applications of IPv4 unicast and VPN unicast filtering. The same mechanism can be reused and new match criteria added to address similar filtering for other BGP address families (for example, IPv6 unicast).

After a flow route is installed in the inetflow.0 table, it is also added to the list of firewall filters in the kernel.

On routers only, flow-specification NLRI messages are supported in VPNs. The VPN compares the route target extended community in the NLRI to the import policy. If there is a match, the VPN can start using the flow routes to filter and rate-limit packet traffic. Received flow routes are installed into the flow routing table instance-name.inetflow.0. Flow routes can also be propagated throughout a VPN network and shared among VPNs. To enable multiprotocol BGP (MP-BGP) to carry flow-specification NLRI for the inet-vpn address family, include the flow statement at the [edit protocols bgp group group-name family inet-vpn] hierarchy level. VPN flow routes are supported for the default instance only. Flow routes configured for VPNs with family inet-vpn are not automatically validated, so the no-validate statement is not supported at the [edit protocols bgp group group-name family inet-vpn] hierarchy level. No validation is needed if the flow routes are configured locally between devices in a single AS.

Import and export policies can be applied to the family inet flow or family inet-vpn flow NLRI, affecting the flow routes accepted or advertised, similar to the way import and export policies are applied to other BGP families. The only difference is that the flow policy configuration must include the from rib inetflow.0 statement. This statement causes the policy to be applied to the flow routes. An exception to this rule occurs if the policy has only the then reject or the then accept statement and no from statement. Then, the policy affects all routes, including IP unicast and IP flow.

This example shows how to configure the following export policies:

  • A policy that allows the advertisement of flow routes specified by a route-filter. Only the flow routes covered by the 10.13/16 block are advertised. This policy does not affect unicast routes.

  • A policy that allows all unicast and flow routes to be advertised to the neighbor.

  • A policy that disallows all routes (unicast or flow) to be advertised to the neighbor.

Configuration

Configuring a Static Flow Route

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

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 the BGP peer sessions:

  1. Configure the match conditions.
  2. Configure the action.
  3. (Recommended) For the flow specification algorithm, configure the standard-based term order.

    In the default term ordering algorithm, as specified in the flowspec RFC draft Version 6, a term with less specific matching conditions is always evaluated before a term with more specific matching conditions. This causes the term with more specific matching conditions to never be evaluated. Version 7 of RFC 5575 made a revision to the algorithm so that the more specific matching conditions are evaluated before the less specific matching conditions. For backward compatibility, the default behavior is not altered in Junos OS, even though the newer algorithm makes more sense. To use the newer algorithm, include the term-order standard statement in the configuration. This statement is supported in Junos OS Release 10.0 and later.

Results

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

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

Advertising Flow Routes Specified by a Route Filter

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

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 the BGP peer sessions:

  1. Configure the BGP group.
  2. Configure the flow policy.
  3. Configure the local autonomous system (AS) number.

Results

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

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

Advertising All Unicast and Flow Routes

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

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 the BGP peer sessions:

  1. Configure the BGP group.
  2. Configure the flow policy.
  3. Configure the local autonomous system (AS) number.

Results

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

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

Advertising No Unicast or Flow Routes

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

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 the BGP peer sessions:

  1. Configure the BGP group.
  2. Configure the flow policy.
  3. Configure the local autonomous system (AS) number.

Results

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

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

Limiting the Number of Flow Routes Installed in a Routing Table

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

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.

Note

Application of a route limit might result in unpredictable dynamic route protocol behavior. For example, once the limit is reached and routes are being rejected, BGP does not necessarily attempt to reinstall the rejected routes after the number of routes drops below the limit. BGP sessions might need to be cleared to resolve this issue.

To limit the flow routes:

  1. Set an upper limit for the number of prefixes installed in inetflow.0 table.
  2. Set a threshold value of 50 percent, where when 500 routes are installed, a warning is logged in the system log.

Results

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

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

Limiting the Number of Prefixes Received on a BGP Peering Session

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, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

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.

Configuring a prefix limit for a specific neighbor provides more predictable control over which peer can advertise how many flow routes.

To limit the number of prefixes:

  1. Set a limit of 1000 BGP routes from neighbor 10.12.99.2.
  2. Configure the neighbor session to be brought down when the maximum number of prefixes is reached.

    If you specify a percentage, as shown here, messages are logged when the number of prefixes reaches that percentage.

    After the session is brought down, the session reestablishes in a short time unless you include the idle-timeout statement.

Results

From configuration mode, confirm your configuration by entering the show protocols command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

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

Verification

Confirm that the configuration is working properly.

Verifying the NLRI

Purpose

Look at the NLRI enabled for the neighbor.

Action

From operational mode, run the show bgp neighbor 10.12.99.5 command. Look for inet-flow in the output.

user@host> show bgp neighbor 10.12.99.5

Verifying Routes

Purpose

Look at the flow routes. The sample output shows a flow route learned from BGP and a statically configured flow route.

For locally configured flow routes (configured at the [edit routing-options flow] hierarchy level), the routes are installed by the flow protocol. Therefore, you can display the flow routes by specifying the table, as in show route table inetflow.0 or show route table instance-name.inetflow.0, where instance-name is the routing instance name. Or, you can display all locally configured flow routes across multiple routing instances by running the show route protocol flow command.

If a flow route is not locally configured, but received from the router’s BGP peer, this flow route is installed in the routing table by BGP. You can display the flow routes by specifying the table or by running show route protocol bgp, which displays all BGP routes (flow and non-flow).

Action

From operational mode, run the show route table inetflow.0 command.

user@host> show route table inetflow.0
user@host> show route table inetflow.0 extensive
user@host> show route hidden

Meaning

A flow route represents a term of a firewall filter. When you configure a flow route, you specify the match conditions and the actions. In the match attributes, you can match a source address, a destination address, and other qualifiers such as the port and the protocol. For a single flow route that contains multiple match conditions, all the match conditions are encapsulated in the prefix field of the route. When you issue the show route command on a flow route, the prefix field of the route is displayed with all of the match conditions. 10.12.44.1,* means that the matching condition is match destination 10.12.44.1/32. If the prefix in the output were *,10.12.44.1, this would mean that the match condition was match source 10.12.44.1/32. If the matching conditions contain both a source and a destination, the asterisk is replaced with the address.

The term-order numbers indicate the sequence of the terms (flow routes) being evaluated in the firewall filter. The show route extensive command displays the actions for each term (route).

Verifying Flow Validation

Purpose

Display flow route information.

Action

From operational mode, run the show route flow validation detail command.

user@host> show route flow validation detail

Verifying Firewall Filters

Purpose

Display the firewall filters that are installed in the kernel.

Action

From operational mode, run the show firewall command.

user@host> show firewall

Verifying System Logging When Exceeding the Number of Allowed Flow Routes

Purpose

If you configure a limit on the number of flow routes installed, as described in Limiting the Number of Flow Routes Installed in a Routing Table, view the system log message when the threshold is reached.

Action

From operational mode, run the show log <log-filename> command.

user@host> show log flow-routes-log-file

Verifying System Logging When Exceeding the Number of Prefixes Received on a BGP Peering Session

Purpose

If you configure a limit on the number of flow routes installed, as described in Limiting the Number of Prefixes Received on a BGP Peering Session, view the system log message when the threshold is reached.

Action

From operational mode, run the show log <log-filename> command.

user@host> show log flow-routes-log-file

Example: Configuring BGP to Carry IPv6 Flow Specification Routes

This example shows how to configure IPv6 flow specification for traffic filtering. BGP flow specification can be used to automate inter-domain and intra-domain coordination of traffic filtering rules in order to mitigate denial-of-service attacks.

Requirements

This example uses the following hardware and software components:

  • Two MX Series routers

  • Junos OS Release 16.1 or later

Before you enable BGP to carry IPv6 flow specification routes:

  1. Configure IP addresses on the device interfaces.
  2. Configure BGP.
  3. Configure a routing policy that exports routes (such as static routes, direct routes, or IGP routes) from the routing table into BGP.

Overview

Flow specification provides protection against denial-of-service attacks and restricts bad traffic that consumes the bandwidth and stops it near the source. In earlier Junos OS releases, flow specification rules were propagated for IPv4 over BGP as network layer reachability information. Beginning with Junos OS Release 16.1, the flow specification feature is supported on the IPv6 family and allows propagation of traffic flow specification rules for IPv6 and IPv6 VPN.

Topology

Figure 7 shows the sample topology. Router R1 and Router R2 belong to different autonomous systems. IPv6 flow specification is configured on Router R2. All incoming traffic is filtered based on the flow specification conditions, and the traffic is treated differently depending on the specified action. In this example, all traffic heading to abcd::11:11:11:10/128 that matches the flow specification conditions is discarded; whereas, traffic destined to abcd::11:11:11:30/128 and matching the flow specification conditions is accepted.

Figure 7: Configuring BGP to Carry IPv6 Flow Routes
Configuring BGP to Carry
IPv6 Flow Routes

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 R1

Router R2

Configuring Router R2

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 R2:

Note

Repeat this procedure for Router R1 after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the interfaces with IPv6 addresses.
  2. Configure the IPv6 loopback address.
  3. Configure the router ID and autonomous system (AS) number.
  4. Configure an EBGP peering session between Router R1 and Router R2.
  5. Configure a static route and a next hop. Thus a route is added to the routing table to verify the feature in this example.
  6. Specify flow specification conditions.
  7. Configure a discard action to discard packets that match the specified match conditions.
  8. Specify flow specification conditions.
  9. Configure an accept action to accept packets that match the specified match conditions
  10. Define a policy that allows BGP to accept static routes.

Results

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

Verification

Confirm that the configuration is working properly.

Verifying the Presence of IPv6 Flow Specification Routes in the inet6flow Table

Purpose

Display the routes in the inet6flow table in Router R1 and R2, and verify that BGP has learned the flow routes.

Action

From operational mode, run the show route table inet6flow.0 extensive command on Router R1.

user@R1> show route table inet6flow.0 extensive

From operational mode, run the show route table inet6flow.0 extensive command on Router R2.

user@R2> show route table inet6flow.0 extensive

Meaning

The presence of routes abcd::11:11:11:10/128 and abcd::11:11:11:30/128 in the inet6flow table confirms that BGP has learned the flow routes.

Verifying BGP Summary Information

Purpose

Verify that the BGP configuration is correct.

Action

From operational mode, run the show bgp summary command on Router R1 and R2.

user@R1> show bgp summary
user@R2> show bgp summary

Meaning

Verify that the inet6.0 table contains the BGP neighbor address and a peering session has been established with its BGP neighbor.

Verifying Flow Validation

Purpose

Display flow route information.

Action

From operational mode, run the show route flow validation command on Router R1.

user@R1> show route flow validation

Meaning

The output displays the flow routes in the inet6.0 table.

Verifying the Flow Specification of IPv6 Routes

Purpose

Display the number of packets that are discarded and accepted based on the specified flow specification routes.

Action

From operational mode, run the show firewall filter_flowspec_default_inet6_ command on Router R2.

user@R2> show firewall filter __flowspec_default_inet6__

Meaning

The output indicates that packets destined to abcd::11:11:11:10/128 are discarded and 88826 packets have been accepted for the route abcd::11:11:11:11:30/128.

See also

Configuring BGP Flow Specification Action Redirect to IP to Filter DDoS Traffic

Starting in Junos OS Release 18.4R1, BGP flow specification as described in BGP Flow-Spec Internet draft draft-ietf-idr-flowspec-redirect-ip-02.txt, Redirect to IP Action is supported. Redirect to IP action uses extended BGP community to provide traffic filtering options for DDoS mitigation in service provider networks. Legacy flow specification redirect to IP uses the BGP nexthop attribute. Junos OS advertises redirect to IP flow specification action using the extended community by default. This feature is required to support service chaining in virtual service control gateway (vSCG). Redirect to IP action allows to divert matching flow specification traffic to a globally reachable address that could be connected to a filtering device that can filter the DDoS traffic and send the clean traffic to the egress device.

Before you begin redirecting traffic to IP for BGP flow specification routes, do the following:

  1. Configure the device interfaces.
  2. Configure OSPF or any other IGP protocol.
  3. Configure MPLS and LDP.
  4. Configure BGP.

Configure the redirect to IP feature using the BGP extended community.

  1. Configure redirect to IP action for static IPv4 flow specification routes as specified in the BGP Flow-Spec Internet draft draft-ietf-idr-flowspec-redirect-ip-02.txt, Redirect to IP Action .

    Junos OS advertises redirect to IP flow specification action using the extended community redirect to IP by default. The ingress device detects and sends the DDoS traffic to the specified IP address.

    For example, redirect the DDoS traffic to IPv4 address 10.1.1.1.

  2. Configure redirect to IP action for static IPv6 flow specification routes.

    For example, redirect the DDoS traffic to IPv6 address 1002:db8::

  3. Define a policy to filter traffic from a specific BGP community.

    For example, define a policy p1 to filter traffic from BGP community redirip.

  4. Define a policy to set, add, or delete a BGP community and specify the extended community.

    For example, define a policy p1 to set, add, or delete a community reidirip and an extended community to redirect traffic to IP address 10.1.1.1.

  5. Configure BGP to use VRF.inet.0 table to resolve VRF flow specification routes include statement at the hierarchy level.

Configure the legacy flow specification redirect to IP feature using the nexthop attribute.

Note

You cannot configure policies to redirect traffic to an IP address using BGP extended community and the legacy redirect to next hop IP address together.

  1. Configure legacy flow specification redirect to IP specified in the internet draft draft-ietf-idr-flowspec-redirect-ip-00.txt , BGP Flow-Spec Extended Community for Traffic Redirect to IP Next Hop include at the hierarchy level.
  2. Define a policy to match the next hop attribute.

    For example, define a policy p1 to redirect traffic to next hop IP address 10.1.1.1.

  3. Define a policy to set, add, or delete the BGP community using the legacy flow specification next hop attribute redirect to IP action.

    For example, define a policy p1 and set, add, or delete a BGP community redirnh to redirect the DDoS traffic to the the next hop IP address 10.1.1.1.

Release History Table
Release
Description
Beginning with Junos OS Release 16.1R4, the rate-limit range is [0 through 1000000000000].
Beginning with Junos OS Release 16.1, IPv6 support is extended to BGP flow specification that allows propagation of traffic flow specification rules for IPv6 and VPN-IPv6 packets.
Starting with Junos OS Release 16.1R1, BGP flow specification supports traffic-marking extended-community filtering action.
Starting in Release 16.1, Junos OS excludes applying the flowspec filter to traffic received on specific interfaces.
Beginning with Junos OS Release 15.1, changes are implemented to extend nonstop active routing (NSR) support for existing inet-flow and inetvpn-flow families and extend route validation for BGP flowspec per draft-ietf-idr-bgp-flowspec-oid-01.