Source Address Validation in Intra-domain Networks and Inter-domain Networks (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 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, 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

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

1. Generate 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.

2. Advertise SPA routes: Only the following types of routes can be advertised to the BGP IPv6 SAVNET peer:

¡ The outgoing interface of the corresponding IP route of 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 by using the 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 received IPv6 packets on the user-side interface. 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. The BGP IPv6 SAVNET session is established. 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 interafce Interface 1.

Restrictions and guidelines: SAVNET configuration

This feature is available only for the following cards:

Card category	Cards
CEPC	CEPC-XP4LX, CEPC-XP24LX, CEPC-XP48RX, CEPC-CP4RX, CEPC-CP4RXA, CEPC-CP4RX-L, CEPC-CQ8L, CEPC-CQ8LA, CEPC-CQ8L1A, CEPC-CQ8L3A, CEPC-CQ16L1, CEPC-DQ2L1-G
CSPEX	CSPEX-1304X, CSPEX-1404X, CSPEX-1502X, CSPEX-1504X, CSPEX-1504XA, CSPEX-1602X, CSPEX-1602XA, CSPEX-1804X, CSPEX-1512X, CSPEX-1612X, CSPEX-1812X, CSPEX-1502XA, CSPEX-1802X, CSPEX-1802XA, CSPEX-1812X-E, CSPEX-2304X-G, CSPEX-2304X-LG, CSPEX-2612XA, CSPEX-2612X3A
SPE	RX-SPE200, RX-SPE200-E

‌

SAVNET tasks at a glance

To configure SAVNET, perform the following tasks:

1. Configuring BGP extensions for SAVNET

2. Enabling SAVNET destination prefix probing

3. Specifying the SAVNET interface type for an interface

4. (Optional.) Configuring BGP SAVNET performance optimization

¡ Configuring BGP SAVNET time parameters

¡ Configuring dropping of SAVNET-detected spoofed packets

¡ Manually deploying SAVNET entries

5. Configuring SAVNET in access scenarios

6. (Optional.) Enabling SAVNET logging

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.

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 the UNI interface specified by the ipv6 savnet port-type command, the SPA route generated based on the import route can be advertised to the BGP IPv6 SAVNET peer.

Restrictions and guidelines

After you specify the SAVNET interface type for an interface, do not enable SAVA on the interface. 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 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

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.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Manually deploy SAVNET entries.

ipv6 savnet entry prefix ipv6-address prefix-length

By default, no manually deployed SAVNET entries exist.

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, delete the access tag information configured for 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.

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 SAVNET entry information generated based on BGP notifications to the SAVNET module.	display bgp [ instance instance-name ] ipv6 savnet sav
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 5, 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 5 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 3/1/1 as a UNI and Ten-GigabitEthernet 3/1/2 as an NNI.

<DeviceA> system-view

[DeviceA] interface ten-gigabitethernet 3/1/1

[DeviceA-Ten-GigabitEthernet3/1/1] ipv6 savnet port-type uni

[DeviceA-Ten-GigabitEthernet3/1/1] quit

[DeviceA] interface ten-gigabitethernet 3/1/2

[DeviceA-Ten-GigabitEthernet3/1/2] ipv6 savnet port-type nni

[DeviceA-Ten-GigabitEthernet3/1/2] 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 3/1/1

[DeviceB-Ten-GigabitEthernet3/1/1] 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-GigabitEthernet3/1/1

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-GigabitEthernet3/1/1

# 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 XGE3/1/1 --

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.

13-Security Configuration Guide

Configuring SAVNET

SPA routes

DPP routes

Establishing BGP neighbors to create a SAVNET network

Advertising SPA routes between BGP IPv6 SAVNET peers

Transmitting DPP routes

Creating SAVNET entries

Verifying the received IPv6 packet based on the SAVNET entries

Transmission process analysis

Background

Operating mechanism

SAVNET access scenarios

Introduction

Operating mechanism

Example

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Specifying the SAVNET interface type for an interface

About this task

Restrictions and guidelines

Procedure

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

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