IP source address spoofing attacks are a prevalent threat to network security, against which ACLs and unicast reverse path forwarding (uRPF) are typically used. Although both ACL and uRPF mitigate IP source address spoofing attacks, they each have notable limitations, as follows:

· High maintenance costs—ACL rules require manual maintenance, which is both tedious and error-prone.

· Risks posed by misconfiguration—Incorrect ACL configuration can block legitimate traffic or mistakenly permit malicious traffic to pass through.

· False-positive risk—uRPF validates source addresses based on the FIB. On networks with asymmetric routing, strict uRPF check might erroneously block legitimate traffic, while loose uRPF check might permit malicious traffic to pass through.

Source Address Validation in Intra-domain Networks and Inter-domain Networks (SAVNET) is used to resolve these issues.

SAVNET is a protocol for preventing IPv6 source address spoofing attacks. A SAVNET enabled device creates SAVNET entries based on SAVNET packets and the packet incoming interfaces to verify the validity of IPv6 packet source prefixes. Upon receiving an IPv6 packet on an interface, the device searches for a SAVNET entry that matches the packet's source IPv6 address prefix and the incoming interface. If no match is found, the device drops the packet.

SAVNET can be deployed on all devices in the backbone network connecting to an access network.

SAVNET can be deployed within a single AS or across multiple ASs. The inter-domain deployment is implemented based on the intra-domain deployment. The following sections will introduce the two SAVNET deployment methods in details.

Intra-domain SAVNET

Intra-domain SAVNET protocol information

A device enabled with SAVNET is called a SAVNET device. Each SAVNET device creates SAVNET entries through the Source Prefix Advertisement (SPA) information and Destination Prefix Probing (DPP) information exchanged between neighbor SAVNET devices. A SAVNET entry records the mapping between an IPv6 packet source prefix and a packet incoming interface.

SPA information

When a SAVNET device in an address domain learns a source prefix locally, the device will advertise the learned source prefix to its neighbors through SPA information. In this way, each device can learn all source prefixes learned locally by other devices in the SAVNET domain. A piece of SPA information contains the following content:

· Origin Router ID—Router ID of the SAVNET device that sent the SPA information.

· Source Prefix—Source prefix coming from a locally learned direct route, static route, dynamic route, or User Network Route (UNR) route. You can use the import-route command in BGP IPv6 SAVNET address family view to import routes.

DPP information

A SAVNET device sends a piece of IPv6 DPP information to probe the forwarding path of the packet with a specific destination address in the address domain. The devices along the path will create SAVNET entries according to the DPP information. A piece of DPP information contains the following content:

· Origin Router ID—Router ID of the origin SAVNET device that sent the DPP information.

· Dest Prefix—Destination prefix coming from a non-direct forwarding destination prefix in the local IPv6 FIB table.

· Router ID List—List of router IDs for recording the forwarding path of the DPP information. A SAVNET device on the forwarding path adds its router ID to the router ID list when it forwards the DPP information to the nexthop neighbor.

BGP extension for SAVNET

Overview

SAVNET devices use Border Gateway Protocol (BGP) to transmit SAVNET protocol information. The BGP IPv6 SAVNET address family view has been added to the BGP module for exchanging BGP IPv6 SAVNET route information through sessions in the view. SPA information and DPP information are carried in BGP IPv6 SAVNET route information. The Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI) for the BGP IPv6 SAVNET address family are 2 and 251, respectively. For more information about BGP, see BGP configuration in Layer 3—IP Routing Configuration Guide.

BGP IPv6 SAVNET routes include two types:

· SPA routes—Used to transmit SPA information.

· DPP routes—Used to transmit DPP information.

Route generation mechanism

SPA routes

Based on the routes imported into the BGP IPv6 SAVNET address family view of a SAVNET device using the import-route command, the device generates SPA routes. An SPA route contains the source prefix and the origin router ID. The prefix in a generated route comes from a route prefix imported with the import-route command and the origin router ID is the router ID configured locally on the device.

On the following SPA routes can be advertised to the BGP IPv6 SAVNET peer:

· The outgoing interface of the IP route corresponding to the SPA route is configured as a user-network interface (UNI) by using the ipv6 savnet port-type command.

· An SAVNET access tag is applied to the SPA route through a routing policy.

DPP routes

After generating SPA routes based on the routes imported with the import-route command, a SAVNET device can generate the following types of DPP routes:

· DPP routes generated based on the forwarding destination prefixes of the non-direct entries in the IPv6 FIB—The routing protocol type of a non-direct entry is not direct. A generated DPP route contains the origin router ID, destination prefix, and router ID list. The origin router ID is the router ID configured locally on the device, and the destination prefix is the corresponding non-direct forwarding destination prefix in the IPv6 FIB table. The router ID in the router ID list is the one configured locally on the device.

· DPP routes generated based on IPv6 PBR applied on the SAVNET device—A DPP route can be generated only when IPv6 PBR is applied to the interface where the locally advertised source prefix resides. A generated DPP route contains the origin router ID, destination prefix, and router ID list. The origin router ID is the router ID configured locally on the device, and the router ID in the router ID list is the one configured locally on the device. The relationship between the destination prefix and the applied IPv6 PBR is as follows:

¡ For IPv6 PBR configured with an ACL:

- If the ACL only has permit rules for source address matching, DPP routes with the destination prefix as the unspecified address (::) are generated when the locally advertised source prefix information matches the ACL-specified source addresses. Otherwise, no DPP route is generated.

- If the ACL has permit rules for both source and destination address matching, DPP routes with the destination prefixes as the ACL-specified destination addresses are generated when the locally advertised source prefix information matches the ACL-specified source addresses. Otherwise, no DPP route is generated.

- If the ACL only has permit rules for destination address matching, DPP routes with the destination prefixes as the ACL-specified destination addresses are generated. If the any destination address is specified in a rule, a DPP route with the destination prefix as the unspecified address (::) is generated.

- If the ACL has no permit rules, no DPP route is generated.

¡ For IPv6 PBR configured with other match criteria, no DPP route is generated.

For more information about the import-route command, see BGP commands in Layer 3—IP Routing Command Reference. For more information about IPv6 PBR, see Layer 3—IP Routing Configuration Guide. For more information about ACLs, see ACL and QoS Configuration Guide.

Basic operating mechanism

SAVNET operates as follows:

1. Establishes BGP neighbors to create a SAVNET network.

2. Advertises SPA routes between BGP IPv6 SAVNET peers.

3. Transmits DPP routes between BGP IPv6 SAVNET peers.

4. Creates SAVNET entries.

5. Verifies received IPv6 packets based on the SAVNET entries.

Establishing BGP neighbors to create a SAVNET network

After BGP neighbors are established between devices and you configure the BGP IPv6 SAVNET address family for each device, SAVNET neighbors are established.

Advertising SPA routes between BGP IPv6 SAVNET peers

After a SAVNET device generates an SPA route, it advertises the SPA route to all BGP IPv6 SAVNET peers. Each SPA route recipient configured with the route reflection feature reflects the route. You do not need to configure a route reflector. During the transmission of the SPA route, the source prefix and origin router ID carried in the route does not change.

When a SAVNET neighbor receives the SPA route through the BGP IPv6 SAVNET session, it compares the router ID in the received SPA route with the locally configured router ID:

· If they are the same, the neighbor drops the route.

· If they are different, the neighbor saves the mapping between the source prefix and the router ID in the route to the local neighbor information table. Then the neighbor sends the SPA route to other BGP IPv6 SAVNET peers.

Transmitting DPP routes

The SAVNET device transmits the generated DPP routes based on the generation methods, if you have enabled SAVNET destination prefix probing using the destination-probing enable command:

· For DPP routes generated based on the forwarding destination prefixes of the non-direct entries in the IPv6 FIB

The device looks up the outgoing interface to the next hop for the destination prefix in the IPv6 FIB table and determines whether it has established a direct connection with a BGP IPv6 SAVNET peer through that interface. If a direct peer relationship is established, the device sends the DPP route only to that direct peer. If a direct peer relationship has not been established, the device does not send the DPP route.

· For DPP routes generated based on IPv6 PBR applied on the SAVNET device

The device determines whether it has established a direct connection with a BGP IPv6 SAVNET peer on the outgoing interface to the next hop configured by IPv6 PBR. If a direct peer relationship is established, the device sends the DPP route only to that direct peer. If a direct peer relationship has not been established, the device does not send the DPP route.

The above mechanism uses the optimal path to the destination prefix to send DPP information to the remote device so that all devices along the path can generate SAVNET entries based on the received DPP information.

After receiving a DPP route, the SAVNET neighbor device compares the origin router ID carried in the DPP route with the locally configured router ID.

· If they are the same, the device drops the DPP route.

· If they are different, the device matches the destination prefix carried in the DPP route with the local IPv6 FIB table.

¡ If an IPv6 FIB entry matching that prefix exists, the device adds its own router ID as a route attribute to the router ID list of the DPP route. The device then finds the outgoing interface to the next hop for the prefix in the FIB and determines whether it has established a direct BGP IPv6 SAVNET peer through that outgoing interface. If a direct peer relationship is established, the device forwards the DPP route only to that direct peer.

¡ If the destination prefix in the DPP route is the unspecified address (::), the device looks up each non-direct entry in the local IPv6 FIB table and generates a DPP route for each non-direct entry. The destination prefix in a generated DPP route is the destination address prefix in the corresponding non-direct entry. The device sends the generated DPP routes to only peers with which direct BGP IPv6 SAVNET session relationships have been established on the outgoing interfaces to the next hops in the non-direct entries.

¡ If no IPv6 FIB entry that matches the prefix exists, the device drops the DPP route.

Creating SAVNET entries

After receiving a DPP route, a SAVNET device searches for locally stored source prefixes (transmitted through the SPA routes) according to the origin router ID in the route. If a source prefix with the same origin router ID as the DPP route exists, a SAVNET entry will be generated. In the generated SAVNET entry, the source prefix is bound to the interface that received the DPP route. When the device receives packets whose source addresses match the source prefix address, only the packets received from the interface specified in the SAVNET entry (DPP route receiving interface) will be processed. Packets received from other interfaces will be dropped.

Verifying the received IPv6 packet based on the SAVNET entries

SAVNET entries can be used to verify the validity of the IPv6 packets recevied on a UNI. Upon receiving an IPv6 packet on an interface, the SAVNET device searches for a SAVNET entry with the prefix of the packet's source IPv6 address and the packet incoming interface. If no match is found, the device drops the packet.

Transmission process analysis

As shown in Figure 1, in the SAVNET network, Device A, Device B, and Device C are all SAVNET devices. A BGP IPv6 SAVNET session is set up. Device A is connected to the user network through the 10::/64 subnet. To ensure the security of the core network, both Device B and Device C need to generate SAVNET entries and process only the user network packets received from Port 1.

Figure 1 SAVNET network diagram

‌

With SAVNET configured, the transmission process of SAVNET protocol information and the generation process of SAVNET entries are as follows:

1. After you import a local direct route into the BGP IPv6 SAVNET address family of Device A, Device A generates an SPA route with source prefix 10::/64 and origin router ID 1.1.1.1, and advertises it to Device B. Upon receiving the SPA route, Device B records the mapping between the source prefix information and the origin router ID, and then reflects the route to Device C. Upon receiving the SPA route reflected by Device B, Device C records the mapping between the source prefix information and the origin router ID.

2. Device A searches for local IPv6 FIB entries, and identifies two non-direct forwarding destination prefixes 22::/64 and 30::/64. Based on the prefixes, it generates two DPP routes. The destination prefixes for the two DPP routes are 22::/64 and 30::/64, respectively. Each of the DPP routes has a router ID list that contains only router ID 1.1.1.1.

3. In the IPv6 FIB entries of Device A, the nexthop outgoing interfaces of the forwarding destination prefixes 22::/64 and 30::/64 are both Port 1. After Device A creates a direct BGP IPv6 SAVNET session with Device B on Port 1, Device A advertises both DPP routes to Device B.

4. After Device B receives the DPP route with destination prefix 22::/64, it searches for the locally stored source prefix information corresponding to the origin router ID carried in the DPP route information. Because matching source prefix 10::/64 is found, Device B generates a SAVNET entry with prefix 10::/64 and incoming interface Port 1. In subsequent packet forwarding, for received packets whose source IPv6 addresses belong to the 10::/64 prefix, Device B processes only the packets received from Port 1. Because the destination prefix 22::/64 is a direct forwarding destination prefix in the IPv6 FIB table of Device B, Device B will not forward the DPP route with destination prefix 22::/64.

5. After Device B receives the DPP route with destination prefix 30::/64, it searches for the locally stored source prefix information corresponding to the origin router ID carried in the DPP route information. Matching prefix 10::/64 is found and the incoming interface is Port 1. The DPP routes with destination prefix 30::/64 and 22::/64 respectively carry the same origin router ID and trigger generation of the same SAVNET entry. However, Device B generates only one entry but not duplicate entries.

6. By searching for the local IPv6 FIB table, Device B detects an entry with non-direct forwarding destination prefix 30::/64 and nexthop outgoing interface Port 2. Device B has established a direct BGP IPv6 SAVNET session with Device C on Port 2. Thus, Device B adds the local router ID to the router ID list of the DPP route with destination prefix 30::/64 sent by Device A, without modifying the origin router ID in the route. Then Device B forwards the DPP route to Device C through Port 2.

7. After Device C receives the DPP route with destination prefix 30::/64, it searches for the locally stored source prefix information corresponding to the origin router ID carried in the DPP route information. Because matching prefix 10::/64 is found, Device C generates a SAVNET entry with prefix 10::/64 and incoming interface Port 1. In subsequent packet forwarding, for received packets whose source IPv6 addresses belong to the 10::/64 prefix, Device C processes only the packets received from Port 1. Because the destination prefix 30::/64 is a direct forwarding destination prefix in the IPv6 FIB table of Device C, Device C will not forward the DPP route with destination prefix 30::/64.

Agent DPP routes

Background

As shown in Figure 2, Device E advertises prefix 1::1/128 to all other devices in the network. After you import the prefix into the BGP IPv6 SAVNET address family of Device A, it generates an SPA route and a DPP route, and then advertises the routes to other devices. The forwarding path of the DPP route is shown by the blue path in the figure.

Under normal circumstances, when Device E receives the SPA route and DPP route from Device A, it generates a SAVNET entry with incoming interface Port 1. It processes only the packets received from Port 1. If the link between Device B and Device C is disconnected, Device E needs to wait for the route from Device A to 1::1/128 to converge and Device A to regenerate a DPP route. After receiving the updated DPP route transmitted through the path Device A > Device B > Device D > Device E and updating the generated SAVNET entry, Device E can process the packets received from Port 2.

Figure 2 Agent DPP route networking diagram

‌

DPP routes are sent through BGP route-refresh messages at a specific interval. The devices cannot respond to network link changes in real time and update the advertised DPP routes.

Operating mechanism

BGP's support for sending agent DPP routes can resolve the above issue in SAVNET networks.

NOTE:

The agent DPP route feature is supported on devices by default, and does not need to be configured.

The operating mechanism of the agent DPP route feature is as below:

1. Upon receiving a DPP route, a DPP relay device (device other than the one generating a specific DPP route) records and saves the prefix information to be probed in the DPP route.

2. If the next hop of the destination prefix changes but the DPP relay device does not receive the updated DPP route, the relay device immediately generates an agent DPP route with the same destination prefix and sends it to the next hop BGP IPv6 SAVNET peer that can reach the destination prefix.

3. Upon receiving the agent DPP route, the peer forwards it as a regular DPP route.

In this example, when the link between Device B and Device C is disconnected, Device A's routes reconverge. Device A might still be in the interval waiting to send the next DPP route message and cannot help other devices update the SAVNET entries in time. After Device B's routes converge, if it has not received the DPP update route from Device A, it immediately advertise an agent DPP route and transmit it to Device E along the path Device B > Device D > Device E. Device E updates the SAVNET entry based on the agent DPP route to ensure correct processing of packets received from Port 2.

The agent DPP route has the same effect as the updated DPP route sent by Device A after full route convergence. The agent DPP route feature allows quick responses to changes on the next hop of a destination prefix in the network. As a result, SAVNET devices can update the SAVNET entries quickly without waiting for the DPP route sending interval of the DPP route generating device, which minimizes packet loss as much as possible.

SAVNET access scenarios

Introduction

By default, a SAVNET device generate SAVNET entries only when it receives DPP routes. Because generation of DPP routes requires existence of non-direct entries or PBR in the FIB, DPP routes are often only generated on backbone network devices deployed with SAVNET. As shown in Figure 3, CE devices connected to the PE devices at the edge of the backbone network cannot generate DPP routes. Thus, the PE devices cannot generate SAVNET entries containing interfaces connected to the access subnets.

Figure 3 SAVNET access scenarios

‌

A mechanism has been developed to configure SAVNET devices to generate SAVNET entries using only SPA routes, helping PE devices in the access scenarios filter source address spoofed packets. This mechanism supports both single-homed and multi-homed access scenarios.

Operating mechanism

In an access scenario, after you configure an access tag for the user-side interface on a PE, the tag information can be carried in the SPA route. Based on the carried access tag information, the PE device can generate a SAVNET entry. The specific operating mechanism is as follows:

1. After you execute the ipv6 savnet miig-tag command on the user-side interface of the PE, this interface is configured with an access tag, including the access tag value and access type information.

2. When you execute the import-route command to import a route for obtaining source prefix information and generating an SPA route, the generated SPA route carries the access tag information (including tag value and access type) if all of the following conditions are met:

¡ You have specified the route-policy route-policy-name option in the import-route command.

¡ You have configured the apply tag command for the route policy specified by the route-policy route-policy-name option.

The tag value is that specified by the apply tag command and the access type is that specified by the ipv6 savnet miig-tag command.

3. When the PE device generates or receives the SPA route carrying the access tag information, it checks whether an interface with access tag information matching that carried in the SPA route exists locally:

¡ If an interface exists, the device generates a SAVNET entry with the source prefix as that carried in the SPA route and the incoming interface as this interface.

¡ If no interface exists, the device does not generate a SAVNET entry.

4. When the device receives an updated SPA route, the SAVNET entry generated based on the SPA route will be updated.

Example

Figure 4 Generating SAVNET entries based on access tags

‌

As shown in Figure 4, PE 1 and PE 2 are the edge devices of the SAVNET backbone network and provide access services for CE 1 and CE 2. CE 1 is single-homed to PE 1, while CE 2 is multi-homed to both PE 1 and PE 2. CE 1 advertises prefix P1 in subnet 1 to PE 1, while CE 2 advertises prefix P2 in subnet 2 to PE 1 and prefix P3 in subnet 2 to PE 2.

PE 1 and PE 2 are configured with access tag information. The process of generating SAVNET entries based on the access tag information is as follows:

1. PE 1 generates SPA routes based on prefixes P1 and P2 and carries access tag information through a routing policy:

¡ SPA Route 1 carries source prefix P1, access tag value 1, and access type single-homed.

¡ SPA Route 2 carries source prefix P2, access tag value 2, and access type complete multi-homed.

2. Because Interface 1 and Interface 2 of PE 1 have access tag information matching that carried in SPA Route 1 and Route 2, respectively, PE 1 generates two SAVNET entries: one with source prefix P1 and incoming interface Interface 1, and the other with source prefix P2 and incoming interface Interface 2.

3. PE 2 generates SPA Route 3 based on prefix P3 and carries access tag information for the SPA route through a routing policy. SPA Route 3 carries source prefix P3, access tag value 2, and access type complete multi-homed.

4. Because Interface 1 of PE 2 has access tag information matching that carried in SPA Route 3, PE 2 generates a SAVNET entry with source prefix P3 and incoming interface Interface 1.

5. PE 1 advertises SPA Route 1 and Route 2 to PE 2, and PE 2 advertises SPA Route 3 to PE 1.

6. Because Interface 2 of PE 1 has access tag information matching that carried in SPA Route 3, PE 1 generates a SAVNET entry with source prefix P3 and incoming interface Interface 2.

7. Because PE 2 does not have an interface with access tag information matching that carried in SPA Route 1, it does not generate a SAVNET entry based on SPA Route 1. Because Interface 1 of PE 2 has access tag information matching that carried in SPA Route 2, PE 2 generates a SAVNET entry with source prefix P2 and incoming interface Interface 1.

Inter-domain SAVNET

Inter-domain SAVNET networking model

As shown in Figure 5, in the scenario where SAVNET validates inter-domain traffic for security, you need to configure two ASs:

· Source AS—The AS to which the packet source address prefix belongs.

· Validation AS—The AS where SAVNET entries are generated to validate inter-domain traffic.

Figure 5 Inter-domain SAVNET networking model

As shown in Figure 6, both the source AS and the validation AS need to elect a Designated Router (DR) among all their border devices. An EBGP IPv6 SAVNET session needs to be established between the DR devices to exchange inter-domain SAVNET protocol information. All non-DR ASBRs must establish IBGP IPv6 SAVNET sessions with the DR within the same AS to exchange intra-domain SAVNET protocol information.

Figure 6 Inter-domain SAVNET network deployment

Inter-domain SAVNET protocol information

SAVNET has added the following types of protocol information to facilitate inter-domain SAVNET networking:

· Inter-domain SPA information—The DR in the validation AS learns source prefixes from the source AS through inter-domain SPA information, and propagates the source prefixes to other ASBRs in the validation AS through IBGP IPv6 SAVNET sessions. An inter-domain SPA message contains the following key information:

¡ Source AS Number—Number of the source AS from which the source prefix information is originated.

¡ Source Prefixes—The source prefixes originate from directly connected, static, UNR, IGP, or EBGP routes learned locally within the source AS by ASBRs. You can use the import-route command in BGP IPv6 SAVNET address family view to import these routes.

· Inter-domain DPP information: The source AS sends inter-domain DPP information to the validation AS to help the ASBRs in the validation AS identify the optimal egress to the source AS and generate an SAVNET entry and based on that egress. An inter-domain DPP message contain the following key information:

¡ Source AS Number—Number of the source AS from which the inter-domain DPP message is originated.

¡ Validation AS number—Number of the destination AS to which the inter-domain DPP message is sent.

¡ Ingress Neighbor AS List—A list of neighbor ASs at the ingress, indicating the last-hop AS before reaching the validation AS on each optimal path from the source AS to the validation AS.

NOTE:

Inter-domain SPA and DPP information propagate via SPA and DPP routes. SPA routes that propagate intra-domain SPA information are called intra-domain SPA routes, while those that propagate inter-domain SPA information are called inter-domain SPA routes. Similarly, DPP routes that propagate intra-domain DPP information are called intra-domain DPP routes, and those that propagate inter-domain DPP information are called inter-domain DPP routes.

Operating mechanism

Figure 7 Inter-domain SAVNET entry generation process

As shown in Figure 7, an inter-domain SAVNET entry is generated as follows:

1. In the source AS, ASBR 1 and ASBR 2 import source prefixes P1 and P2 by using the import-route command. Then, the ASBRs use intra-domain SPA routes to advertise the source prefixes to the DR device ASBR 3.

2. ASBR 3 converts the intra-domain SPA routes to inter-domain SPA routes and sends them to the peer DR device ASBR 4.

3. ASBR 4 records the source prefixes and the source AS number carried by inter-domain SPA routes, and forwards these routes to other ASBRs in the validation AS.

4. The non-DR devices in the validation AS also record the source prefixes and the source AS number carried by inter-domain SPA routes.

5. The non-DR ASBRs in the source AS use the peer designate-router command to specify the DR and use the savnet validation-as command to specify the validation AS number. They collect the ingress neighbor AS numbers in the AS_PATHs from the source AS to the validation AS, and then send the collected ingress neighbor AS numbers to the DR device ASBR 3.

Figure 8 Source AS collecting ingress neighbor AS numbers

As shown in Figure 8, the source AS collects ingress neighbor AS numbers as follows:

¡ The ASBRs in the source AS obtain from the local BGP routing table the AS_PATHs of all preferred routes that pass through or originate from the validation AS.

¡ The ASBRs collect the penultimate AS on each AS_PATH from the source AS to the validation AS.

¡ The DR of the source AS then sends the summary of the collected AS numbers to the DR of the validation AS.

In this example, the source AS is AS 100 and the validation AS is AS 200. The source AS receives two preferred routes from the validation AS through different paths, with one path passing through AS 5 and AS 10, and the other path passing through AS 20. In the AS_PATHs of the two routes, AS 10 and AS 20 are the ingress neighbors for validation AS 200. The ASBRs in AS 100 send these ASs to the DR. The DR then consolidates them into an ingress neighbor AS list and transmits the list to AS 200.

The device also supports collecting ingress neighbor ASs for backup routes in FRR, ensuring that inter-domain traffic can still pass security validation after an FRR path switchover.

6. After ASBR 3 specifies the validation AS number (by using the savnet validation-as command), it also collects the ingress neighbor AS numbers from its own BGP routes. Then, ASBR 3 consolidates all the intra-domain ingress neighbor ASs into an ingress neighbor AS list and transmits the list to the peer DR device ASBR 4 through an inter-domain DPP route.

7. Upon receiving the inter-domain DPP route, ASBR 4 performs the following:

a. Identifies the outgoing interfaces for the neighbor ASs in the ingress neighbor AS list carried in the inter-domain DPP route.

b. Identifies the source prefixes according to the source AS number carried in the inter-domain DPP route.

c. Creates SAVNET entries for these source prefixes, with the incoming interfaces of these SAVNET entries being the outgoing interfaces to the ingress neighbor ASs. Each neighbor AS number has a SAVNET entry.

8. ASBR 4 forwards the received inter-domain DPP route to other ASBRs within the AS. These ASBRs also create SAVNET entries based on the inter-domain DPP information, following the same process as in step 7.

IGP-based intra-domain SAVNET

About IGP-based intra-domain SAVNET

Except for BGP-based intra-domain SAVNET, IS-IS SAVNET provides an optimized SAVNET solution to resolve these issues. In this solution, the SAVNET module automatically generates and updates accurate SAVNET entries based on IS-IS routing information to validate IPv6 source prefixes.

Operating mechanism

After you enable IS-IS SAVNET on each device in an IS-IS routing domain, IS-IS SAVNET operates on each device as follows:

1. Each device computes IS-IS routes and generates route entries. Each entry contains one destination prefix and one or multiple outgoing interfaces, in {destination prefix x; outgoing interface 1, outgoing interface 2, ...} format.

2. The IS-IS module sends the generated route entries to the SAVNET module. Each entry contains one destination prefix and one outgoing interface, in {destination prefix x; interface 1}, {destination prefix x; interface 2} format.

3. The SAVNET module generates SAVNET entries based on the received route entries, and then uses these entries to validate IPv6 packets.

When a path in the IS-IS routing domain changes, IS-IS regenerates a {destination prefix; outgoing interface} entry and sends it to the SAVNET module, which then updates the SAVNET entry based on the received entry.

SAVNET denylist and allowlist mechanisms

About the denylist and allowlist mechanisms

On a SAVNET network, you can configure the device to generate a SAVNET entry as a denylist or allowlist entry. When the device receives a packet after it generates SAVNET entries, the device processes the packet as follows:

· If the source IP address and incoming interface of the packet both match a SAVNET denylist entry, the device discards the packet. If the matching entry is allowlisted, the device receives and processes the packet.

· If the source IP address of the packet matches a SAVNET denylist entry but its incoming interface does not match the entry, the device receives and processes the packet. If the matching entry is allowlisted, the device discards the packet.

· If the source IP address of the packet does not match any SAVNET entry, the device takes action depending on the type of its incoming interface. If the packet arrives at an NNI interface, the device permits the packet to pass through. If the packet arrives at a UNI interface, the device discards the packet.

· On consumer interfaces of the SAVNET denylist, the device compares incoming packets only with denylisted SAVNET entries.

NOTE:

· If a packet matches a SAVNET entry that is not created based on the denylist or allowlist mechanism, the device processes that packet in the same way as it processes packets that match SAVNET allowlist entries.

· The denylist feature is applicable to IGP-based intra-domain SAVNET and BGP-based SAVNET. The allowlist feature is applicable only to IGP-based intra-domain SAVNET.

Denylist entry generation mechanism

The following information uses Figure 9 for example to describe how the device generates a SAVNET denylist entry.

1. The device creates SAVNET denylist entries upon receiving an IPv6 BGP unicast route, as follows:

2. Identifies the outgoing interface leading to the next hop of the route.
Determines whether the outgoing interface acts as source prefix producers.
If the outgoing interface acts as source prefix producers, the device identifies the consumer interfaces of each source prefix producer. An interface is the consumer of a source prefix producer if its consumer name is the same as the producer name.

3. For each consumer of each source prefix producer, generates a SAVNET denylist entry. In each entry, the source prefix is the destination address of the IPv6 BGP unicast route, the incoming interface is a consumer interface.

Figure 9 Process of SAVNET denylist entry generation

Allowlist entry generation mechanism

The following information uses Figure 10 for example to describe how the device generates a SAVNET allowlist entry.

1. When the device receives IGP routes, the device creates SAV routes, with their protocol type set to the IGP name. You can view these routes by executing the display bgp ipv6 savnet sav command.

2. When the device receives a BGP IPv6 unicast route from a remote SAVNET device, the device creates SAVNET entries based on the SAVNET allowlist mechanism, as follows:

a. The device searches the BGP SAV routes injected by the IGP for a match based on the destination address and incoming interface of the BGP IPv6 unicast route.

b. If a match is found, the device determines that a legitimate path is available to reach that destination address. Then, the device generates a SAVNET allowlist entry for that route. In this entry, the source prefix is the destination address of the BGP IPv6 unicast route, and the incoming interface is the outgoing interface in the matching IGP-type SAV route.

If multiple matching IGP-type SAV routes are available, the device generates one SAVNET allowlist entry for each matching SAV route.

Figure 10 Process of SAVNET allowlist entry generation

Restrictions and guidelines: SAVNET configuration

SAVNET can be deployed only on the public network and does not support VPN instances.

SAVNET does not support attachment circuits (ACs) in Layer 2 VPNs, including MPLS L2VPN, VPLS, and VXLAN.

Only Layer 3 Ethernet interfaces and their subinterfaces, Layer 3 aggregate interfaces and their subinterfaces, VLAN interfaces, and FlexE interfaces support this feature.

SAVNET tasks at a glance

To configure SAVNET, perform the following tasks:

1. Configuring BGP-based SAVNET

¡ Configuring BGP extensions for SAVNET

¡ Enabling SAVNET destination prefix probing

¡ (Optional.) Configuring SAVNET in access scenarios

¡ (Optional.) Enabling IS-IS SAVNET computation

2. Configuring IGP-based SAVNET

¡ Specifying the SAVNET interface type for an interface

¡ Enabling IS-IS SAVNET computation

3. (Optional.) Configuring BGP SAVNET performance optimization

¡ Configuring BGP SAVNET time parameters

¡ Configuring dropping of SAVNET-detected spoofed packets

4. (Optional.) Configuring the SAVNET denylist or allowlist feature

5. (Optional.) Enabling SAVNET logging

Specifying the SAVNET interface type for an interface

About this task

SAVNET devices support configuring the following types of interfaces:

· NNI—Used for connecting SAVNET neighbors. The SAVNET entries take effect only when you specify the interfaces connected between SAVNET neighbors as NNI interfaces.

· UNI—Used for connecting the user network. If the outgoing interface of an import route is a UNI interface configured by the ipv6 savnet port-type command, the SPA route generated based on that import route can be advertised to BGP IPv6 SAVNET peers.

Restrictions and guidelines

This feature is exclusive with the SAVA feature. For more information about SAVA, see "Configuring SAVA."

This feature is supported on only Layer 3 Ethernet interfaces, Layer 3 Ethernet subinterfaces, Layer 3 aggregate interfaces, Layer 3 aggregate subinterfaces, VLAN interfaces, and FlexE interfaces.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Specify the SAVNET interface type for an interface.

ipv6 savnet port-type { nni | uni }

By default, the SAVNET interface type is not specified for the interface.

Configuring BGP extensions for SAVNET

Restrictions and guidelines

BGP IPv6 SAVNET route information can be exchanged between only directly connected BGP IPv6 SAVNET peers. If a non-direct BGP IPv6 SAVNET session is created, no SAVNET entry can be generated correctly. Please use the IP address of the direct interface of the BGP IPv6 SAVNET peer to establish a BGP IPv6 SAVNET session.

This step involves details about BGP commands. For more information, see Layer 3—IP Routing Command Reference.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure SAVNET BGP peers or peer groups.

peer { group-name | ipv6-address [ prefix-length ] } as-number as-number

4. Create the BGP IPv6 SAVNET address family and enter its view.

address-family ipv6 savnet

5. Enable the device to exchange BGP IPv6 SAVNET routing information with a peer/peer group.

peer { group-name | ipv6-address [ prefix-length ] } enable

By default, the device cannot exchange BGP IPv6 SAVNET routing information with the specified peer/peer group.

6. Import route information from other routing protocols into the BGP IPv6 SAVNET routing table so that the SAVNET device can generate and advertise SPA route information.

import-route { isisv6 | ospfv3 | ripng } [ { process-id | all-processes } [ med med-value | route-policy route-policy-name ] * ]

import-route { bgp4+ ebgp | direct | static | unr } [ med med-value | route-policy route-policy-name ] *

By default, BGP does not import routing information from other protocols.

This step is required for only SAVNET devices that need to generate SPA routes and DPP routes.

7. Configure BGP IPv6 SAVNET route reflection.

a. Configure the device as a route reflector and specify a peer or peer group as a client.

peer { group-name | ipv6-address [ prefix-length ] } reflect-client

b. (Optional.) Enable route reflection between clients.

reflect between-clients

c. (Optional.) Configure the cluster ID for the route reflector.

reflector cluster-id { cluster-id | ipv4-address }

This step is required on SAVNET devices that need to only receive and forward SPA routes.

8. Return to system view.

quit

9. Enter interface view.

interface interface-type interface-number

10. Specify the SAVNET interface type as UNI.

ipv6 savnet port-type uni

By default, the SAVNET interface type is not specified for an interface.

An SPA route can be advertised to the BGP IPv6 SAVNET peer only if the outgoing interface to the next hop for the route is configured as a UNI.

11. (Optional.) Configure IPv6 interface PBR by applying an IPv6 policy to the UNI.

ipv6 policy-based-route policy-name [ share-mode ]

By default, no IPv6 policy is applied to the UNI.

With this command configured, the device can generate DPP routes based on the IPv6 policy.

Enabling SAVNET destination prefix probing

About this task

When SAVNET destination prefix probing is disabled, the device only forwards but cannot generate DPP routes. With this feature enabled, the device can generate DPP routes.

Restrictions and guidelines

This feature does not affect the agent DPP route feature. SAVNET devices can generate agent DPP routes even when SAVNET destination prefix probing is disabled.

As a best practice, configure the SAVNET entry aging time to be at least twice the DPP route sending interval configured on the route generating device. Otherwise, SAVNET entries might age out incorrectly because of long DPP route sending interval.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 SAVNET address family view.

address-family ipv6 savnet

4. Enable SAVNET destination prefix probing.

destination-probing enable

By default, SAVNET destination prefix probing is disabled.

Configuring SAVNET in access scenarios

About this task

You can configure this feature on access devices so that SAVNET entries can be generated without DPP routes.

Restrictions and guidelines

If you have configured the same access tag value for different interfaces, you must also configure the same access type for the interfaces.

Before configuring the access tag information for an interface, you must first specify the SAVNET interface type of that interface. Before using the ipv6 savnet port-type command to restore the SAVNET interface type setting of an interface, you must delete the access tag information from that interface.

If an SPA route carrying tag information is generated, it can be advertised directly. You do not need to configure the outgoing interface of the corresponding IP route as a UNI.

Procedure

1. Enter interface view.

interface interface-type interface-number

2. Configure an SAVNET access tag for the interface.

ipv6 savnet miig-tag tag-value { single-homed | complete-multi-homed }

3. Create a routing policy, and use the apply tag command to set an access tag to be carried in routes for the routing policy.

For more information about the configuration procedures, see policy-based routing configuration in Layer 3—IP Routing Configuration Guide.

4. Enter BGP instance view.

bgp as-number [ instance instance-name ]

5. Enter BGP IPv6 SAVNET address family view.

address-family ipv6 savnet

6. Import route information from other routing protocols into the BGP IPv6 SAVNET routing table so that the SAVNET device can generate and advertise SPA route information.

import-route { isisv6 | ospfv3 | ripng } { process-id | all-processes } route-policy route-policy-name

import-route { bgp4+ ebgp | direct | static | unr } route-policy route-policy-name

By default, BGP does not import routing information from other protocols.

For more information, see BGP configuration in Layer 3—IP Routing Configuration Guide.

Configuring inter-domain SAVNET

Prerequisites

Before configuring inter-domain SAVNET, you must complete the following tasks:

· Plan the DRs for the source AS and the validation AS and establish an EBGP IPv6 SAVNET session between the two DRs.

· Deploy intra-domain SAVNET in both the source AS and the validation AS.

Restrictions and guidelines

When configuring inter-domain SAVNET, follow these restrictions and guidelines:

· In both the source AS and the validation AS, use the peer designate-router command on all non-DR devices acting as ASBRs must to specify the DR device of their respective local ASs to properly advertise inter-domain DPP information to the DR or receive inter-domain SPA and DPP information forwarded by the DR.

· Execute the savnet validation-as command on all ASBRs in the source AS, including DR device.

· Only an IBGP peer or peer group can be designated as a DR. An EBGP peer or peer groups cannot be designated as a DR.

· After the peer designate-router command is executed, the session between the local device and the specified peer/peer group will be disconnected and then reestablished.

· The specified validation AS number must differ from the local AS number of the device.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 SAVNET address family view.

address-family ipv6 savnet

4. Specify the DR device.

peer { group-name | ipv6-address [ prefix-length ] } designate-router

By default, no DR device is specified.

5. Specify the validation AS numbers when the local AS acts as the source AS.

savnet validation-as { as-number&<1-8> }

By default, no validation AS number is configured when the local AS acts as the source AS.

Enabling IS-IS SAVNET computation

About this task

· High maintenance costs—ACL rules require manual maintenance, which is both tedious and error-prone.

· Risks posed by misconfiguration—Incorrect ACL configuration can block legitimate traffic or mistakenly permit malicious traffic to pass through.

IS-IS SAVNET provides an optimized SAVNET solution to resolve these issues. In this solution, the SAVNET module automatically generates and updates accurate SAVNET entries based on IS-IS routing information to validate IPv6 source prefixes.

Operating mechanism

After you enable IS-IS SAVNET on each device in an IS-IS routing domain, IS-IS SAVNET operates on each device as follows:

Each device computes IS-IS routes and generates route entries. Each entry contains one destination prefix and one or multiple outgoing interfaces, in {destination prefix x; outgoing interface 1, outgoing interface 2, ...} format.

The IS-IS module sends the generated route entries to the SAVNET module, in {destination prefix x; interface 1}, {destination prefix x; interface 2} format.

The SAVNET module generates SAVNET entries based on the received route entries, and then uses these entries to validate IPv6 packets.

Restrictions and guidelines

To have the IS-IS module generate and issue {destination prefix; outgoing interface} entries to the SAVNET module, you must perform the following steps:

1. Execute the savnet enable command on each device in the IS-IS routing domain.

2. Execute the isis ipv6 savnet enable command on each NNI SAVNET interface.

Enabling SAVNET computation on an IS-IS process

1. Enter system view.

system-view

2. Enter IS-IS view.

isis [ process-id ] [ vpn-instance vpn-instance-name ]

3. Enter IS-IS IPv6 address family view.

address-family ipv6 [ unicast ]

4. Enable SAVNET computation on the IS-IS process.

savnet enable

By default, SAVNET calculation is disabled on an IS-IS process.

Enabling SAVNET computation on an IPv6 IS-IS interface

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Set the SAVNET interface type to NNI.

ipv6 savnet port-type nni

By default, no SAVNET interface type is set on an interface.

For more information about this command, see SAVNET c ommands in Security Command Reference.

4. Enable SAVNET computation on the IPv6 IS-IS interface.

isis ipv6 savnet enable

By default, SAVNET computation is disabled on an IPv6 IS-IS interface.

Configuring BGP SAVNET performance optimization

Configuring BGP SAVNET time parameters

About this task

To adapt to different device performance and network environments, you can perform the following tasks on SAVNET devices:

· Use the destination-probing interval command to set the DPP route sending interval. With this command configured on a device, the device periodically sends DPP routes at the specified interval.

· Use the savnet-entry expire-time command to set the SAVNET entry aging time. This helps prevent traffic forwarding issues caused by retention of outdated SAVNET entries after the network topology changes. With this command configured, SAVNET entries generated through BGP have an aging time and can be maintained or updated through continuous reception of DPP routes. Entries that are not maintained or updated because no DPP routes are received before the aging timer expires will age out.

Restrictions and guidelines

If a large number of DPP routes need to be sent, do not set the sending interval of DPP routes too short. A too short sending interval might overwhelm BGP IPv6 SAVNET peers with DPP routes, causing them unable to process the received DPP routes timely.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 SAVNET address family view.

address-family ipv6 savnet

4. Set the DPP route sending interval.

destination-probing interval [ interval ]

By default, the DPP route sending interval is 3600 seconds.

5. Set the SAVNET entry aging time.

savnet-entry expire-time time

By default, the SAVNET entry aging time is 7200 seconds.

Configuring dropping of SAVNET-detected spoofed packets

About this task

SAVNET entries are generated based on routes in the BGP IPv6 SAVNET address family view. When a large number of BGP routes exist on a SAVNET device, the device takes a long time to complete creation of all SAVNET entries. Before SAVNET entry creation completes, some valid IPv6 packets might be incorrectly dropped because the corresponding SAVNET entries have not been generated.

To resolve this issue, you can use the undo ipv6 savnet packet-drop enable command to disable dropping of SAVNET-detected spoofed packets during the SAVNET entry generation period. Thus, the SAVNET device will not drop packets that have no matching SAVNET entries, reducing incorrect dropping of valid packets. When all SAVNET entries are created, you can use the ipv6 savnet packet-drop enable command to enable dropping of SAVNET-detected spoofed packets.

Procedure

1. Enter system view.

system-view

2. Disable dropping of SAVNET-detected spoofed packets.

ipv6 sava packet-drop enable

By default, dropping of SAVNET-detected spoofed packets is enabled.

Manually deploying SAVNET entries to the driver

About this task

A SAVNET device detects the forwarding path of IPv6 packets destined for a specified destination address by sending DPP information. The SAVNET devices along the path create SAVNET entries based on the DPP information. You can use this feature to manually deploy SAVNET entries to the driver.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Manually deploy SAVNET entries to the driver.

ipv6 savnet entry prefix ipv6-address prefix-length

By default, no manually deployed SAVNET entries exist in the driver.

Configuring the SAVNET denylist or allowlist feature

About this task

To generate SAVNET denylist or allowlist entries flexibly only for some of the IPv6 BGP routes, specify a routing policy when you configure the SAVNET denylist or allowlist feature.

· By default, all IPv6 BGP routes are available for generating SAVNET allowlist entries. To generate SAVNET allowlist entries flexibly only for some of the IPv6 BGP routes, specify a routing policy by executing the savnet allowlist route-policy command. The device will generate SAVNET allowlist entries only for BGP IPv6 unicast routes that do not match the routing policy. If an IPv6 BGP route matches the routing policy, the device does not use it to generate a SAVNET allowlist entry.

· By default, all IPv6 BGP routes are available for generating SAVNET denylist entries. To generate SAVNET denylist entries flexibly only for some of the IPv6 BGP routes, specify a routing policy by executing the savnet denylist route-policy command. The device will generate SAVNET denylist entries only for IPv6 BGP unicast routes that match the routing policy.

Restrictions and guidelines

The denylist feature is applicable to IGP-based intra-domain SAVNET and BGP-based SAVNET. The allowlist feature is applicable only to IGP-based intra-domain SAVNET.

You can configure an interface as source prefix producers or as a consumer for generation of SAVNET denylist entries, but not both.

Before you configure an interface as a consumer or producer, you must Configuration set its interface type to NNI.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv6 unicast address family view.

address-family ipv6 [ unicast ]

4. Enable the SAVNET denylist or allowlist.

¡ Enable the SAVNET denylist.

savnet denylist enable

¡ Enable the SAVNET allowlist.

savnet allowlist enable

By default, the SAVNET denylist and allowlist are disabled.

5. (Optional.) Specify a routing policy to control generation of SAVNET denylist or allowlist entries.

¡ Specify a routing policy to control generation of SAVNET denylist entries.

savnet denylist route-policy route-policy-name

¡ Specify a routing policy to control generation of SAVNET allowlist entries.

savnet allowlist route-policy route-policy-name

By default, no routing policy is specified to control generation of SAVNET denylist or allowlist entries.

6. Return to system view.

quit

7. (Optional.) Configure interfaces for generation of SAVNET denylist entries.

a. Enter interface view.

interface interface-type interface-number

b. Specify the interface as an NNI SAVNET interface.

ipv6 savnet port-type nni

By default, no SAVNET interface type is set on an interface.

c. Configure the interface with a role for generation of SAVNET denylist entries.

ipv6 savnet deny { consumer consumer-name | productor productor-name }

By default, no interfaces are specified for generation of SAVNET denylist entries.

This step is required for generation of SAVNET denylist entries. If you are configuring the SAVNET allowlist, skip this step.

Enabling SAVNET logging

About this task

To identify and troubleshoot issues, enable SAVNET logging.

This feature enables the device to generate log messages when spoofed packets are detected by SAVNET. The log messages are sent to the information center and output according to the configured log destinations and output rules. For more information about the information center, see Network Management and Monitoring Configuration Guide.

When the device outputs a large amount of SAVNET detection log messages, it will reduce device performance and affect log viewing and troubleshooting. You can perform the following tasks as needed:

· Disable SAVNET logging.

· Increase the SAVNET log output interval to reduce the output frequency.

· Decrease the number of log messages that can be output in each interval. The exceeding log messages will not be displayed.

Procedure

1. Enter system view.

system-view

2. Enable SAVNET logging.

ipv6 savnet log enable spoofing-packet [ interval interval | number number ] *

By default, SAVNET logging is disabled.

Display and maintenance commands for SAVNET

Execute the display commands in any view.

Task	Command
Display SAVNET entries.	In standalone mode:‌ display ipv6 savnet entry [ [ interface interface-type interface-number ] [ slot slot-number ] \| vpn-instance vpn-instance-name ] In IRF mode: display ipv6 savnet entry [ [ interface interface-type interface-number ] [ chassis chassis-number slot slot-number ] \| vpn-instance vpn-instance-name ]
Display SAVNET packet drop statistics.	display ipv6 savnet packet-drop statistics [ interface interface-type interface-number ]
Display information about peers or peer groups for the BGP IPv6 SAVNET address family.	display bgp [ instance instance-name ] peer ipv6 savnet [ ipv6-address prefix-length \| { ipv6-address \| group-name group-name } log-info \| [ ipv6-address ] verbose ]
Display information about BGP IPv6 SAVNET peer groups.	display bgp [ instance instance-name ] group ipv6 savnet [ group-name group-name ]
Display update group information for the BGP IPv6 SAVNET address family.	display bgp [ instance instance-name ] update-group ipv6 savnet [ ipv6-address ]
Display BGP IPv6 SAVNET SPA route information.	display bgp [ instance instance-name ] ipv6 savnet spa [ peer ipv6-address { advertised-routes \| received-routes } [ { savnet-route route-length \| savnet-prefix } [ verbose ] \| statistics ] \| route-distinguisher route-distinguisher [ savnet-route route-length \| savnet-prefix ] \| { savnet-route route-length \| savnet-prefix } [ advertise-info ] \| statistics ] display bgp [ instance instance-name ] ipv6 savnet spa [ route-distinguisher route-distinguisher ] time-range min-time max-time
Display BGP IPv6 SAVNET DPP route information.	display bgp [ instance instance-name ] ipv6 savnet dpp [ [ route-distinguisher route-distinguisher ] [ savnet-route route-length \| savnet-prefix ] \| statistics ] display bgp [ instance instance-name ] ipv6 savnet dpp [ route-distinguisher route-distinguisher ] time-range min-time max-time
Display destination prefix information that can generate DPP routes.	display bgp [ instance instance-name ] ipv6 savnet prefix [ ipv6-address prefix-length ] display bgp [ instance instance-name ] ipv6 savnet prefix time-range min-time max-time
Display the ingress neighbor AS information for inter-domain SAVNET.	display bgp [ instance instance-name ] ipv6 savnet ingress-neighbor-as [ validation-as as-number ]
Display SAVNET entry information generated based on BGP notifications to the SAVNET module.	display bgp [ instance instance-name ] ipv6 savnet sav
Display route entry information sent by IS-IS to SAVNET.	display isis [ process-id ] savnet sav-table ipv6 [ ipv6-address [ prefix-length ] ] [ interface-type interface-number ]
Clear SAVNET packet drop statistics.	reset ipv6 savnet packet-drop statistics [ interface interface-type interface-number ]
Soft-reset BGP sessions for the BGP IPv6 SAVNET address family.	refresh bgp [ instance instance-name ] { ipv6-address [ prefix-length ] \| all \| external \| group group-name \| internal } { export \| import } ipv6 savnet
Reset BGP sessions for the IPv6 SAVNET address family.	reset bgp [ instance instance-name ] ipv6-address [ prefix-length ] ipv6 savnet

‌

SAVNET configuration examples‌

Example: Configuring SAVNET basic network

Network configuration

As shown in Figure 11, valid users in the LAN use prefix 10::/64. Configure SAVNET on Device A and Device B to meet the following requirements:

· Device A and Device B establish a SAVNET neighbor relationship, and exchange SPA and DPP routes through BGP. Device B creates a SAVNET entry.

· Device B performs source address validity check on the packets received from Device A based on the SAVNET entry, and receives or forwards the packets matching corresponding entry as configured.

Figure 11 Network diagram

‌

Prerequisites

1. Assign IPv6 addresses to interfaces on the devices.

2. Configure the backbone network as an OSPFv3 area, and advertise the IPv6 address of each interface on Device A and Device B in the OSPFv3 area. For more information, see OSPFv3 configuration in Layer 3—IP Routing Configuration Guide.

Procedure

1. Configure Device A:

# Specify Ten-GigabitEthernet 0/0/15 as a UNI and Ten-GigabitEthernet 0/0/16 as an NNI.

<DeviceA> system-view

[DeviceA] interface ten-gigabitethernet 0/0/15

[DeviceA-Ten-GigabitEthernet0/0/15] ipv6 savnet port-type uni

[DeviceA-Ten-GigabitEthernet0/0/15] ipv6 savnet entry prefix 10:: 64

[DeviceA-Ten-GigabitEthernet0/0/15] quit

[DeviceA] interface ten-gigabitethernet 0/0/16

[DeviceA-Ten-GigabitEthernet0/0/16] ipv6 savnet port-type nni

[DeviceA-Ten-GigabitEthernet0/0/16] quit

# Configure BGP.

[DeviceA] bgp 100

[DeviceA-bgp-defult] router-id 1.1.1.1

[DeviceA-bgp-defult] peer 20::2 as 100

[DeviceA-bgp-defult] address-family ipv6 savnet

[DeviceA-bgp-defult-savnet-ipv6] destination-probing enable

[DeviceA-bgp-defult-savnet-ipv6] peer 20::2 enable

[DeviceA-bgp-defult-savnet-ipv6] import-route direct

[DeviceA-bgp-defult-savnet-ipv6] quit

[DeviceA-bgp-defult] quit

2. Configure Device B:

# Specify the SAVNET interface type.

<DeviceB> system-view

[DeviceB] interface ten-gigabitethernet 0/0/15

[DeviceB-Ten-GigabitEthernet0/0/15] ipv6 savnet port-type nni

# Configure BGP.

[DeviceB] bgp 100

[DeviceB-bgp-defult] router-id 2.2.2.2

[DeviceB-bgp-defult] peer 20::1 as 100

[DeviceB-bgp-defult] address-family ipv6 savnet

[DeviceB-bgp-defult-savnet-ipv6] peer 20::1 enable

[DeviceB-bgp-defult-savnet-ipv6] quit

[DeviceB-bgp-defult] quit

Verifying the configuration

# View brief information about received SPA routes on Device B.

[DeviceB] display bgp ipv6 savnet spa

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of SAVNET routes: 1

Total number of routes from all peers: 1

Route distinguisher: 1.1.1.1:0

Total number of routes: 1

* >i Network : [1][1][1.1.1.1][64][10::]/120

NextHop : :: LocPrf : 100

MIIG-Tag: 0 MIIG-Type : 0

MED : 0

Path/Ogn: ?

# View detailed information about received SPA routes on Device B.

<DeviceB> display bgp ipv6 savnet spa [1][1][1.1.1.1][64][10::]/120

BGP local router ID: 2.2.2.2

Local AS number: 100

Route distinguisher: 1.1.1.1:0

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of [1][1][1.1.1.1][64][10::]/120:

From : 20::1 (1.1.1.1)

Rely nexthop : ::

Original nexthop: ::

Route age : 05h04m52s

OutLabel : NULL

RxPathID : 0x0

TxPathID : 0x0

AS-path : (null)

Origin : incomplete

Attribute value : MED 0, localpref 100, pref-val 0

State : valid, internal, best

Source type : local

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

Route type : SAVNET SPA

Origin routerID : 1.1.1.1

MIIG-Tag : 0

MIIG-Type : 0

MIIG-Flags : 0

The output shows that Device B has received an SPA route from Device A and recorded the mapping between source prefix 10::/64 and origin router ID 1.1.1.1.

# View brief information about received DPP routes on Device B.

<DeviceB> display bgp ipv6 savnet dpp

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of SAVNET routes: 1

Total number of routes from all peers: 1

Route distinguisher: 1.1.1.1:0

Total number of routes: 1

* >i Network : [2][2][1][1.1.1.1][64][30::]/120

NextHop : 0.0.0.0 LocPrf : 100

MED : 0

Path/Ogn: i

# View detailed information about received DPP routes on Device B.

<DeviceB> display bgp ipv6 savnet dpp [2][2][1][1.1.1.1][64][30::]/120

BGP local router ID: 2.2.2.2

Local AS number: 100

Route distinguisher: 1.1.1.1:0

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of [2][2][1][1.1.1.1][64][30::]/120:

From : 20::1 (1.1.1.1)

Rely nexthop : ::1

Original nexthop: 0.0.0.0

Out interface : NULL0

Route age : 00h01m07s

OutLabel : NULL

RxPathID : 0x0

TxPathID : 0xffffffff

AS-path : (null)

Origin : igp

Attribute value : MED 0, localpref 100, pref-val 32768

State : valid, internal, best

Source type : local

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

Route type : SAVNET DPP

Origin routerID : 1.1.1.1

Sequence num : 160

IfIndexIn : 258

In interface : Ten-GigabitEthernet0/0/15

Path RID list : 1.1.1.1

Agent RID list : (null)

The output shows that Device B has received a DPP route from Device A, and the origin router ID carried in the route is the same as the locally recorded one corresponding to source prefix 10::/64.

# View SAVNET entries generated based on BGP notifications to the SAVNET module on Device B.

<DeviceB> display bgp ipv6 savnet sav

Total number of routes: 1

BGP local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

* >i Network : 10:: PrefixLen : 64

In-Intf : Ten-GigabitEthernet0/0/15

# Verify the correctness of the SAVNET entry information on Device B.

<DeviceB> display ipv6 savnet entry

IPv6 savnet entry count: 1

Destination/Prefix length Type Interface VPN instance

10::/64 BGP XGE0/0/15 --

The output shows that Device B has learned and generated the SAVNET entry corresponding to the local source prefix of Device A. When Device B receives a user network packet from Device A, it can perform packet source address validity check based on the SAVNET entry.

12-Security Configuration Guide

Configuring SAVNET

Background

Operating mechanism

SAVNET access scenarios

Introduction

Operating mechanism

Example

Denylist entry generation mechanism

About this task

Restrictions and guidelines

Procedure

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Prerequisites

Restrictions and guidelines

Procedure

About this task

Operating mechanism

Restrictions and guidelines

Enabling SAVNET computation on an IS-IS process

Enabling SAVNET computation on an IPv6 IS-IS interface

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

Display and maintenance commands for SAVNET

SAVNET configuration examples‌

Network configuration

Prerequisites

Procedure

Verifying the configuration

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us