en-US
search-icon

SonicOS 5.9 Admin Guide

Appendices

CLI Guide

Command Line Interface

This appendix contains a categorized listing of Command Line Interface (CLI) commands for SonicOS firmware. Each command is described, and where appropriate, an example of usage is included.

For a listing of Command Line Interface (CLI) commands for SonicOS 5.9 firmware, refer to the SonicOS 5.9 Enterprise Command Line Interface Reference Guide, which is available online under Product Documentation > Network Security on the SonicWall Support page:

http://www.SonicWALL.com/us/en/support.html

The SonicOS 5.9 Enterprise Command Line Interface Reference Guide PDF is also available directly at:

http://www.SonicWALL.com/app/projects/file_downloader/document_lib.php?t=PG&id=592

Topics:
* 
NOTE: The complete SonicWALL CLI Command Reference is included in the SonicOS online help. To access the Command Reference, click the Help button from the SonicOS GUI, and then navigate to Appendices > CLI Guide.

Input Data Format Specification

The table below describes the data formats acceptable for most commands. H represents one or more hexadecimal digit (0-9 and A-F). D represents one or more decimal digit.

 

Input Data Formats

Data

Data Format

MAC Address

HH:HH:HH:HH:HH:HH

MAC Address

HHHH.HHHH.HHHH

IP Address

D.D.D.D

IP Address

0xHHHHHHHH

Integer Values

D

Integer Values

0xH

Integer Range

D-D

Text Conventions

Bold text indicates a command executed by interacting with the user interface.

Courier text indicates commands and text entered using the CLI.

Italic text indicates the first occurrence of a new term, as well as a book title, and also emphasized text. In this command summary, items presented in italics represent user-specified information.

Items within angle brackets (“< >”) are required information.

Items within square brackets (“[ ]”) are optional information.

Items separated by a “pipe” (“|”) are options. You can select any of them.

* 
NOTE: Though a command string may be displayed on multiple lines in this guide, it must be entered on a single line with no carriage returns except at the end of the complete command.

Editing and Completion Features

You can use individual keys and control-key combinations to assist you with the CLI. The table below describes the key and control-key combination functions.

 

Key Reference

Key(s)

Function

Tab

Completes the current word

?

Displays possible command completions

CTRL+A

Moves cursor to the beginning of the command line

CTRL+B

Moves cursor to the previous character

CTRL+C

Exits the Quick Start Wizard at any time

CTRL+E

Moves cursor to the end of the command line

CTRL+F

Moves cursor to the next character

CTRL+K

Erases characters from the cursor to the end of the line

CTRL+N

Displays the next command in the command history

CTRL+P

Displays the previous command in the command history

CTRL+W

Erases the previous word

Left Arrow

Moves cursor to the previous character

Right Arrow

Moves the cursor to the next character

Up Arrow

Displays the previous command in the command history

Down Arrow

Displays the next command in the command history

Most configuration commands require completing all fields in the command. For commands with several possible completing commands, the Tab or ? key display all options.

myDevice> show [TAB]

 
 

alerts

interface

network

tech-support

arp

log

processes

tsr

content-filter

memory

route

web-management

cpu

messages

security-services

zone

device

nat

status

zones

gms

netstat

system

 

The Tab key can also be used to finish a command if the command is uniquely identified by user input.

myDevice> show al [TAB]

displays

myDevice> show alerts

Additionally, commands can be abbreviated as long as the partial commands are unique. The following text:

myDevice> sho int inf

is an acceptable abbreviation for

myDevice> show interface info

Command Hierarchy

The CLI configuration manager allows you to control hardware and firmware of the appliance through a discreet mode and submode system. The commands for the appliance fit into the logical hierarchy shown below.

To configure items in a submode, activate the submode by entering a command in the mode above it.

For example, to set the default LAN interface speed or duplex, you must first enter configure, then interface x0 lan. To return to the higher Configuration mode, simply enter end or finished.

Configuration Security

SonicWALL Internet Security appliances allow easy, flexible configuration without compromising the security of their configuration or your network.

Passwords

The SonicWALL CLI currently uses the administrator’s password to obtain access. SonicWALL devices are shipped with a default password of password. Setting passwords is important in order to access the SonicWALL and configure it over a network.

Factory Reset to Defaults

If you are unable to connect to your device over the network, you can use the command restore to reset the device to factory defaults during a serial configuration session.

Management Methods for the SonicWALL Network Security Appliance

You can configure the SonicWALL appliance using one of three methods:

Using a serial connection and the configuration manager
An IP address assignment is not necessary for appliance management.
A device must be managed while physically connected via a serial cable.
Web browser-based User Interface
In IP address must have been assigned to the appliance for management or use the default of 192.168.168.168.

Initiating a Management Session using the CLI

Topics:

Serial Management and IP Address Assignment

Follow the steps below to initiate a management session via a serial connection and set an IP address for the device.

* 
NOTE: The default terminal settings on the SonicWALL and modules is 80 columns by 25 lines. To ensure the best display and reduce the chance of graphic anomalies, use the same settings with the serial terminal software. The device terminal settings can be changed, if necessary. Use the standard ANSI setting on the serial terminal software.
1
Attach the included null modem cable to the appliance port marked CONSOLE. Attach the other end of the null modem cable to a serial port on the configuring computer.
2
Launch any terminal emulation application that communicates with the serial port connected to the appliance. Use these settings:
115,200 baud
8 data bits
no parity
1 stop bit
no flow control
3
Press Enter/Return. Initial information is displayed followed by a DEVICE NAME> prompt.

Initiating an SSH Management Session via Ethernet

* 
NOTE: This option works for customers administering a device that does not have a cable for console access to the CLI.

Follow the steps below to initiate an SSH management session through an Ethernet connection from a client to the appliance.

1
Attach an Ethernet cable to the interface port marked XO. Attach the other end of the Ethernet cable to an Ethernet port on the configuring computer.
2
Launch any terminal emulation application (such as PuTTY) that communicates via the Ethernet interface connected to the appliance.
3
Within the emulation application, enter the IP destination address for the appliance and enter 22 as the port number.
4
Select SSH as the connection type and open a connection.

Logging in to the SonicOS CLI

When the connection is established, log in to the security appliance:

1
At the User prompt enter the Admin’s username. Only the admin user will be able to login from the CLI. The default Admin username is admin. The default can be changed.
2
At the Password prompt, enter the Admin’s password. If an invalid or mismatched username or password is entered, the CLI prompt will return to User:, and a “CLI administrator login denied due to bad credentials” error message will be logged. There is no lockout facility on the CLI.

Configuring Site-to-Site VPN Using CLI

This section describes how to create a VPN policy using the Command Line Interface. You can configure all of the parameters using the CLI, and enable the VPN without using the Web management interface.

* 
NOTE: In this example, the VPN policy on the other end has already been created.
Topics:

CLI Access

1
Use a DB9 to RJ45 connector to connect the serial port of your PC to the console port of your firewall.
2
Using a terminal emulator program, such as TerraTerm, use the following parameters:
115,200 baud
8 bits
No parity
1 stop bit
No flow control
3
You may need to hit return two to three times to get to a command prompt, which will look similar to the following:

TZ200>

If you have used any other CLI, such as Unix shell or Cisco IOS, this process should be relatively easy and similar. It has auto-complete so you do not have to type in the entire command.

4
When a you need to make a configuration change, you should be in configure mode. To enter configure mode, type configure.

TZ200 > configure

(config[TZ200])>

The command prompt changes and adds the word config to distinguish it from the normal mode. Now you can configure all the settings, enable and disable the VPNs, and configure the firewall.

Configuration

In this example, a site-to-site VPN is configured between two TZ 200 appliance, with the following settings:

Local TZ 200 (home):
WAN IP: 10.50.31.150
LAN subnet: 192.168.61.0
Mask 255.255.255.0

Remote TZ 200 (office):
WAN IP: 10.50.31.104
LAN subnet: 192.168.15.0
Mask: 255.255.255.0

Authentication Method: IKE using a Pre-Shared Key
Phase 1 Exchange: Main Mode
Phase 1 Encryption: 3DES
Phase 1 Authentication SHA1
Phase 1 DH group: 2
Phase 1 Lifetime: 28800
Phase 2 Protocol: ESP
Phase 2 Encryption: 3DES
Phase 2 Authentication: SHA1
Phase 2 Lifetime: 28800
No PFS

1
In configure mode, create an address object for the remote network, specifying the name, zone assignment, type, and address. In this example, we use the name OfficeLAN:

(config[TZ200]> address-object Office LAN
(config-address-object[OfficeLAN])>

* 
NOTE: The prompt has changed to indicate the configuration mode for the address object.

(config-address-object[OfficeLAN])> zone VPN
(config-address-object[OfficeLAN])> network 192.168.15.0 255.255.255.0
(config-address-object[OfficeLAN])> finished

2
To display the address object, type the command show address-object [name]:

TZ200 > show address-object OfficeLAN

The output will be similar to the following:

address-object OfficeLAN
network 192.168.15.0 255.255.255.0
zone VPN

3
To create the VPN policy, type the command vpn policy [name] [authentication method]:

(config[TZ200])> vpn policy OfficeVPN pre-shared
(config-vpn[OfficeVPN])>

* 
NOTE: The prompt has changed to indicate the configuration mode for the VPN policy. All the settings regarding this VPN will be entered here.
4
Configure the Pre-Shared Key. In this example, the Pre-Shared Key is SonicWALL:

(config-vpn[OfficeVPN])> pre-shared-secret SonicWALL

5
Configure the IPsec gateway:

(config-vpn[OfficeVPN])> gw ip-address 10.50.31.104

6
Define the local and the remote networks:

(config-vpn[OfficeVPN])> network local address-object "LAN Primary Subnet"
(config-vpn[OfficeVPN])> network remote address-object "OfficeLAN"

7
Configure the IKE and IPsec proposals:

(config-vpn[OfficeVPN])> proposal ike main encr triple-des auth sha1 dh 2 lifetime 28800
(config-vpn[OfficeVPN])> proposal ipsec esp encr triple-des auth sha1 dh no lifetime 28800

8
In the Advanced tab in the UI configuration, enable keepalive on the VPN policy:

(config-vpn[OfficeVPN])> advanced keepalive

9
To enable the VPN policy, use the command vpn enable “name” :

(config[TZ200])> vpn enable "OfficeVPN"

10
Use the finished command to save the VPN policy and exit from the VPN configure mode:

(config-vpn[OfficeVPN])> finished
(config[TZ200])>

The configuration is complete.

* 
NOTE: The command prompt goes back to the configure mode prompt.

Viewing VPN Configuration

Use the following steps to configure the VPN policies.

1
To view a list of all the configured VPN policies, type the command show vpn policy. The output will be similar to the following:

(config[TZ200])> show vpn policy

Policy: WAN GroupVPN (Disabled)
Key Mode: Pre-shared
Pre Shared Secret: DE65AD2228EED75A

Proposals:
IKE: Aggressive Mode, 3DES SHA, DH Group 2, 28800 seconds
IPSEC: ESP, 3DES SHA, No PFS, 28800 seconds

Advanced:
Allow NetBIOS OFF, Allow Multicast OFF
Management: HTTP OFF, HTTPS OFF
Lan Default GW: 0.0.0.0
Require XAUTH: ON, User Group: Trusted Users

Client:
Cache XAUTH Settings: Never
Virtual Adapter Settings: None
Allow Connections To: Split Tunnels
Set Default Route OFF, Apply VPN Access Control List OFF
Require GSC OFF
Use Default Key OFF

Policy: OfficeVPN (Enabled)
Key Mode: Pre-shared
Primary GW: 10.50.31.104
Secondary GW: 0.0.0.0
Pre Shared Secret: SonicWALL

IKE ID:
Local: IP Address
Peer: IP Address

Network:
Local: LAN Primary Subnet
Remote: OfficeLAN

Proposals:
IKE: Main Mode, 3DES SHA, DH Group 2, 28800 seconds
IPSEC: ESP, 3DES SHA, No PFS, 28800 seconds

Advanced:
Keepalive ON, Add Auto-Rule ON, Allow NetBIOS OFF
Allow Multicast OFF
Management: HTTP ON, HTTPS ON
User Login: HTTP ON, HTTPS ON
Lan Default GW: 0.0.0.0
Require XAUTH: OFF
Bound To: Zone WAN

2
To view the configuration for a specific policy, specify the policy name in double quotes. For example:

(config[TZ200])> show vpn policy "OfficeVPN"

The output will be similar to the following:

Policy: OfficeVPN (Enabled)
Key Mode: Pre-shared
Primary GW: 10.50.31.104
Secondary GW: 0.0.0.0
Pre Shared Secret: SonicWALL

IKE ID:
Local: IP Address
Peer: IP Address

Network:
Local: LAN Primary Subnet
Remote: OfficeLAN

Proposals:
IKE: Main Mode, 3DES SHA, DH Group 2, 28800 seconds
IPSEC: ESP, 3DES SHA, No PFS, 28800 seconds

Advanced:
Keepalive ON, Add Auto-Rule ON, Allow NetBIOS OFF
Allow Multicast OFF
Management: HTTP ON, HTTPS ON
User Login: HTTP ON, HTTPS ON
Lan Default GW: 0.0.0.0
Require XAUTH: OFF
Bound To: Zone WAN

3
3. Type the command show vpn sa “name” to see the active SA:

(config[TZ200])> show vpn sa "OfficeVPN"

Policy: OfficeVPN
IKE SAs

GW: 10.50.31.150:500 --> 10.50.31.104:500
Main Mode, 3DES SHA, DH Group 2, Responder
Cookie: 0x0ac298b6328a670b (I), 0x28d5eec544c63690 (R)
Lifetime: 28800 seconds (28783 seconds remaining)

IPsec SAs

GW: 10.50.31.150:500 --> 10.50.31.104:500
(192.168.61.0 - 192.168.61.255) --> (192.168.15.0 - 192.168.15.255)
ESP, 3DES SHA, In SPI 0xed63174f, Out SPI 0x5092a0b2
Lifetime: 28800 seconds (28783 seconds remaining)

BGP Advanced Routing

About BGP Advanced Routing

This appendix provides an overview of SonicWALL’s implementation of Border Gateway protocol (BGP), how BGP operates, and how to configure BGP for your network.

BGP Overview

Topics:

What is BGP?

BGP is a large-scale routing protocol used to communicate routing information between Autonomous Systems (ASs), which are well-defined, separately administered network domains. BGP support allows for SonicWALL security appliances to replace a traditional BGP router on the edge of a network's AS. The current SonicWALL implementation of BGP is most appropriate for "single-provider / single-homed" environments, where the network uses one ISP as their Internet provider and has a single connection to that provider. SonicWALL BGP is also capable of supporting "single-provider / multi-homed" environments, where the network uses a single ISP but has a small number of separate routes to the provider. BGP is enabled on the Network > Routing page of the SonicOS GUI and then it is fully configured through the SonicOS Command Line Interface (CLI).

Background Information

Routing protocols are not just packets transmitted over a network, but comprise all the mechanisms by which individual routers, and groups of routers, discover, organize, and communicate network topologies. Routing protocols use distributed algorithms that depend on each participant following the protocol as it is specified, and are most useful when routes within a network domain dynamically change as links between network nodes change state.

Routing protocols typically interact with two databases:

Routing Information Base (RIB) - Used to store all the route information required by the routing protocols themselves.
Forward Information Base (FIB) - Used for actual packet forwarding.

The best routes chosen from the RIB are used to populate the FIB. Both the RIB and FIB change dynamically as routing updates are received by each routing protocol, or connectivity on the device changes.

There are two basic classes of routing protocols:

Interior Gateway Protocols (IGPs) - Interior Gateway Protocols are routing protocols designed to communicate routes within the networks that exist inside of an AS. There are two generations of IGPs. The first generation consists of distance-vector protocols. The second generation consists of link-state protocols. The distance-vector protocols are relatively simple, but have issues when scaled to a large number of routers. The link-state protocols are more complex, but have better scaling capability. The existing distance-vector protocols are Interior Gateway Routing Protocol (IGRP), Enhanced Interior Gateway Routing Protocol (EIGRP), Routing Information Protocol (RIP), and RIPv2, an enhanced version of RIP. IGRP and EIGRP are proprietary Cisco protocols. The link-state protocols currently in use are Open Shortest Path First (OSPF) and the little-used Intermediate System to Intermediate System (IS-IS) protocol.

SonicOS supports OSPFv2 and RIPv1/v2 protocols, the two most common routing Interior Gateway Protocols, allowing our customers to use our products in their IGP networks and avoid the additional cost of a separate traditional router.

Exterior Gateway Protocols (EGPs) - The standard, ubiquitous Exterior Gateway Protocol is BGP (BGP4, to be exact). BGP is large-scale routing protocol that communicates routing information and policy between well-defined network domains called Autonomous Systems (ASs). An Autonomous System is a separately administered network domain, independent of other Autonomous Systems. BGP is used to convey routes and route policy between Autonomous Systems. ISPs commonly use BGP to convey routes and route policy with their customers as well as with other ISPs.

Each Autonomous System has a 16-bit number assigned. Like IP addresses, an AS number may be public or private. Public AS numbers are a limited resource and are provisioned based on a number of factors. ISP customers with large networks multi-homed to two or more ISPs usually have a public AS, whereas smaller customers will be given a private AS administered by their ISP provider.

As our products evolve in support of enterprise-level requirements, some customers may want to place our products on the edge of their AS in place of a traditional BGP router. To support these topologies, BGP has been added.

* 
NOTE: SonicOS supports BGP4+, or IPv6 support in BGP4 (RFC 2545), on platforms that support BGP.

Autonomous Systems

Each Autonomous System has a 16-bit number assigned. Like IP addresses, an AS number may be public or private. Public AS numbers are a limited resource and are provisioned based on a number of factors. ISP customers with large networks multi-homed to two or more ISPs usually have a public AS, whereas smaller customers will be given a private AS administered by their ISP provider.

Types of BGP Topologies

BGP is a very flexible and complex routing protocol. As such, BGP routers may be placed in a large variety of topology settings, such as Internet core routers, intermediary ISP routers, ISP Customer Premises Equipment (CPE), or routers in small private BGP networks. The number of BGP routes required for different topologies varies from greater than 300,000 for core routers, to 0 for ISP customers that use a single ISP and use default routing for all destinations outside of their AS. ISP customers are often required to run BGP from their edge router (the CPE) to the ISP regardless of the number of routes they receive from the ISP. This allows ISP customers to control which networks to advertise to the outside world. There's always the fear that a customer will advertise a network, or network aggregate, not owned by the customer, black-holing Internet traffic to those networks. In reality, ISP providers are careful to filter invalid advertisements from their customers (one of BGP's strengths), so this rarely happens.

There are three basic scales of BGP networks:

Single-Provider / single-Homed - The network receives a single route (single-homed) from a single ISP (single-provider). The number of routes an ISP customer receives from its ISP depends on the nature of its AS. An ISP customer that uses only one ISP as their Internet provider, and has a single connection to that provider (single-provider / single-homed) has no need to receive any routes - all traffic destined outside of the AS will go to their ISP. These customers may still advertise some or all of their inside network to the ISP.
Single-Provider / Multi-Homed - The network receives multiple routes (multi-homed) from a single ISP (single-provider). ISP customers that use a single ISP, but have multiple connections to their ISP may only receive the default route (0.0.0.0/0) at each ISP gateway. If an ISP connection goes down, the advertised default route sent from the connected CPE router to internal routers would be withdrawn, and Internet traffic would then flow to a CPE router that has connectivity to the ISP. The customer's inside network would also be advertised to the ISP at each CPE router gateway, allowing the ISP to use alternate paths should a particular connection to a customer go down.
Multi-Provider / Multi-Homed - ISP customers that use more than one ISP (multi-provider / multi-homed) have one or more separate gateway routers for each ISP. In this case, the customer's AS must be a public AS, and may either be a transit or non-transit AS. A transit AS will receive and forward traffic from one ISP destined for a network reachable through another ISP (the traffic destination is not in the customer's AS). A non-transit AS should only receive traffic destined for its AS - all other traffic would be dropped. BGP routers in a transit AS would often receive a large portion (in many cases, all) of the full BGP route table from each ISP.

Why Use BGP?

Even if you are not a large network on the internet, BGP is the standard for multi-homing, load-balancing, and redundancy:
Single-provider / single-homed – Not typically a strong candidate for BGP, but may still use it to advertise networks to the ISP. single-homed networks are not eligible for a public AS from RIRs.
Single-provider / Multi-homed – Common to follow RFC2270 suggestion to use a single private AS (64512 to 65535) to get the benefit of BGP while preserving public ASN.
Multi-provider / Multi-homed – Highly redundant, typically with dedicated routers to each ISP. Requires public ASN. Large memory footprint
Route summarization makes routing scalable.

How Does BGP Work?

BGP uses TCP port 179 for communication. BGP is considered a path-vector protocol, containing end-to-end path descriptions for destinations. BGP neighbors can either be internal (iBGP) or external (eBGP):

iBGP – Neighbor is in the same AS.
eBGP – Neighbor is in a different AS.

Paths are advertised in UPDATE messages that are tagged with various path attributes. AS_PATH and NEXT_HOP are the two most important attributes that describe the path of a route in a BGP update message.

AS_PATH: Indicates the ASs that the route is traveling from and two. In the example below, the AS_PATH is from AS 7675 to AS 12345. For internal BGP, the AS_PATH specifies the same AS for both the source and destination.
NEXT_HOP: Indicates the IP address of the next router the path travels to. Paths advertised across AS boundaries inherit the NEXT_HOP address of the boundary router. BGP relies on interior routing protocols to reach NEXT_HOP addresses.

BGP Finite State Machine

RFC 1771, which defines BGP, describes the operation of BGP in terms of the following state machine. The table following BGP Finite State Machine provides additional information on the various states.

BGP Finite State Machine

 

BGP Finite State Machine: States

State

Description

Idle

Waiting for Start event, after establishing new BGP session or resetting an existing session. In the event of errors, falls back to the Idle state. After a Start event, BGP initializes, resets connect retry timer, initiates TCP transport connection, and listens for connections

Connect

Once the TCP layer is up, transition to OpenSent, and send OPEN. If no TCP, transition to Active. If the connect retry timer expires, remain in Connect, reset the timer, and initiate a transport connection. Otherwise, transition back to Idle.

Active

Try to establish TCP connection with peer. If successful, transition to OpenSent and send OPEN. If connect retry expires, restart the timer and fall back to the Connect state. Also actively listen for connection by another peer. Go back to Idle in case of other events.

Connect to Active flapping indicates a TCP transport problem, for example, TCP retransmissions or unreachability of a peer.

OpenSent

Waiting for OPEN message from peer. Validate on receipt. On validation failure, send NOTIFICATION and go to Idle. On success, send KEEPALIVE and reset the keepalive timer. Negotiate hold time, smaller value wins. If zero, hold timer and keepalive timer are not restarted.

OpenConfirm

Wait for KEEPALIVE or NOTIFICATION. If KEEPALIVE is received, transition to Established. If UPDATE or KEEPALIVE is received, restart the hold timer (unless the negotiated hold time is zero). If NOTIFICATION is received, transition to Idle.

Periodic KEEPALIVE messages are sent. If TCP layer breaks, transition to Idle. If an error occurs, send a NOTIFICATION with error code, transition to Idle.

Established

Session up, exchange updates with peers. If a NOTIFICATION is received, transition to Idle. Updates are checked for errors. On error, send NOTIFICATION, and transition to Idle. In case of hold time expiration, disconnect TCP.

BGP Messages

BGP communication includes the following types of messages

Open – The first message between BGP peers after TCP session establishment. Contains the necessary information to establish a peering session, for example, ASN, hold time, and capabilities such as multi-product extensions and route-refresh.
Update – These messages contain path information, such as route announcements or withdrawals.
Keepalive – Periodic messages to keep TCP layer up, and to advertise liveliness.
Notification – A request to terminate the BGP session. Non-fatal notifications contain the error code “cease”. Subcodes provide further detail:
 

Notification Subcodes

Subcode

Description

1 – Maximum number of prefixes reached

The configured “neighbor maximum-prefix” value was exceeded

2 – Administratively shutdown

Session was administratively shutdown

3 – Peer unconfigured

Peer configuration has been removed

4 – Administratively reset

Session was administratively reset

5 – Connection rejected

Rejection (sometimes temporary) of BGP session

6 – Other configuration change

Session was administratively reset for some reason

Route-refresh – A request for the peer to resend its routes.
BGP Attributes

BGP update messages can include the following attributes:

 

BCP Attributes

Value

Code

1

ORIGIN

2

AS_PATH

3

NEXT_HOP

4

MULTI_EXIT_DISC

5

LOCAL_PREF

6

ATOMIC_AGGREGATE

7

AGGREGATOR

8

COMMUNITY

9

ORIGINATOR_ID

10

CLUSTER_LIST

11

DPA

12

ADVERTISER (Historic)

13

RCID_PATH / CLUSTER_ID (Historic)

14

MP_REACH_NLRI

15

MP_UNREACH_NLRI

16

EXTENDED COMMUNITIES

17

AS4_PATH

18

AS4_AGGREGATOR

19

SAFI Specific Attribute (SSA) (deprecated)

20

Connector Attribute (deprecated)

21

AS_PATHLIMIT (deprecated)

22

PMSI_TUNNEL

23

Tunnel Encapsulation Attribute

24

Traffic Engineering

25

IPv6 Address Specific Extended Community

26

AIGP (TEMPORARY - expires 2011-02-23)

27-254

Unassigned

255

Reserved for development

For more information on BGP attributes, see: http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xml.

Caveats

Scale - Currently, SonicOS supports from 512 to 2,048 policy-based routes (PBRs). This is not sufficient for full or even partial routing tables. The number of routes that exist in the RIB may be greater than the number installed into PBR (which is the FIB). This occurs when multiple competing routes have been received through the routing protocols. For each case in which the RIB contains competing routes to a particular network destination, only one of these routes is chosen to be installed in the FIB.

Currently, our implementation is most appropriate for the single-provider/single-homed customers. Single-provider/multi-homed installations may also be appropriate when either the default route is being received from the ISP, or a very small number of ISP-specific routes are received by the customer. The latter allows inside routers to take the optimal path to destinations outside of the AS, but still within the ISP's network domain (this is called partial-routes).

Load balancing - Currently, load sharing, which allows the same source network (packet) to be sent in a round robin fashion to multiple BGP peers, is supported (see Using Multi-Homed BGP for Load Sharing). There is, however, currently no multi-path support in SonicOS, which precludes load-balancing without splitting networks.
Loopback - There is currently no loopback interface support.
NAT - BGP is for routing. It does not co-exist well with NAT.
VPN updates - BGP updates over VPN are not currently working.
Asymmetric paths - Stateful firewall will not currently handle asymmetric paths, especially not across multiple firewalls.

Configuring BGP

The following sections describe how to configure BGP Advanced Routing for SonicOS:

IPsec Configuration for BGP

BGP transmits packets in the clear. Therefore for strong security, SonicWALL recommends configuring an IPsec tunnel to use for BGP sessions. The configurations of the IPsec tunnel and of BGP are independent of each other. The IPsec tunnel is configured completely within the VPN configuration section of the SonicOS GUI, while BGP is enabled on the Network > Routing page and then configured on the SonicOS Command Line Interface. When configuring BGP over IPsec, first configure the IPsec tunnel and verify connectivity over the tunnel before configuring BGP.

The following procedure shows a sample IPsec configuration between a SonicWALL and a remote BGP peer, where the SonicWALL is configured for 192.168.168.75/24 on the X0 network and the remote peer is configured for 192.168.168.35/24 on the X0 network.

1
Navigate to the VPN > Settings page and click the Add button under the VPN Policies section. The VPN Policies dialog displays.

2
In the Policy Type drop-down menu, make sure that Site to Site is selected.
* 
NOTE: A site-to-site VPN tunnel must be used for BGP over IPsec. Tunnel interfaces will not work for BGP.
3
Select the desired Authentication Method. In this example, we are using IKE using Preshared Secret.
4
Enter a Name for the VPN policy.
5
In the IPsec Primary Gateway Name or Address field, enter the IP address of the remote peer (for this example it is 192.168.168.35).
6
In the IPsec Secondary Gateway Name or Address field, enter 0.0.0.0.
7
Enter a Shared Secret and confirm it.
8
In the Local IKE ID field, enter the IP address of the SonicWall (for this example it is 192.168.168.75)
9
In the Peer IKE ID field, enter the IP address of the remote peer (192.168.168.35).
10
Click on the Network tab.

11
For the local network, select X0 IP from the Choose local network from list drop-down menu.
12
For the remote network, select the remote peer’s IP address from the Choose destination network from list drop-down menu, which is 192.168.168.35 for this example. If the remote IP address is not listed, select Create new address object to create an address object for the IP address.
13
Click on the Proposals tab. You can either use the default IPsec proposals or customize them as you see fit.
14
Click on the Advanced tab.
15
Check the Enable Keep Alive check box.
16
Click OK.

The VPN policy is now configured on the SonicWALL appliance. Now complete the corresponding IPsec configuration on the remote peer. When that is complete, return to the VPN > Settings page and check the Enable check box for the VPN policy to initiate the IPsec tunnel.

Use the ping diagnostic on the SonicWALL to ping the BGP peer IP address and use Wireshark to ensure that the request and response are being encapsulated in ESP packets.

* 
NOTE: As configured in this example, routed traffic will not go through the IPSEC tunnel used for BGP. That traffic is sent and received in the clear, which is most likely the desired behavior since the goal is to secure BGP, not all the routed network traffic.

For more detailed information on configuring IPsec, see the VPN chapters in the SonicOS Administrator’s Guide.

Basic BGP Configuration

To configure BGP on a SonicWALL security appliance:
1
On the SonicOS GUI, navigate to the Network > Routing page.
2
In the Routing Mode drop-down menu, select Advanced Routing.
3
In the BGP drop-down menu, select Enabled (Configure with CLI).
* 
NOTE: The SonicOS Expanded license is required for BGP. See the System > Licenses page to manage your licenses.

* 
NOTE: After BGP has been enabled through the GUI, the specifics of the BGP configuration are performed using the SonicOS command line interface (CLI). For detailed information on how to connect to the SonicOS CLI, see the SonicOS Command Line Interface Guide at: http://www.SonicWALL.com/us/support/230_3623.html.
4
Log in to the SonicOS CLI through the console interface.
5
Enter configuration mode by typing the configure command.
6
Enter the BGP CLI by typing the route ars-bgp command. You will now see the following prompt:

ZebOS version 7.7.0 IPIRouter 7/2009

ARS BGP>

7
You are now in BGP Non-Config Mode. Type ? to see a list of non-config commands.
8
Type show running-config to see the current BGP running configuration.
9
To enter BGP Configuration Mode, type the configure terminal command. Type ? to see a list of configuration commands.
10
When you have completed your configuration, type the write file command. If the unit is part of a High Availability pair or cluster, the configuration changes will be automatically conveyed to the other unit or units.

BGP Path Selection Process

The following attributes can be used to configure the BGP path selection process.

 

BGP Path Selection Process Attributes

Attribute

Description

Weight

Prefer routes learned from neighbors with the highest weight set. Only relevant to the local router.

Local Preference

Administratively prefer routes learned from a neighbor. Shared with the whole AS.

Network or Aggregate paths

Prefer paths that were locally originated from the network and aggregate-address commands.

AS_PATH

Prefer the path with the shortest AS_PATH.

Origin

Prefer the path with the lowest origin type (as advertised in UPDATE messages): IGP < EGP < Incomplete.

Multi Exit Discriminator (MED)

Provides path preference information to neighbors for paths into originating AS.

Recency

Prefer the most recently received path.

Router ID

Prefer the path from the router with the lower router ID.

Weight

The weight command assigns a weight value, per address-family, to all routes learned from a neighbor. The route with the highest weight gets preference when the same prefix is learned from more than one peer. The weight is relevant only to the local router.

The weights assigned using the set weight command override the weights assigned using this command.

When the weight is set for a peer-group, all members of the peer-group will have the same weight. The command can also be used to assign a different weight to a particular peer-group member.

The following example shows weight configuration:

router bgp 12345
   neighbor 12.34.5.237 remote-as 12345
   neighbor 12.34.5.237 weight 60
router bgp 12345
   neighbor group1 peer-group
   neighbor 12.34.5.237 peer-group group1
   neighbor 67.78.9.237 peer-group group1
   neighbor group1 weight 60
Local Preference

The Local Preference attribute is used to indicate the degree of preference for each external route in an appliance’s routing table. The Local Preference attribute is included in all update messages sent to devices in the same AS. Local Preference is not communicated to outside AS. The following figure shows a sample topology illustrating how Local Preference affects routes between neighboring ASs.

BGP Local Preference Topology

The following BGP configurations are entered on SNWL1 and SNWL2. The higher Local Preference on SNWL2 leads to SNWL2 being the preferred route advertised by AS 12345 (the SonicWall AS) to outside ASs.

 

BGP Local Preference Topology: BGP Configurations

SNWL1 Configuration

SNWL2 Configuration

x0 = 12.34.5.228
x1 = 172.16.228.45
------------------
router bgp 12345
neighbor 172.16.228.228 remote-as 7675
neighbor 12.34.5.237 remote-as 12345
bgp default local-preference 150
x0 = 12.34.5.237
x1 = 10.1.1.2
------------------
router bgp 12345
neighbor 10.1.1.1 remote-as 8888
neighbor 12.34.5.228 remote-as 12345
bgp default local-preference 200
Local Preference Used with Route Maps

Route Maps are similar to Access Control Lists. They consist of a series of Permit and/or Deny statements that determine how the appliance processes the routes. Route maps are applied to inbound traffic—not outbound traffic. The following diagram shows a sample topology that uses a route map to configure local preference.

BGP Local Preference topology with Route Maps

The following BGP configurations are entered on SNWL1 and SNWL2.

 

BGP Local Preference Topology with Route Maps: BGP Configurations

SNWL1 Configuration

SNWL2 Configuration

x1 = 172.16.228.45
 
 
------------------
router bgp 12345
neighbor 172.16.228.228 remote-as 7675
neighbor 12.34.5.237 remote-as 12345
bgp default local-preference 150
x0 = 12.34.5.237
x1 = 10.1.1.2
x4 = 10.4.4.1
------------------
router bgp 12345
neighbor 10.1.1.1 remote-as 9999
neighbor 10.1.1.1 route-map rmap1 in
neighbor 12.34.5.237 remote-as 12345
....
ip as-path access-list 100 permit ^8888$
...
route-map rmap1 permit 10
match as-path 100
set local-preference 200
 
route-map rmap1 permit 20
set local-preference 150

The Route Map configured on SNWL2 (rmap1) is configured to apply to inbound routes from neighbor 10.1.1.1. It has two permit conditions:

route-map rmap1 permit 10: This permit condition matches access list 100 that is configured to permit traffic from AS 8888 and set routes from AS 8888 to a Local Preference of 200.
route-map rmap1 permit 10: This permit condition sets all other traffic that doesn’t match access list 100 (that is, traffic coming from ASs other than 8888) to a Local Preference of 150.

AS_PATH Prepending

AS_Path Prepending is the practice of adding additional AS numbers at the beginning of a path update. This makes the path for this route longer, and thus decreases its preference.

AS_Path Prepending can be applied on either outbound or inbound paths. AS_Path Prepending may not be honored if it is over-ruled by a neighbor.

 

AS_PATH Prepending: Outbound and Inbound Path Configurations

Outbound Path Configuration

Inbound Path Configuration

router bgp 12345

bgp router-id 10.50.165.233

network 12.34.5.0/24

neighbor 10.50.165.228 remote-as 7675

neighbor 10.50.165.228 route-map long out

!

route-map long permit 10

set as-path prepend 12345 12345

router bgp 7675

bgp router-id 10.50.165.228

network 7.6.7.0/24

neighbor 10.50.165.233 remote-as 12345

neighbor 10.50.165.233 route-map prepend in

!

route-map prepend permit 10

set as-path prepend 12345 12345

 

This configuration leads to a route being installed to the neighbor 10.50.165.233 with the AS_Path Prepended as 12345 12345. This can be viewed by entering the show ip bgp command.

ARS BGP>show ip bgp
BGP table version is 98, local router ID is 10.50.165.228
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 12.34.5.0/24 10.50.165.233 0 0 12345 12345 12345 i
*> 7.6.7.0/24 0.0.0.0 100 32768 i
Total number of prefixes 2

Multiple Exit Discriminator (MED)

Topics:
set metric Command

The set metric command can be used in a route map to make paths more or less preferable:

router bgp 7675
   network 7.6.7.0/24
   neighbor 10.50.165.233 remote-as 12345
   neighbor 10.50.165.233 route-map highmetric out
!
route-map highmetric permit 10
   set metric 300

The Multi Exit Discriminator (MED) is an optional attribute that can be used to influence path preference. It is non-transitive, meaning it is configured on a single appliance and not advertised to neighbors in update messages. In this section, we will consider the uses of the bgp always-compare-med and bgp deterministic-med commands.

bgp always-compare-med Command

The bgp always-compare-med command allows comparison of the MED values for paths from different ASs for path selection. A path with lower MED is preferred.

As an example, consider the following routes in the BGP table and the always-compare-med command is enabled:

Route1: as-path 7675, med 300
Route2: as-path 200, med 200
Route3: as-path 7675, med 250

Route2 would be the chosen path because it has the lowest MED.

If the always-compare-med command was disabled, MED would not be considered when comparing Route1 and Route2 because they have different AS paths. MED would be compared for only Route1 and Route3.

bgp deterministic-med Command

The selected route is also affected by the bgp deterministic-med command, which compares MED when choosing among routes advertised by different peers in the same autonomous system.

When the bgp deterministic-med command is enabled, routes from the same AS are grouped together, and the best routes of each group are compared. If the BGP table showed:

Route1: as-path 200, med 300, internal
Route2: as-path 400, med 200, internal
Route3: as-path 400, med 250, external

BGP would have a group of Route1 and a second group of Route2 and Route3 (the same AS).

The best of each group is compared. Route1 is the best of its group because it is the only route from AS 200.

Route1 is compared to the Route2, the best of group AS 400 (the lower MED).

Since the two routes are not from the same AS, the MED is not considered in the comparison. The external BGP route is preferred over the internal BGP route, making Route3 the best route.

BGP Communities

A community is a group of prefixes that share some common property and can be configured with the transitive BGP community attribute. A prefix can have more than one community attribute. Routers can act on one, some or all the attributes. BGP communities can be thought of as a form of tagging. The following is an example of a BGP communities configuration.

router bgp 12345
   bgp router-id 10.50.165.233
   network 12.34.5.0/24
   network 23.45.6.0/24
   neighbor 10.50.165.228 remote-as 7675
   neighbor 10.50.165.228 send-community
   neighbor 10.50.165.228 route-map comm out
!
access-list 105 permit 12.34.5.0/24
access-list 110 permit 23.45.6.0/24
!
route-map comm permit 10
   match ip address 105
   set community 7675:300
!
route-map comm permit 20
   match ip address 110
   set community 7675:500
!
router bgp 7675
   bgp router-id 10.50.165.228
   network 7.6.7.0/24
   neighbor 10.50.165.233 remote-as 12345
   neighbor 10.50.165.233 route-map shape in
!
ip community-list 1 permit 7675:300
ip community-list 2 permit 7675:500
!
route-map shape permit 10
   match community 1
   set local preference 120
 
route-map shape permit 20
   match community 2
   set local preference 130

Synchronization and Auto-Summary

The synchronization setting controls whether the router advertises routes learned from an iBGP neighbor based on the presence of those routes in its IGP. When synchronization is enabled, BGP will only advertise routes that are reachable through OSPF or RIP (the Exterior Gateway Protocols as opposed to BGP, the Exterior Gateway Protocol). Synchronization is a common cause of BGP route advertisement problems.

The auto-summary setting controls whether or not routes are advertised classfully. Auto-summary is another common cause of BGP configuration problems

By default, auto-summary and synchronization are disabled on Zebos.

Preventing an Accidental Transit AS

As we discussed earlier, an AS peer can either be a transit peer (allowing traffic from an outside AS to another outside AS) or a non-transit peer (requiring all traffic to either originate or terminate on its AS). Transit peers will have dramatically larger routing tables. Typically, you will not want to configure a SonicWALL security appliance as a transit peer.

Transit Peers vs. Non-Transit Peers

To prevent your appliance from inadvertently becoming a transit peer, you will want to configure inbound and outbound filters, such as the following:

Outbound Filters
Permit only routes originated from the local AS out:
ip as-path access-list 1 permit ^$
router bgp 12345
   bgp router-id 10.50.165.233
   network 12.34.5.0/24
   neighbor 10.50.165.228 remote-as 7675
   neighbor 10.50.165.228 filter-list 1 out
   neighbor 172.1.1.2 remote-as 9999
   neighbor 10.50.165.228 filter list 1 out
Permit only owned prefixes out:
ip prefix-list myPrefixes seq 5 permit 12.34.5.0/24
ip prefix-list myPrefixes seq 10 permit 23.45.6.0/24
router bgp 12345
   bgp router-id 10.50.165.233
   network 12.34.5.0/24
   network 23.45.6.0/24
   neighbor 10.50.165.228 remote-as 7675
   neighbor 172.1.1.2 remote-as 9999
   neighbor 10.50.165.228 prefix-list myPrefixes out
   neighbor 172.1.1.2 prefix-list myPrefixes out
Inbound Filters
Drop all owned and private inbound prefixes
ip prefix-list unwantedPrefixes seq 5 deny 12.34.5.0/24 le 32
ip prefix-list unwantedPrefixes seq 10 deny 23.45.6.0/24 le 32
ip prefix-list unwantedPrefixes seq 20 deny 10.0.0.0/8 le 32
ip prefix-list unwantedPrefixes seq 21 deny 172.16.0.0/12 le 32
ip prefix-list unwantedPrefixes seq 22 deny 192.168.0.0/16 le 32
ip prefix-list unwantedPrefixes seq 30 permit 0.0.0.0/0 le 32
router bgp 12345
   bgp router-id 10.50.165.233
   network 12.34.5.0/24
   network 23.45.6.0/24
   neighbor 10.50.165.228 remote-as 7675
   neighbor 172.1.1.2 remote-as 9999
   neighbor 10.50.165.228 prefix-list unwantedPrefixes in
   neighbor 172.1.1.2 prefix-list unwantedPrefixes in

Using Multi-Homed BGP for Load Sharing

The following topology shows an example where a SonicWALL security appliance uses a multi-homed BGP network to load share between two ISPs.

Multi-Homed BGP for Load Sharing Topology

The SonicWALL security appliance is configured as follows:

router bgp 12345
   bgp router-id 10.50.165.233
   network 12.34.5.0/24
   neighbor 10.50.165.228 remote-as 7675
   neighbor 10.50.165.228 route-map ISP1 out
   neighbor 172.1.1.2 remote-as 9999
   neighbor 10.50.165.228 route-map ISP2 out
!
route-map ISP1 permit 10
match ip address 1
set weight 100
route-map ISP1 permit 20
match ip address 2
route-map ISP2 permit 10
match ip address 1
route-map ISP2 permit 20
match ip address 2
set weight 100
access-list 1 permit 12.34.5.0/25
access-list 2 deny 12.34.5.0/25
access-list 2 permit any

Verifying BGP Configuration

The following sections describe methods to verify a BGP configuration:

Viewing BGP Routes

Figure shows a basic BGP topology where a SonicWALL security appliance is configured for BGP to connect to two routers on two different ASs.

BGP Topology

The routes in the FIB for this network can be viewed either in the SonicOS GUI or by using the CLI.

Topics:
Viewing FIB routes in the GUI

A summary of the BGP configuration can be viewed on the SonicOS GUI through the Network > Routing page by clicking the BGP Status button, located at the top of the page next to the Routing Mode drop-down menu. The BGP Status dialog displays the output of the show ip bgp summary and show ip bgp neighbor commands.

The BGP routes in the FIB can also be viewed on the SonicOS GUI in the Routing Policies table on the Network > Routing page.

Viewing FIB Routes in the CLI

To view the FIB routes in the CLI, perform the following commands:

SonicWALL> configure
(config[SonicWALL])> route ars-nsm
ZebOS version 7.7.0 IPIRouter 7/2009
ARS NSM>show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
B 7.6.7.0/24 [20/0] via 10.50.165.228, X1, 05:08:31
B 199.199.0/16 [20/0] via 10.50.165.237, X1, 05:08:31
C 10.50.165.192/26 is directly connected, X1
C 127.0.0.0/8 is directly connected, lo0
C 12.34.5.0/24 is directly connected, X0
Viewing RIB Routes in the CLI

To view the RIB routes in the CLI, enter the show ip bgp command:

ARS BGP>show ip bgp
BGP table version is 98, local router ID is 10.50.165.233
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, l - labeled
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 7.6.7.0/24 10.50.165.228 0 0 7675 i
*> 12.34.5.0/24 0.0.0.0 100 32768 i
*> 199.199.0.0/16 10.50.165.228 0 0 7675 9999 i
Total number of prefixes 3
* 
NOTE: The last route is the path to AS9999 that was learned through AS7675.

Configuring BGP Logging

SonicWALL BGP offers a comprehensive selection of debug commands to display log events related to BGP traffic. BGP logging can be configured on the CLI by using the debug bgp command followed by of the following keywords:

 

BP Debug Keyword Descriptions

BGP Debug Keywords

Description

all

Enables all BGP debugging.

dampening

Enables debugging for BGP dampening.

events

Enables debugging for BGP events.

filters

Enables debugging for BGP filters.

fsm

Enables debugging for BGP Finite State Machine (FSM).

keepalives

Enables debugging for BGP keepalives.

nht

Enables debugging for NHT messages.

nsm

Enables debugging for NSM messages.

updates

Enables debugging for inbound/outbound BGP updates.

To disable BGP debugging, enter the “no” form of the command. For example, to disable event debugging, type the no debug events command.

BGP log messages can also be viewed on the SonicOS GUI on the Log > Log Monitor page. BGP messages are displayed as part of the Advanced Routing category of log messages.

The above message indicates that an update to the outgoing RIB was denied because the router from which the update was received was not directly connected to the appliance.

To allow for BGP peers that are not directly connected, use the ebgp-multihop keyword with the neighbor command. For example:

neighbor 10.50.165.228 ebgp-multihop

IPv6 BGP

IPv6 Border Gateway protocol (BGP) communicates IPv6 routing information between Autonomous Systems (ASs). A SonicWall security appliance with IPv6 BGP support can replace a traditional BGP router on the edge of a network's AS.

IPv6 BGP is enabled on the Network > Routing page, but must be configured on the SonicOS Command Line Interface (CLI).

The following restrictions apply to SonicOS 5.9.0.2

IPv6 BGP is supported only on NSA platforms.
IPv6 BGP depends on IPv6 functions and ZebOS (Zebra OS).
MPLS/VPN and multicast are not supported in IPv6 BGP.
Topics:

Configuring Multiple Autonomous Systems

If an Autonomous System (AS) has multiple BGP routers, the AS can serve as a transit service for other ASs. When BGP runs between routers in different ASs, it uses exterior BGP (eBGP). When BGP runs between routers in the same AS, it uses interior BGP (iBGP).

In the following diagram, AS 200 is a transit AS for AS 100 and AS 300.

Multiple Autonomous Systems Configuration

To configure multiple ASs as shown in the above diagram, configure routers RTA, RTB, and RTC as follows:

On RTA:
router bgp 100
   neighbor 129.213.1.1 remote−as 200
address-family ipv6
   redistribute connected
   neighbor 129.213.1.1 activate
On RTB:
router bgp 200
   neighbor 129.213.1.2 remote−as 100
   neighbor 175.220.1.2 remote−as 200
address-family ipv6
   redistribute connected
   neighbor 129.213.1.2 activate
   neighbor 175.220.1.2 activate
On RTC:
router bgp 200
   neighbor 175.220.212.1 remote−as 200
address-family ipv6
   neighbor 175.220.212.1 activate
   neighbor 175.220.212.1 activate
 

Configuring Basic BGP over IPv6

A IPv6 BGP peer router can be configured to carry either IPv4 or IPv6 route information over either an IPv6 address family or an IPv4 address family.

Basic BGP over IPv6 Configuration

To configure basic BGP over IPv6, configure routers R1 and R2 as follows:

On R1:
router bgp 6501
   bgp router−id 1.1.1.1
   neighbor 2011:11:11:11::2 remote−as 6502
 
address−family ipv6
   neighbor 2011:11:11:11::2 activate
exit−address−family
On R2:
router bgp 6502
   bgp router−id 2.2.2.2
   neighbor 2011:11:11:11::1 remote−as 6501
 
address−family ipv6
   network 1010::1/128
   network 2020::1/128
   neighbor 2011:11:11:11::1 activate

Configuring EBGP Multihop

EBGP Multihop enables you to establish a neighbor connection between two external peers that are not directly connected. Multihop is available only for eBGP and is not available in for iBGP. When the firewall has an external neighbor that does not have a direct connection, you can use the ebgp−multihop command to establish a neighbor connection.

To configure EBGP Multihop, configure routers R1 and R2 as follows:

On R1:
router bgp 6501
   bgp router−id 1.1.1.1
   neighbor 2011:11:11:11::2 remote−as 6502
   neighbor 2011:11:11:11::2 ebgp−multihop
 
address−family ipv6
   neighbor 2011:11:11:11::2 activate
exit−address−family
 
On R2:
router bgp 6502
   bgp router−id 2.2.2.2
   neighbor 2011:11:11:11::1 remote−as 6501
   neighbor 2011:11:11:11::1 ebgp−multihop
 
address−family ipv6
   network 1010::1/128
   network 2020::1/128
   neighbor 2011:11:11:11::1 activate

Configuring IPv6 BGP Outbound Route Filter

IPv6 BGP Outbound Route Filter (ORF) can be used to minimize the number of BGP updates sent between peer routers by filtering out unwanted routing updates at the source.

To configure IPv6 BGP Outbound Route Filter (ORF), configure routers R1 and R2 as follows:

On R1:
router bgp 6501
   bgp router−id 1.1.1.1
   neighbor 2011:11:11:11::2 remote−as 6502
 
address−family ipv6
   redistribute connected
   neighbor 2011:11:11:11::2 activate
   neighbor 2011:11:11:11::2 prefix-list pref1 in
   neighbor 2011:11:11:11::2 prefix-list pref2 out
exit−address−family
 
ipv6 prefix-list pref1 seq 10 deny 1010::1/128
ipv6 prefix-list pref1 seq 20 permit any
ipv6 prefix-list pref2 seq 10 deny 1111::1/128
ipv6 prefix-list pref2 seq 20 permit any
On R2:
router bgp 6502
   bgp router−id 2.2.2.2
   neighbor 2011:11:11:11::1 remote−as 6501
 
address−family ipv6
   redistribute connected
   neighbor 2011:11:11:11::1 activate
 

To check the routes on R1 and R2, use the show bgp ipv6 unicast command.

The route on R1 should have IPv6 address 1010::1/128.
The route on R2 should have IPv6 address 1111::1/128.
On R1:
R1> show bgp ipv6 unicast
On R2:
R2> show bgp ipv6 unicast

Configuring IPv6 BGP Distribute List

IPv6 BGP Distribute List can be used to minimize the number of BGP updates sent between peer routers by filtering out unwanted routing updates at the source.

To configure IPv6 BGP Distribute List, configure routers R1 and R2 as follows:

On R1:
router bgp 6501
   bgp router−id 1.1.1.1
   neighbor 2011:11:11:11::2 remote−as 6502
 
address−family ipv6
   redistribute connected
   neighbor 2011:11:11:11::2 activate
   neighbor 2011:11:11:11::2 distribute-list acl1 in
   neighbor 2011:11:11:11::2 distribute-list acl2 out
exit−address−family
 
ipv6 access-list acl1 deny 1010::1/128
ipv6 access-list acl1 permit any
ipv6 access-list acl2 deny 1111::1/128
ipv6 access-list acl2 permit any
On R2:
router bgp 6502
   bgp router−id 2.2.2.2
   neighbor 2011:11:11:11::1 remote−as 6501
 
address−family ipv6
   redistribute connected
   neighbor 2011:11:11:11::1 activate
 

To check the routes on R1 and R2, use the show bgp ipv6 unicast command.

The route on R1 should have IPv6 address 1010::1/128.
The route on R2 should have IPv6 address 1111::1/128.
On R1:
R1> show bgp ipv6 unicast
On R2:
R2> show bgp ipv6 unicast

IPv6 BGP Route-Map

IPv6 BGP Route-Map can be used to minimize the number of BGP updates sent between peer routers by filtering out unwanted routing updates at the source.

To configure IPv6 BGP Route-Map, configure routers R1 and R2 as follows:

On R1:
router bgp 6501
   bgp router−id 1.1.1.1
   neighbor 2011:11:11:11::2 remote−as 6502
 
address−family ipv6
   redistribute connected
   neighbor 2011:11:11:11::2 activate
   neighbor 2011:11:11:11::2 route-map map1 in
   neighbor 2011:11:11:11::2 route-map map2 out
exit−address−family
 
ipv6 access-list acl1 deny 1010::1/128
ipv6 access-list acl1 permit any
ipv6 access-list acl2 deny 1111::1/128
ipv6 access-list acl2 permit any
!
route-map map1 permit 1 match ipv6 address acl1
!
route-map map2 permit 1 match ipv6 address acl2
!
On R2:
router bgp 6502
   bgp router−id 2.2.2.2
   neighbor 2011:11:11:11::1 remote−as 6501
 
address−family ipv6
   redistribute connected
   neighbor 2011:11:11:11::1 activate

To check the routes on R1 and R2, use the show bgp ipv6 unicast command.

On R1:
R1> show bgp ipv6 unicast

The route on R1 should have IPv6 address 1010::1/128.

On R2:
R2> show bgp ipv6 unicast

The route on R2 should have IPv6 address 1111::1/128.

Configuring an AS Regular Expression

You can configure regular expressions that can be matched and used to deny or allow addresses from an AS.

AS Regular Expression Configuration

RTB advertises these routes:

2004::/64
2003::/64
2002::/64

RTC advertises these routes:

5000::/64
6666::6/128
7777::7/128

To check the routes on router RTA, use the show bgp ipv6 unicast command.

On RTA:
RTA> show bgp ipv6 unicast
BGP table version is 4, local router ID is 10.0.1.2
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal, l - labeled
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
 

Network

Next Hop

Metric

LocPrf

Weight

Path

*> 2002::/64
::ffff:a00:101
0
0
100
i
*> 2003::/64
::ffff:a00:101
0
0
100
i
*> 2004::/64
::ffff:a00:101
0
0
100
i
*> 5000::/64
::ffff:a00:101
0
0
100
400i
*> 6666::6/128
::ffff:a00:101
0
0
100
400
*> 7777::7/128
::ffff:a00:101
0
0
100
400

To configure AS regular expressions on RTA and deny all routes originated in AS100:

router bgp 200
   neighbor 10.0.1.1 remote-as 100
   neighbor 10.0.1.1 update-source X2
   neighbor 2004::1 remote-as 100
   neighbor 2004::1 update-source X2
!
address-family ipv6
   neighbor 10.0.1.1 activate
   neighbor 10.0.1.1 filter-list 1 in
   neighbor 2004::1 activate
exit-address-family
 
ip as-path access-list 1 deny ^100$
ip as-path access-list 1 permit .*
 

To check the routes on router RTA, use the show bgp ipv6 unicast command.

On RTA:
RTA> show bgp ipv6 unicast
BGP table version is 4, local router ID is 10.0.1.2
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal, l - labeled
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
 
 

Network

Next Hop

Metric

LocPrf

Weight

Path

*> 5000::/64
::ffff:a00:101
0
0
100
400i
*> 6666::6/128
::ffff:a00:101
0
0
100
400i
*> 7777::7/128
::ffff:a00:101
0
0
100
400i
Total number of prefixes 3

To modify the AS path to deny all routes learned from the AS100:

On RTA:
router bgp 200
   neighbor 10.0.1.1 remote-as 100
   neighbor 10.0.1.1 update-source X2
   neighbor 2004::1 remote-as 100
   neighbor 2004::1 update-source X2
!
address-family ipv6
   neighbor 10.0.1.1 activate
   neighbor 10.0.1.1 filter-list 1 in
   neighbor 2004::1 activate
exit-address-family
 
ip as-path access-list 1 deny _100_
ip as-path access-list 1 permit .*

To check the routes on router RTA, use the show bgp ipv6 unicast command.

On RTA:
RTA> show bgp ipv6 unicast

EBGP Route Selection

Routes are selected based on the administrative distance of the routing protocol running on that route. Routing protocols with lower administrative distances are given priority over routing protocols with higher administrative distances. EBGP has an administrative distance of 20. OSPF has an administrative distance of 110.

This diagram shows three ASs and the routing protocols used by the BGP routers.

EBGP Route Selection Configuration

The RTC router in AS300 advertises route 1000::/64 to both AS100 and to AS200:

The route from RTC (AS300) to RTA (AS100) runs OSPF.
The route from RTC (AS300) to RTB (AS200) runs eBGP.
The route from RTA (AS100) to RTB (AS200) runs eBGP.

RTA (AS100) receives updates about route 1000::/64 from both OSPF and eBGP. The route learned from eBGP is selected and added to RTA’s routing table, because the administrative distance of eBGP is less than the administrative distance of OSPF.

On RTA:
router bgp 100
   neighbor 3001::1 remote-as 200
!
address-family ipv6
   distance bgp 150 150 150
   neighbor 3001::1 activate
exit-address-family
On RTB:
router bgp 200
   bgp log-neighbor-changes
   neighbor 1001::1 remote-as 300
   neighbor 2003::1 remote-as 100
 
address-family ipv6
   network 6666::6/128
   neighbor 1001::1 activate
   neighbor 2003::1 activate
exit-address-family
On RTC:
router bgp 300
   neighbor 3002::1 remote-as 200
!
address-family ipv6 network 1000::/64
   neighbor 3002::1 activate
exit-address-family

To check the routes on router RTA, use the show ipv6 route command.

RTA> show ipv6 route
IPv6 Routing Table
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP
Timers: Uptime
 
B 1000::/64 [20/0] via fe80::204:27ff:fe0c:b006, X1, 00:01:07
C 2003::/64 via ::, X1, 00:30:50
B 6666::6/128 [20/0] via fe80::204:27ff:fe0c:b006, X1, 00:01:07
C fe80::/64 via ::, X1, 00:30:53
 

Since RTC is directly connected to RTA, the route from OSPF is actually a better route than the route learned by BGP. To ensure that the route between RTA and RTC is selected for the routing table, you can use the distance command to change the default administrative distance of the BGP route to a higher administrative distance than the OSPF route. For example:

distance bgp 150 150 150

You can also use the backdoor neighbor command to set the BGP route as the preferred route. For example:

On RTA:
router bgp 100
   neighbor 3001::1 remote-as 200
!
address-family ipv6
   network 1000::/64
   backdoor neighbor 3001::1 activate
exit-address-family
 

To check the routes on router RTA, use the show ipv6 route command.

RTA> show ipv6 route
IPv6 Routing Table
 
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP
Timers: Uptime
 
O 1000::/64 [110/2] via fe80::217:c5ff:feb4:57f2, X4, 00:30:53
C 2003::/64 via ::, X1, 00:31:18
B 6666::6/128 [20/0] via fe80::204:27ff:fe0c:b006, X1, 00:00:03
C fe80::/64 via ::, X1, 00:31:21

IPv6 BGP Synchronization

IPv6 BGP Synchronization keeps all BGP routers updated with the IPv6 addresses of all available routes and networks.

In BGP Synchronization, if an AS (AS100) passes traffic from another AS (AS300) to a third AS (AS400), BGP does not advertise that route until all the routers in AS100 have learned that route from the IGP. In this case, the IGP is iBGP. AS100 must wait until iBGP has propagated that route to all routers within AS100. Then, eBGP advertises the route to external ASs.

In this example, after RTB learns address 6666::6/128 via iBGP. it then advertises the address to RTD.

Sample IPv6 BGP Synchronization

* 
NOTE: You can make RTB think that IGP has already propagated the route information by adding a static route to 6666::6/128 on RTB and making sure that the other routers can reach 6666::6/128.

In this example, RTC (AS2) advertises address 6666::6/128 to RTA (AS100). In AS100, RTA and RTB are running iBGP, so RTB learns address 6666::6/128 and is able to reach it via next hop 5.5.5.5 (RTC). Next hop is carried via iBGP. However, to reach the next hop (RTC), RTB must send traffic through RTE, but RTE does not know IP address 6666::6/128.

If RTB advertises 6666::6/128 to RTD (AS400), traffic that tries to reach 6666::6/128 from RTD must pass through RTB and RTE in AS100. However, since RTE has not learned 6666::6/128, all packets will be dropped at RTE.

To configure BGP Synchronization on RTB in AS100:

On RTB:
router bgp 100
   neighbor 10.103.10.129 remote-as 100
   neighbor 3001::1 remote-as 100
   neighbor 3001::1 update-source X4
   neighbor 5000::1 remote-as 400
   neighbor 5000::1 update-source X2
!
address-family ipv6
   synchronization
   neighbor 10.103.10.129 activate
   neighbor 3001::1 activate
   neighbor 5000::1 activate
exit-address-family
 

You can disable synchronization if you do not pass traffic from one AS to another AS through an intermediate AS. You can also disable synchronization if all routers in the intermediate AS run BGP. Disabling synchronization lets you to carry fewer routes in your IGP and allows BGP to converge more quickly.

To disable BGP Synchronization on RTB in AS100:

On RTB:
router bgp 100
   neighbor 10.103.10.129 remote-as 100
   neighbor 3001::1 remote-as 100
   neighbor 3001::1 update-source X4
   neighbor 5000::1 remote-as 400
   neighbor 5000::1 update-source X2
!
address-family ipv6
   neighbor 10.103.10.129 activate
   neighbor 3001::1 activate
   neighbor 5000::1 activate
exit-address-family
 

BGP Route Reflection

By default, all iBGP routers in an AS must be in a full mesh configuration. Each router must be configured as a peer to every other router.

With route reflection, all iBGP routers do not need to be fully meshed. Route reflection eliminates the need for each iBGP router to communicate with every other iBGP router in the AS. An iBGP router can be designated as a route reflector and can pass iBGP learned routes to multiple iBGP clients.

When a router is configured as a route reflector, it acts as a single point where all the other iBGP routers can get the iBGP learned routes. The route reflector acts like a server, rather than a peer, for every other router in the AS. All the other IBGP routers become route reflector clients. A router is a route reflector as long as it has at least one route reflector client.

BGP Route Reflection Configuration

To configure route reflection in an AS:

On RouterA:
interface Serial0/0
   ipv6 address 2011:12:12:12::1/64
   ipv6 ospf 10 area 0
 
interface Serial0/1
   ipv6 address 2011:13:13:13::1/64
   ipv6 ospf 10 area 0
 
router bgp 100
 
bgp router−id 1.1.1.1
no bgp default ipv4−unicast
bgp log−neighbor−changes
   neighbor 2011:22:22:22::22 remote−as 100
   neighbor 2011:22:22:22::22 update−source Loopback0
   neighbor 2011:33:33:33::33 remote−as 100
   neighbor 2011:33:33:33::33 update−source Loopback0
!
address−family ipv6
   neighbor 2011:22:22:22::22 activate
   neighbor 2011:22:22:22::22 route−reflector−client
   neighbor 2011:33:33:33::33 activate
   neighbor 2011:33:33:33::33 route−reflector−client
exit−address−family
!
ipv6 router ospf 10
   router−id 1.1.1.1
 
On RRClient1:
interface Loopback0
   ipv6 address 2011:22:22:22::22/128
   ipv6 ospf 10 area 0
!
interface Loopback10
   ipv6 address 1010:10:10:10::10/128
 
interface Serial0/0
   ipv6 address 2011:12:12:12::2/64
   ipv6 ospf 10 area 0
!
router bgp 100
   bgp router−id 2.2.2.2
   bgp log−neighbor−changes
      neighbor 2011:11:11:11::11 remote−as 100
      neighbor 2011:11:11:11::11 update−source Loopback0
!
address−family ipv6
   neighbor 2011:11:11:11::11 activate
   network 1010:10:10:10::10/128
exit−address−family
!
ipv6 router ospf 10
   router−id 2.2.2.2
On RRClient2:
interface Loopback0
   ipv6 address 2011:33:33:33::33/128
   ipv6 ospf 10 area 0
!
interface Loopback20
   ipv6 address 2020:20:20:20::20/128
!
interface Serial0/0
   no ip address
   ipv6 address 2011:13:13:13::2/64
   ipv6 ospf 10 area 0
!
router bgp 100
   bgp router−id 3.3.3.3
   bgp log−neighbor−changes
      neighbor 2011:11:11:11::11 remote−as 100
      neighbor 2011:11:11:11::11 update−source Loopback0
!
address−family ipv6
   neighbor 2011:11:11:11::11 activate
   network 2020:20:20:20::20/128
exit−address−family
!
ipv6 router ospf 10
   router−id 3.3.3.3
   log−adjacency−changes

To check the routes, use the show bgp ipv6 unicast command:

On RRClient1:
RRClient1> show bgp ipv6 unicast

You should see route 2020:20:20:20::20/128.

On RRClient2:
RRClient2> show bgp ipv6 unicast

You should see route 1010:10:10:10::10/128.

IPv6 BGP Local Preference

The local preference designates a route to a certain network as the preferred exit route to that network from the AS. The route with a highest local preference is the preferred route. The default value of the local preference is 100, but this can be changed using the set local-preference command.

IPv6 BGP Local Preference Configuration

To configure the local preference of a preferred route in an AS:

On R1:
interface Loopback0
   ipv6 address 1111:111:111:A::/64 eui−64
   ipv6 ospf 10 area 0
 
interface FastEthernet0/0
   ipv6 address AB01:CD1:123:A::/64 eui−64
   ipv6 ospf 10 area 0
!
interface Serial0/0
   ipv6 address AB01:CD1:123:C::/64 eui−64
!
interface FastEthernet0/1
   ipv6 address AB01:CD1:123:B::/64 eui−64
   ipv6 ospf 10 area 0
!
   ipv6 router ospf 10 router−id 1.1.1.1 log−adjacency−changes
   redistribute connected route−map CONNECTED
!
route−map CONNECTED permit 10
   match interface Serial0/0
!
router bgp 123
bgp router−id 1.1.1.1
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 remote−as 123
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 update−source Loopback0
   neighbor 3333:333:333:A:C603:3FF:FEF0:0 remote−as 123
   neighbor 3333:333:333:A:C603:3FF:FEF0:0 update−source Loopback0
   neighbor AB01:CD1:123:C:C604:16FF:FE98:0 remote−as 101
   neighbor AB01:CD1:123:C:C604:16FF:FE98:0 ebgp−multihop 5
!
address−family ipv6
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 activate
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 next−hop−self
   neighbor 3333:333:333:A:C603:3FF:FEF0:0 activate
   neighbor 3333:333:333:A:C603:3FF:FEF0:0 next−hop−self
   neighbor AB01:CD1:123:C:C604:16FF:FE98:0 activate exit−address−family
 
On R2:
interface Loopback0
   ipv6 address 2222:222:222:A::/64 eui−64
   ipv6 ospf 10 area 0
!
interface FastEthernet0/0
   ipv6 address AB01:CD1:123:A::/64 eui−64
   ipv6 ospf 10 area 0
!
interface FastEthernet0/1
   ipv6 address AB01:CD1:123:D::/64 eui−64
   ipv6 ospf 10 area 0
!
   ipv6 router ospf 10 router−id 2.2.2.2 log−adjacency−changes
!
router bgp 123
bgp router−id 2.2.2.2
   neighbor 1111:111:111:A:C601:3FF:FEF0:0 remote−as 123
   neighbor 1111:111:111:A:C601:3FF:FEF0:0 update−source Loopback0
   neighbor 3333:333:333:A:C603:3FF:FEF0:0 remote−as 123
   neighbor 3333:333:333:A:C603:3FF:FEF0:0 update−source Loopback0
 
address−family ipv6
   neighbor 1111:111:111:A:C601:3FF:FEF0:0 activate
   neighbor 3333:333:333:A:C603:3FF:FEF0:0 activate
exit−address−family
 
On R3:
interface Loopback0
   ipv6 address 3333:333:333:A::/64 eui−64
   ipv6 ospf 10 area 0
!
interface FastEthernet0/0
   ipv6 address AB01:CD1:123:B::/64 eui−64
   ipv6 ospf 10 area 0
!
interface Serial0/0
   ipv6 address AB01:CD1:123:E::/64 eui−64
!
interface FastEthernet0/1
   ipv6 address AB01:CD1:123:D::/64 eui−64
   ipv6 ospf 10 area 0
!
ipv6 router ospf 10
   router−id 3.3.3.3
   redistribute connected route−map CONNECTED
!
router bgp 123
   no synchronization
   bgp router−id 3.3.3.3
   neighbor 1111:111:111:A:C601:3FF:FEF0:0 remote−as 123
   neighbor 1111:111:111:A:C601:3FF:FEF0:0 update−source Loopback0
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 remote−as 123
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 update−source Loopback0
   neighbor AB01:CD1:123:E:C605:16FF:FE98:0 remote−as 202
   neighbor AB01:CD1:123:E:C605:16FF:FE98:0 ebgp−multihop 5
!
address−family ipv6
   neighbor 1111:111:111:A:C601:3FF:FEF0:0 activate
   neighbor 1111:111:111:A:C601:3FF:FEF0:0 next−hop−self
   neighbor 1111:111:111:A:C601:3FF:FEF0:0 route−map LOCAL_PREF out
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 activate
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 next−hop−self
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 route−map LOCAL_PREF out
   neighbor AB01:CD1:123:E:C605:16FF:FE98:0 activate
exit−address−family
!
ipv6 prefix−list 10 seq 5 permit BC01:BC1:10:A::/64
!
route−map LOCAL_PREF permit 10
   match ipv6 address prefix−list 10
   set local−preference 500
!
route−map LOCAL_PREF permit 20
!
route−map CONNECTED permit 10
   match interface Serial0/0
On R4:
interface Serial0/0
   ipv6 address AB01:CD1:123:C::/64 eui−64
!
interface Loopback10
   ipv6 address BC01:BC1:10:A::/64 eui−64
!
interface Loopback11
   ipv6 address BC02:BC1:11:A::/64 eui−64
!
interface Loopback12
   ipv6 address BC03:BC1:12:A::/64 eui−64
 
router bgp 101
bgp router−id 4.4.4.4
   neighbor AB01:CD1:123:C:C601:3FF:FEF0:0 remote−as 123
!
address−family ipv6
   neighbor AB01:CD1:123:C:C601:3FF:FEF0:0 activate
   network BC01:BC1:10:A::/64 network BC02:BC1:11:A::/64
   network BC03:BC1:12:A::/64 exit−address−family
On R5:
interface Serial0/0
   ipv6 address AB01:CD1:123:E::/64 eui−64
   clock rate 2000000
!
interface Loopback10
   ipv6 address BC01:BC1:10:A::/64 eui−64
!
interface Loopback11
   ipv6 address BC02:BC1:11:A::/64 eui−64
!
interface Loopback12
   ipv6 address BC03:BC1:12:A::/64 eui−64
!
router bgp 202
bgp router−id 5.5.5.5
   neighbor AB01:CD1:123:E:C603:3FF:FEF0:0 remote−as 123
   neighbor AB01:CD1:123:E:C603:3FF:FEF0:0 ebgp−multihop 5
!
address−family ipv6
   neighbor AB01:CD1:123:E:C603:3FF:FEF0:0 activate
   network BC01:BC1:10:A::/64
   network BC02:BC1:11:A::/64
   network BC03:BC1:12:A::/64
exit−address−family
 

To verify the route, use the show bgp ipv6 unicast command:

On R2:
R2> show bgp ipv6 unicast

Before the local preference is configured, R2 has R1 as its next hop for all learned IPv6 addresses. After configuring the local preference on R3 to 500, R2 has a different preferred exit route for prefix BC01:BC1:10:A::/64. R2 can now reach prefix BC01:BC1:10:A::/64 through the exit path of R3, which is now designated as the local preference.

BGP Peer Group Update Policies

A BGP peer group is a group of BGP neighbors that share the same update policies. Update policies are typically set by route maps, distribution lists, and filter lists.

When you define a peer group and add neighbors to it, all of the update policies that you assign to that peer group apply to all of the neighbors in that peer group. You do not need to define a policy for each neighbor.

Members of a peer group inherit all of the configuration settings of that peer group. You can configure certain members to override the update policies, but only if those policies are set for inbound traffic. You cannot configure members to override group policies if the policies apply to outbound traffic.

BGP Peer Group Update Policies Configuration

To configure an IPv6 BGP peer group and its update policies:

On R3:
router bgp 123
   no synchronization
   bgp router−id 3.3.3.3
neighbor interalmap peer-group
   neighbor interalmap remote-as 123
   neighbor 1111:111:111:A:C601:3FF:FEF0:0 peer-group interalmap
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 peer-group interalmap
   neighbor AB01:CD1:123:E:C605:16FF:FE98:0 remote−as 202
   neighbor AB01:CD1:123:E:C605:16FF:FE98:0 ebgp−multihop 5
!
address−family ipv6
   neighbor interalmap activate
   neighbor interalmap route-map 1 out
   neighbor 1111:111:111:A:C601:3FF:FEF0:0 peer-group interalmap
   neighbor 2222:222:222:A:C602:3FF:FEF0:0 peer-group interalmap
exit−address−family
!
ipv6 prefix−list 10 seq 5 permit BC01:BC1:10:A::/64
!
route-map 1 permit 10
   match ipv6 address prefix-list 1 set tag 333
   set metric 273
   set local-preference 312

To verify that the correct local preference route is configured, use the show bgp ipv6 unicast command:

On R3:
R3> show bgp ipv6 unicast

Verify that IPv6 address BC01:BC1:10:A::/64 passes from AS100 to R1 and R2, and that the metric and local preference are set to the corresponding route-map settings.

BGP Confederation

You can divide a single AS into multiple ASs, and then assign these multiple ASs to a single confederation of ASs. The implementation of a BGP confederation reduces the iBGP mesh size of the AS, and the confederation can still advertise as a single AS to external peers.

Each individual AS within a confederation runs fully meshed iBGP, and each individual AS within the confederation also runs eBGP connections to the other ASs inside the confederation. These eBGP peers within the confederation exchange routing information as if they used iBGP. In this way, the confederation preserves next hop, metric, and local preference information. To the outside world, the confederation appears to be a single AS.

BGP Confederation Configuration

To configure a BGP Confederation:

R1:

router bgp 2000
   bgp log-neighbor-changes
   bgp confederation identifier 200
   bgp confederation peers 1000
   neighbor 2003::1 remote-as 1000
!
address-family ipv4
   neighbor 2003::1 activate
exit-address-family
!
address-family ipv6
   network 3002::/64
   network 4000::/64
   neighbor 2003::1 activate
exit-address-family
On R2:
router bgp 1000
   bgp confederation identifier 200
   neighbor 10.0.1.1 remote-as 1000
!
address-family ipv6
   neighbor 10.0.1.1 activate
exit-address-family
 
On R3:
router bgp 1000
   bgp confederation identifier 200
   bgp confederation peers 2000
   neighbor 10.0.1.2 remote-as 1000
   neighbor 3001::1 remote-as 2000
   neighbor 5000::1 remote-as 100
   neighbor 5000::1 update-source X2
!
address-family ipv6
   neighbor 10.0.1.2 activate
   neighbor 3001::1 activate
   neighbor 5000::1 activate
exit-address-family
 
On R5:
router bgp 100
   bgp router-id 5.5.5.5
   bgp log-neighbor-changes
   neighbor 2002::1 remote-as 200
!
address-family ipv6
   network 6666::6/128
   network 7777::7/128
   neighbor 2002::1 activate
exit-address-family
 

Verify that R1, R2, and R3 can learn this route that is advertised by R5:

6666::6/128 and 7777::7/128

Verify that R2 can learn this route from R1 even though they are not directly connected:

3002::/64 and 4000::/64
 
* 
NOTE: The IPv6 BGP configuration data and the IPv6 BGP routes are dumped into a Terminate and Stay Resident (TSR) file.
* 
NOTE: IPv6 BGP uses the ZebOS debug interface. The default setting for all debug switches is closed. Entering the CLI debug command on the console opens the debug switch.

BGP Terms

ARD – Autonomous Routing Domain – A collection of networks/routers that have a common administrative routing policy.

AS - Autonomous System – An ARD that has been assigned an identifying number, typically running BGP4 at its border router(s).

BGP4 - Border Gateway Protocol 4: The most prevalent EGP.

CIDR – Classless inter-domain routing, enables efficient route advertisement through route aggregation.

CPE – Customer Premise Equipment - The equipment at the edge of a customer's network used to interface with the ISP.

EGP - Exterior Gateway Protocol – Any protocol (in practice, BGP4) used to communicate routing information between Autonomous Systems.

Full-Routes - The entire global BGP route table.

FIB - Forwarding Information Base – Our existing route table, used to find the egress interface and next hop when forwarding packets.

Looking Glass* - A Looking Glass (LG) server is a read-only view of routers of organizations running the LG servers. Typically, publicly accessible looking glass servers are run by ISPs or NOCs.

Multi-Homed - An ISP customer that has multiple connections to one or more ISPs.

Multi-Provider - An ISP customer that uses multiple ISPs to connect to the Internet.

NSM – Network Services Module - The ZebOS component that centralizes the interface to the FIB and RIB. The separate routing protocol daemons interface with the NSM for all RIB updates. NSM alone updates the FIB with best-route information from the RIB. 

Partial Routes - A subset of the full BGP route table, usually specific to destinations that are part of an ISP's domain.

RIB - Route Information Base – A run-time database owned by the NSM, and used to store all route information gathered and used by the routing protocols.

IPv6

Topics:

About IPv6

This section provides an overview of the SonicOS implementation of IPv6, how IPv6 operates, and how to configure IPv6 for your network.

Topics:

IPv6 Ready Certification

SonicWALL has met the requirements for "IPv6 Ready" Phase-1 and Phase-2, as specified by the IPv6 Forum, a world-wide consortium providing technical guidance for the deployment of IPv6. The IPv6 Ready Logo Program is a conformance and interoperability testing program intended to increase user confidence by demonstrating that IPv6 is available now and ready to be used.

The IPv6 Ready series of tests extends from a basic level of minimum coverage in Phase-1 to a more complete coverage with Phase-2:

Phase-1 (Silver) Logo: In a first stage, the Logo indicate that the product includes IPv6 mandatory core protocols and can interoperate with other IPv6 implementations.
Phase-2 (Gold) Logo: The "IPv6 ready" step implies a proper care, technical consensus and clear technical references. The IPv6 Ready Logo will indicate that a product has successfully satisfied strong requirements stated by the IPv6 Logo Committee (v6LC).

SonicWALL has been certified for Phase 2 (Gold) IPv6 Ready status. A future Phase-3 level of IPv6 Ready coverage is currently being developed.

For more information, see: http://www.ipv6ready.org/

IPv6 Technology Overview

Every device that is connected to the Internet (computer, printer, smart phone, smart meter, etc.) requires an IP address. The Internet Protocol version 4 (IPv4) provides for approximately 4.3 billion unique IP addresses. The rapid global expansion in usage of the Internet, mobile phones, and VoIP telephony will soon lead to the exhaustion of these 4.3 billion IP addresses.

On February 3rd, 2011, the Internet Assigned Numbers Authority (IANA) distributed the last-remaining blocks of IPv4 addresses to the Regional Internet Registries (RIRs). After the RIRs distribute these addresses to ISPs later this year, the world’s supply of new IPv4 addresses will be exhausted.

Luckily, the Internet Engineering Task Force (IETF) began planning for this day back around 1992, and in 1998, RFC 2460 was published to define Internet Protocol, Version 6 (IPv6). By increasing the address length from 32 bits to 128 bits, IPv6 dramatically increases the number of available addresses compared to IPv4:

IPv4: 4,294,967,296 addresses
IPv6: 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses

Understanding IPv6 Addresses

IPv6 addresses are written in eight groups of four hexadecimal digits separated by colons, in the form:

XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX

IPv6 addresses are logically divided into two parts: a 64-bit (sub-)network prefix, and a 64-bit interface identifier. Here is an example of an IPv6 address:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

* 
NOTE: The hexadecimal digits in IPv6 addresses are case-insensitive.

IPv6 address can be abbreviated using the following two rules:

1
Leading zeroes within a 16-bit value may be omitted. Thus, our example address can be abbreviated from the full form:
2001:0db8:85a3:0000:0000:8a2e:0370:7334

to this abbreviated form:

2001:db8:85a3:0:0:8a2e:370:7334
2
Any number of consecutive groups of four zeros (technically 16-bits of zeros) can be expressed by a double colon (the “::” symbol). Combing these two rules, our example address can be abbreviated from the full form:
2001:0db8:85a3:0000:0000:8a2e:0370:7334

to this abbreviated form:

2001:db8:85a3::8a2e:370:7334
 

IPv6 Full and Abbreviated Addresses

Type of Address

Full Address

Abbreviated Address

unicast address

1080:0:0:0:8:800:200C:417A
1080::8:800:200C:417A

multicast address

FF01:0:0:0:0:0:0:101
FF01::101

loopback address

0:0:0:0:0:0:0:1
::1

unspecified address

0:0:0:0:0:0:0:0
::
* 
NOTE: Networks must have IPv4 internet connectivity in order to get connected to IPv6 internet.
* 
NOTE: IPv6 stack must be enabled for computers at the local network sites.

Here is a simplified picture showing connectivity model for a typical IPv6 deployment.

Typical IPv6 Deployment

The following diagram shows a comparison of the header elements between IPv4 and IPv6.

IPv4 and IPv6 Header Element Comparison

IPv6 Benefits

IPv6 brings some key features to improve the limitations exposed by IPv4. The new IP standard extends IPv4 in a number of important aspects:

6to4 tunnel (allows IPv6 nodes to connect to outside IPv6 services over an IPv4 network)
6to4 Auto Tunnel
GRE Tunnel
IPv6 Manual Tunnel
New, simplified IPv6 header format
Massively large number of available IPv6 addresses
Efficient and hierarchical addressing and routing infrastructure
Auto address assignment to hosts and routers using Neighbor Discovery Protocol (NDP) and DHCPv6
Stateless and stateful address configuration
Built-in security - AH and ESP strongly recommended
Better support for QoS - Flow label in the header
New protocol for neighboring node interaction
Extensibility for new features using extension headers

IPv6 BGP

IPv6 BGP is supported in SonicOS 5.9.0.2. For information on configuring IPv6 BGP, refer to the IPv6 BGP of About BGP Advanced Routing.

IPv6 Support on Backend Servers

SonicWALL provides backend servers that maintain IPv6 address records (AAAA records).

SonicWALL supports IPv6 on the following SonicWALL backend servers:

License Manager Servers
Signature download Servers
Content Filtering Service (CFS) Servers
Dashboard Servers
My sonicWALL Servers
Online Help Servers
Software Update Servers
Auto Software Upgrade Servers
Download NetExtender Servers
Download SonicPoint Image Servers

SonicWALL does not support IPv6 on the following SonicWALL backend servers:

DRP Servers
Responder Servers
Anti-spam Servers
Cloud AV Servers
Enforce AV Servers
Geo-IP Servers
App Report Servers
* 
NOTE: A SonicWALL network security appliance will use an IPv6 address to connect to a backend server only when no IPv4 address can be resolved.

A SonicWALL network security appliance queries for IPv6 addresses for backend servers as follows:

1
If an IPv4 DNS server is available, the firewall queries the IPv4 DNS server for an IPv4 address (A record) first. If resolved, the firewall uses the returned IPv4 address to connect to the backend server.
2
If no IPv4 DNS server is available or if no IPv4 address is found, the firewall then searches for an IPv6 DNS server. If an IPv6 DNS server is found, the firewall queries for an IPv6 address (AAAA record). If one is found, it uses that address to connect to the backend server.
3
If no IPv6 address is resolved, the connection fails.

The firewall will use which ever type of IP address is returned, whether it is an IPv4 address (A record) or and IPv6 address (AAAA record).

If the firewall is configured to retry the query, the firewall will keep querying until the time-out period ends.

SonicWALL IPv6 Feature Support

The following is a list of IPv6 services and features that are currently supported by SonicWALL:

Access Rules
Address Objects
Advanced Bandwidth Management:
Bandwidth Management Monitor
Anti-Spyware
App Flow Server:
IPv6 App Flow generating to App Flow Server
IPv6 App Flow generating to 3rd party App Flow Server
Application Firewall:
App Rules
Attack prevention:
Land Attack
MAC Anti-spoof
Ping of Death
Smurf
SYN Flood
Client Anti-Virus Enforcement
Connection Cache
Connection Monitor:
IPv6 Address Filtering
Content Filtering:
ActiveX, Java, Cookies Restriction
CFS Custom List
CFS Exclusion List
Content Filtering Service
Keywords Blocking
DHCP:
DHCP Server
Dynamic Lease Scope
Generic Options
Integrated Options (DNS/WINS Server)
Lease Persistence
Static Lease Scope
Diagnostics:
Nslookup
Ping6
Reverse Nslookup
Traceroute
DNS client
DNS lookup and reverse name lookup
Dual Stack IPv4 and IPv6
EPRT
EPSV
FTPv6
Flood Protection:
TCP Sync Proxy
Fragmentation Handling
Gateway Anti-Virus
Header Validation
High Availability:
Connection Cache
DHCP Server
FTP
Monitoring IP
NDP
SonicPoint
VPN
HTTP/HTTPS management over IPv6
ICMPv6
IDP
IKEv2
Interface
DHCP Client Mode
IPv6 Interface
Layer 2 Bridge Mode
PPPoE Client Mode
Intrusion Prevention Service
IP Spoof Protection
IPv4 Syslog messages, including messages with IPv6 addresses
IPv6 BGP
IPv6 Connection Limit
IPv6 for Backend Servers
Layer 2 Bridge Mode
Log:
IPv6 Address Log Entry
Logging IPv6 events
Login uniqueness
Multicast Routing with Multicast Listener Discovery
NAT
NAT load balancing
Neighbor Discovery Protocol
NetExtender connections for users with IPv6 addresses
NDP
OSPFv3
Packet Capture
Ping
Policy Based Routing
Reassemble Handling
Remote management
RIPng
Routing
Security services for IPv6 traffic with DPI
Site-to-site IPv6 tunnel with IPsec for security
SonicPoint IPv6 support
SSL VPN
Stateful inspection of IPv6 traffic
Syslog:
IPv4 syslog messages to include IPv6 address
Tunneling
IPv4 to IPv6 tunneling
IPv6 to IPv4 tunneling
Users:
IPv6 User Login and Management
Login Uniqueness
User status
Visualization
App Flow Monitor
App Flow Report
Real-Time Monitor
Threat Report
User Monitor
VLAN:
IPv6 VLAN in Layer 2 Bridge Mode
IPv6 VLAN Interface
VPN policies
Wireless
Wired Mode

SonicWALL IPv6 Features Not Currently Supported

The following is a list of IPv6 services and features that are not currently supported by SonicWall.

* 
NOTE: SonicOS 5.9 is a dual IP stack firmware. Features that are not supported for IPv6 are still supported for IPv4.
Address Objects:
DAO
FQDN
Anti-Spam
Botnet Filter
Command Line Interface
Connect App Flow Server with IPv6 Address
Content Filtering:
CFS Policy per IP Address Range
Websense Enterprice
DHCP over VPN
DHCP Relay
DPI-SSL
Dynamic Address Objects for IPv6 addresses
Dynamic DNS
E-CLI Configuration
Flood Protection:
ICMP
UDP
FQDN
GeoIP Filter
Global VPN Client (GVC)
GMS
VPN:
DHCP over VPN
Group VPN
IKE
IKE DPD
L2TP Server
Mobile IKEv2
OCSP
Route Based VPN
H.323
High Availability:
Multicast v6
Oracle SQL/Net
RTSP
ULA v6
VoIP
IKEv1
Interface:
L2TP Client Mode
Transparent Mode
Wired Mode
IP Helper
IPv6 Syslog messages
ISATAP
LDAP
Log:
Logs from IPNET Stack
Log DNS Name Resolution
MAC-IP Anti-Spoof
Multicast Proxy
Multicast Routing
NAT between IPv6 and IPv4 addresses
IPv4 to IPv6 NAT
IPv6 to IPv4 NAT
NetBIOS over VPN
Network Monitor
NTP
QoS Mapping
RADIUS
RAS Multicast Forwarding
RBL
Route-based VPNs
Single Sign On
SMTP Real-Time Black List (RBL) Filtering
SNMP
SSH
SSL Control
SSL-VPN
Stateful Protocol:
Oracle SQL/Net
SIP
Syslog:
IPv6 syslog messages to include IPv6 address
Users:
Guest Service
LDAP
Radius
SSO
ViewPoint
Virtual Assistant
VLAN:
DHCP Client Mode
L2TP Client Mode
PPPoE Client Mode
VoIP
WAN Acceleration
WAN Load Balance
Web proxy

Supported IPv6 RFCs

This section lists the IPv6 RFCs that are supported in SonicOS 5.9:

TCP/IP stack and Network Protocols

RFC 1886 DNS Extensions to support IP version 6 [IPAPPL dns client]
RFC 1981 Path MTU Discovery for IPv6
RFC 2113 IP Router Alert Option
RFC 2373 IPv6 Addressing Architecture
RFC 2374 An IPv6 Aggregatable Global Unicast Address Format (obsoleted by 3587)
RFC 2375 IPv6 Multicast Address Assignments
RFC 2460 IPv6 specification
RFC 2461 Neighbour discovery for IPv6
RFC 2462 IPv6 Stateless Address Autoconfiguration
RFC 2463 ICMPv6 for IPv6 specification
RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
RFC 2473 Generic Packet Tunneling in IPv6 Specification
RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
RFC 2553 Basic Socket Interface Extensions for IPv6
RFC 2710 Multicast Listener Discovery (MLD) for IPv6
RFC 2711 IPv6 Router Alert Option
RFC 2784 Generic Routing Encapsulation
RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers
RFC 2991 Multipath Issues in Unicast and Multicast Next-Hop Selection
RFC 3056 Connection of IPv6 Domains via IPv4 Clouds
RFC 3484 Default Address Selection for Internet Protocol version 6 (IPv6) (no policy hooks)
RFC 3493 Basic Socket Interface Extensions for IPv6
RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture
RFC 3542 Advanced Sockets Application Program Interface (API) for IPv6
RFC 3587 IPv6 Global Unicast Address Format (obsoletes 2374)

IPsec Conformance

RFC 1826 IP Authentication Header [old AH]
RFC 1827 IP Encapsulating Security Payload (ESP) [old ESP]

NAT Conformance

RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations.
RFC 3022 Traditional IP Network Address Translator (Traditional NAT).

DNS Conformance

RFC 1886 DNS Extensions to support IP version 6

Non-Supported IPv6 RFCs

This section lists the IPv6 RFCs that are currently not supported in SonicOS 5.9.

RFC 2002 IP Mobility Support
RFC 2766 Network Address Translation - Protocol Translation (NAT-PT)
RFC 2472 IP Version 6 over PPP
RFC 2452 IP Version 6 Management Information Base for the Transmission Control Protocol.
RFC 2454 IP Version 6 Management Information Base for the User Datagram Protocol.
RFC 2465 Management Information Base for IP Version 6: Textual Conventions and General Group.

IPv6 Interface Configuration

IPv6 interfaces are configured on the Network > Interfaces page by clicking the IPv6 option for the View IP Version radio button at the top right corner of the page.

By default, all IPv6 interfaces appear as routed with no IP address. Multiple IPv6 addresses can be added on the same interface. Auto IP assignment can only be configured on WAN interfaces.

Each interface can be configured to receive router advertisement or not. IPv6 can be enabled or disabled on each interface.

* 
NOTE: The zone assignment for an interface must be configured through the IPv4 interface page before switching to IPv6 mode.

The following sections describe IPv6 interface configuration:

IPv6 Interface Configuration Constraints

The HA interface cannot be configured for IPv6.
Only the parent interface of a SwitchPort group can be configured as an IPv6 interface, hence all children of a switch port group must be excluded from this list.
Zone and Layer 2 Bridge groups are shared configurations between by IPv4 and IPv6 on an interface. Once they are configured on the IPv4 side, the IPv6 side of the interface will use the same configuration.
Default Gateway and DNS Servers can only be configured for WAN zone interfaces.
VLAN interfaces are not currently supported.

Configuring an Interface for IPv6 Static Mode

Static mode provides user a way to assign static IPv6 address as opposed to an auto-assigned address. Using static mode, the IPv6 interface can still listen for Router Advertisements and learn an autonomous address from the appropriate prefix option. Static Mode does not disturb the running of Stateless Address Autoconfiguration on IPv6 interface unless the user manually disables it.

The following diagram shows a sample topology with IPv6 configured in static mode.

Sample IPv6 Static Mode Configuration

Three types of IPv6 address are possible to assign under this mode:

Automatic Address
Autonomous Address
Static Address
To configure an interface for a static IPv6 address:
1
Navigate to the Network > Interfaces page.
2
Click on the IPv6 button at the top right corner of the page. IPv6 addresses for the appliance are displayed.
3
Click on the Configure icon for the interface you want to configure an IPv6 address for. The Edit Interface dialog displays.
* 
NOTE: The zone assignment for interfaces must be configured on the IPv4 addressing page. To modify the zone assignment for an IPv6 interface, click the IPv4 button at the top right of the page, modify the zone for the interface, and then return to the IPv6 interface page.

4
In the IP Assignment drop-down menu, select Static.
5
Enter the IPv6 Address for the interface.
6
Enter the Prefix Length for the address.
7
If this is the primary WAN interface, enter the IPv6 address of the Default Gateway. If this is not the primary WAN interface, any Default Gateway entry will be ignored, so you can leave this as ::. (The double colon is the abbreviation for an empty address, or 0:0:0:0:0:0:0:0.)
8
If this is the primary WAN interface, enter up to three DNS Server IPv6 addresses. Again, if this is not the primary WAN interface, any DNS Server entries will be ignored.
9
Select Enable Router Advertisement to make this an advertising interface that distributes network and prefix information.
10
Select Advertise Subnet Prefix of IPv6 Primary Static Address to add a default prefix into the interface advertising prefix list. This prefix is the subnet prefix of interface IPv6 primary static address. This option will help all hosts on the link stay in the same subnet.

Configuring Advanced IPv6 Interface Options and Multiple IPv6 Addresses

Perform the following steps to modify Advanced IPv6 interface options or to configure multiple static IPv6 addresses.
1
In the Edit Interface window, click on the Advanced tab.

2
Click the Add Address button to configure multiple static IPv6 addresses for the interface.

* 
NOTE: Multiple IPv6 addresses can only be added for an interface that is configured for Static IPv6 address mode. Multiple IPv6 addresses cannot be configured for Auto or DHCPv6 modes.
3
Enter the IPv6 Address for the additional address for the interface.
4
Enter the Prefix Length for the address.
5
Select Advertise Subnet Prefix of IPv6 Primary Static Address to add a default prefix into the interface advertising prefix list. This prefix is the subnet prefix of interface IPv6 primary static address. This option will help all hosts on the link stay in the same subnet.
6
Click OK.
7
The following additional options can be configured on the Advanced tab under the Advanced Settings heading:
Select Disable all IPv6 Traffic on the Interface to stop the interface from handling all IPv6 traffic. Disabling IPv6 traffic can improve firewall performance for non-IPv6 traffic. If the firewall is deployed in a pure IPv4 environment, SonicWALL recommends enabling this option.
Select Enable Listening to Router Advertisement to have the firewall receive router advertisement. If disabled, the interface filters all incoming Router Advertisement message, which can enhance security by eliminating the possibility of receiving malicious network parameters (for example, prefix information or default gateway). This option is not visible for Auto mode. In Auto mode, it is always enabled.
Select Enable Stateless Address Autoconfiguration to allow autonomous IPv6 addresses to be assigned to this interface. If unchecked, all assigned autonomous IPv6 address will be removed from this interface. This option is not visible for Auto mode. In Auto mode, it is always enabled.
Enter a numeric value for Duplicate Address Detection Transmits to specify the number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection (DAD) before assigning a tentative address to interface. A value of 0 indicates that DAD is not performed on the interface.

Similar with IPv4 gratuitous ARP, IPv6 node uses Neighbor Solicitation message to detect duplicate IPv6 address on the same link. DAD must be performed on any Unicast address (except Anycast address) before assigning a tentative to an IPv6 interface.

Configuring Router Advertisement Settings

Router Advertisement allows IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts. Router Advertisement-based DNS configuration is a useful, optional alternative in networks where an IPv6 host's address is autoconfigured through IPv6 stateless address autoconfiguration, and where the delays in acquiring server addresses and communicating with the servers are critical. Router Advertisement allows the host to acquire the nearest server addresses on every link. Furthermore, it learns these addresses from the same RA message that provides configuration information for the link, thereby avoiding an additional protocol run. This can be beneficial in some mobile environments, such as with Mobile IPv6. SonicWALL’s implementation of IPv6 is full conformable with RFC 4861 in Router and Prefix Discovery.

* 
NOTE: Router Advertisement can only be enabled when interface is under Static mode.
To configure Router Advertisement for an IPv6 interface:
1
In the Edit Interface window, click on the Router Advertisement tab.

2
Select the Enable Router Advertisement check box to have make this an advertising interface that will distribute network and prefix information.
3
Optionally, you can modify the following Router Advertisement settings:
Router Adv Interval Range - The time interval allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds.
Link MTU - The recommended MTU for the interface link. A value of 0 means firewall will not advertise link MTU for the link.
Reachable Time - The time that a node assumes a neighbor is reachable after having received a reachability confirmation. A value of 0 means this parameter is unspecified by this firewall.
Retrans Time - The time between retransmitted Neighbor Solicitation messages. A value of 0 means this parameter is unspecified by this firewall.
Current Hop Limit - The default value that should be placed in the Hop Count field of the IP header for outgoing IP packets. A value of 0 means this parameter is unspecified by this firewall.
Router Lifetime - The lifetime when firewall is accepted as a default router. A value of 0 means that the router is not a default router.
4
Select the Managed check box to set the managed address configuration flag in the Router Advertisement message. If set, it indicates that IPv6 addresses are available via Dynamic Host Configuration Protocol.
5
Select the Other Configuration check box to set the Other configuration flag in Router Advertisement message. If set, it indicates that other configuration information is available via Dynamic Host Configuration Protocol.

Configuring Router Advertisement Prefix Settings

1
Click the Add Prefix button to configure an advertising prefix. Advertising prefixes are used for providing hosts with prefixes for on-link determination and Address Autoconfiguration.

2
Enter the Prefix that is to be advertised with the Router Advertisement message.
3
Enter the Valid Lifetime to set the length of time (in minutes) that the prefix is valid for the purpose of on-link determination. A value of “71582789” means the lifetime is infinite.
4
Enter the Preferred Lifetime to set the length of time that addresses generated from the prefix via stateless address autoconfiguration remain preferred. A value of “71582789” means the lifetime is infinite.
5
Optionally click the On-link check box to enable the on-link flag in Prefix Information option, which indicates that this prefix can be used for on-link determination.
6
Optionally click the Autonomous check box to enable the autonomous address-configuration flag in Prefix Information option, which indicates that this prefix can be used for stateless address configuration.
7
Click OK.

Configuring an Interface for DHCPv6 Mode

DHCPv6 (DHCP for IPv6) is a client/server protocol that provides stateful address configuration or stateless configuration setting for IPv6 hosts. DHCPv6 client is enabled to learn IPv6 address and network parameters when interface is configured to DHCPv6 mode.

DHCPv6 defines two different configuration modes:

DHCPv6 stateful mode: DHCPv6 clients require IPv6 address together with other network parameters (for example, DNS Server, Domain Name, etc.).
DHCPv6 stateless mode: DHCPv6 client only obtains network parameters other than IPv6 address. Choosing which kind of those modes depends on Managed (M) Address Configuration and Other (O) Configuration flag in the advertised Router Advertisement message:
M = 0, O = 0: No DHCPv6 infrastructure.
M = 1, O = 1: IPv6 host use DHCPv6 for both IPv6 address and other network parameter settings.
M = 0, O = 1: IPv6 hosts use DHCPv6 only for other network parameter settings, which is known as DHCPv6 stateless.
M = 1, O = 0: IPv6 hosts use DHCPv6 for IPv6 address assignment. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information.

The following diagram shows a sample DHCPv6 topology.

Sample DHCPv6 Configuration

There are three types of IPv6 addresses that can be assign under DHCPv6:

Automatic Address
Autonomous Address
IPv6 Address assigned through DHCPv6 client
To configure an interface for a DHCPv6 address:
1
Navigate to the Network > Interfaces page.
2
Click on the IPv6 button at the top right corner of the page. IPv6 addresses for the appliance are displayed.
3
Click on the Configure icon for the interface you want to configure an IPv6 address for. The Edit Interface dialog displays.
4
In the IP Assignment drop-down menu, select DHCPv6.

5
The following options can be configured for IPv6 interfaces configured for DHCPv6 mode:
Use Rapid Commit Option - If enabled, DHCPv6 client use Rapid Commit Option to use the two message exchange for address assignment.
Send hints for renewing previous IP on startup - If enabled, DHCPv6 client will try to renew the address assigned before when firewall startup.
6
Set the DHCPv6 Mode for the interface. As required by RFC, DHCPv6 client depends on Router Advertisement message to decide which mode (stateful or stateless) it should choose. This definition will limit user's choice if they want to determine DHCPv6 mode by itself. SonicWALL’s implementation of DHCPv6 defines two different modes to balance the conformance and flexibility:
Automatic - In this mode, IPv6 interface configures IPv6 addresses using stateless/stateful autoconfiguration in accord with the M and O settings in the most recently received router advertisement message.
Manual - In Manual mode, DHCPv6 mode is manually configured regardless of any received Router Advertisement. The Only Request Stateless Information option will determine which DHCPv6 mode is used. If this option is unchecked, DHCPv6 client is under stateful mode; if it is checked, DHCPv6 client is under stateless mode and only obtains network parameters.
7
Optionally, select the Only Request Stateless Information check box to have DHCPv6 clients only requests network parameter setting from the DHCPv6 server. The IPv6 address is assigned through stateless auto-configuration.
8
Click OK to complete the configuration, or click the Advanced tab to configure Advanced options or click the Protocol tab to view DHCPv6 stateful and stateless configuration information.

Configuring Advanced Settings for an IPv6 Interface

The following options can be configured on the Advanced tab of the IPv6 Edit Interface window:

Select Disable all IPv6 Traffic on the Interface to stop the interface from handling all IPv6 traffic. Disabling IPv6 traffic can improve firewall performance for non-IPv6 traffic. If the firewall is deployed in a pure IPv4 environment, SonicWALL recommends enabling this option.
Select Enable Listening to Router Advertisement to have the firewall receive router advertisement. If disabled, the interface filters all incoming Router Advertisement message, which can enhance security by eliminating the possibility of receiving malicious network parameters (for example, prefix information or default gateway). This option is not visible for Auto mode. In Auto mode, it is always enabled.
Select Enable Stateless Address Autoconfiguration to allow autonomous IPv6 addresses to be assigned to this interface. If unchecked, all assigned autonomous IPv6 address will be removed from this interface. This option is not visible for Auto mode. In Auto mode, it is always enabled.
Enter a numeric value for Duplicate Address Detection Transmits to specify the number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection (DAD) before assigning a tentative address to interface. A value of 0 indicates that DAD is not performed on the interface.

Similar with IPv4 gratuitous ARP, IPv6 node uses Neighbor Solicitation message to detect duplicate IPv6 address on the same link. DAD must be performed on any Unicast address (except Anycast address) before assigning a tentative to an IPv6 interface.

DHCPv6 Protocol Tab

When configuring an IPv6 interface in DHCpv6 mode, the Protocol tab displays additional DHCPv6 information.

The following information is displayed on the Protocol tab:

DHCPv6 State: If the interface is configured for Stateless mode, the DHCPv6 State will be Stateless. If the interface is configured for Stateful mode, the DHCPv6 State will be either Enable or Disabled. When the interface is in Stateful, DHCPv6 mode, mousing over the icon to the left of the DHCPv6 State will display current Router Advertisement information for the interface.
DHCPv6 Server: The IPv6 address of the DHCPv6 server.
Stateful Addresses Acquired via DHCPv6: Displays information on any acquired stateful IPv6 addresses.
DNS Servers: The IPv6 addresses of any DNS Servers.

Configuring an Interface for Auto Mode

Auto mode utilities IPv6’s Stateless Address Autoconfiguration to assign IPv6 address. This mode does not require any manual address configuration by the network administrator. The firewall listens to the network and receives prefix information from neighboring routers. The IPv6 Stateless Address Autoconfiguration feature performs all configuration details, such as IPv6 address assignment, address deleting for address conflicting or lifetime expiration, and default gateway selection based on the information collected from on-link router.

* 
NOTE: Auto mode can only be configured for the WAN zone. For security consideration, Auto mode is not available on LAN zone interface.

The following diagram shows a sample topology for IPv6 configured in Auto mode.

Sample IPv6 Auto Mode Configuration

In this mode, two types of IPv6 address are possible to assign:

Automatic Address - The interface default link-local address. It is never timed out and is not able to be edited or deleted.
Autonomous Address - Assigned from Stateless Address Autoconfiguration. Users can manually delete the address if they do not want to wait for its valid lifetime expires.
To configure an IPv6 interface for Auto mode:
1
Navigate to the Network > Interfaces page.
2
Click on the IPv6 button at the top right corner of the page. IPv6 addresses for the appliance are displayed.
3
Click on the Configure icon for the interface you want to configure an IPv6 address for. The Edit Interface dialog displays.
4
In the IP Assignment drop-down menu, select Auto.

5
Optionally, you can select enter a numeric value for Duplicate Address Detection Transmits on the Advanced tab to specify the number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection (DAD) before assigning a tentative address to interface. A value of 0 indicates that DAD is not performed on the interface.
6
Click OK.

Configuring an Interface for PPPoE

Point-to-Point Protocol Over Ethernet (PPPoE) for IPv6 provides the ability to connect a network of hosts over a simple bridging access device to a remote Access Concentrator in the IPv6 network. Each host utilizes its own Point-to-Point Protocol stack and the user is presented with a familiar user interface. The access control, billing, and type of service can be done on a per-user basis, rather than a per-site. PPPoE for IPv4 and IPv6 use the same interface to avoid multiple PPPoE connections on the same interface, and PPPoE for IPv6 cannot be applied alone, it must be used with PPPoEv4 at the same time. This means you must configure the IPv4 assignment to PPPoE mode before configuring PPPoE for IPv6 on the interface. Once the PPPoE connection for IPv6 is established, it can also pass IPv4 traffic.and communicate beyond the local network.

To configure an interface for PPPoE with IPv6:
1
Navigate to the Network > Interfaces page in the Management Interface.
2
Configure an interface in IPv4 to use PPPoE.
3
Change the View IP Version radio button to IPv6.
4
Click the Configure icon for the desired interface.
5
Configure the interface parameters in the General and Protocol tabs.

Point-to-Point Protocol NCP negotiation can only negotiate the Link Local addresses, which are used to communicate within the local network, so a global address should be obtained to communicate beyond the local network.

6
To obtain a global address, configure the PPPoE global address acquired section in the General tab.

There are three ways for obtaining a global address:

Auto

The default global address is set to Auto, which provides a link local address.

a
Select Auto from the PPPoE Address Assignment drop-down list.
b
Click the OK button.
Static
a
Select Static mode from the PPPoE Address Assignment drop-down list.
b
Click the OK button.
DHCPv6
a
Select DHCPv6 from the PPPoEv6 Address Assignment drop-down list.
b
In the Advanced tab, click the Enable Listening to Router Advertisement and Enable Stateless Address Auto-configuration check boxes.
c
Click the OK button.

The PPPoE feature for IPv6 is now configured, to disable it, click the Disconnect button for the desired interface in the main Network > Interfaces page.

Configuring a VLAN Sub-interface

The procedure for configuring a VLAN Sub-interface in IPv6 is identical to that in IPv4. Refer to the Configuring VLAN Subinterfaces (NSA series) for details.

* 
NOTE: All VLAN Sub-interfaces must be configured in IPv4, before configuring them in IPv6.

Configuring an Interface for Wire Mode

IPv4 and IPv6 Wire Mode interfaces share the same configuration, so any changes made in the IPv4 configuration automatically reflect in the IPv6 configuration. For example, if the Disable Stateful Inspection option is enabled in IPv4, it will also be enabled in IPv6.

To configure an IPv6 interface for Wire Mode, first configure an IPv4 interface for Wire Mode, and then change the View IP Version to IPv6. Refer to Configuring Wire Mode (SonicWall NSA series appliances) for details on Wire Mode and configuration procedures.

* 
NOTE: All Wire Mode interface configurations and changes must be made in IPv4 before using them in IPv6.

Configuring IPv6 Tunnel Interfaces

This section describes how to tunnel IPv4 packets through IPv6 networks and IPv6 packets through IPv4 networks. For instance, in order to pass IPv6 packets through the IPv4 network, the IPv6 packet will be encapsulated into an IPv4 packet at the ingress side of a tunnel. When the encapsulated packet arrives at the egress of the tunnel, the IPv4 packet will be de-capsulated.

Tunnels can be either automatic or manually configured. A configured tunnel determines the endpoint addresses by configuration information on the encapsulating node. An automatic tunnel determines the IPv4 endpoints from the address of the embedded IPv6 datagram. IPv4 multicast tunneling determines the endpoints through Neighbor Discovery.

The following diagram depicts an IPv6 to IPv4 tunnel.

IPv6 to IPv4 Tunnel Configuration

The following sections describe IPv6 Tunnel Interface configuration:

Configuring the 6to4 Auto Tunnel

The 6to4 Auto Tunnel is an automatic tunnel: tunnel endpoints are extracted from the encapsulated IPv6 datagram. No manual configuration is necessary.

6to4 tunnels use a prefix of the form “2002:tunnel-IPv4-address::/48” to tunnel IPv6 traffic over IPv4. (for example, if the tunnel’s IPv4 endpoint has the address a01:203, the 6to4 tunnel prefix is “2002:a01:203::1.”) Routers advertise a prefix of the form “2002:[IPv4]:xxxx/64” to IPv6 clients. For complete information, see RFC 3056.

The following diagram shows a sample 6to4 auto tunnel topology.

Sample 6to4 Auto Tunnel Configuration

In the example, customers do not need to specify the tunnel endpoint, but only need to enable the 6to4 auto tunnel. All packets with a 2002 prefix will be routed to the tunnel, and the tunnel's IPv4 destination will be extract from the destination IPv6 address.

6to4 tunnels are easy to configure and use. Users must have a global IPv4 address and IPv6 address, which must also have a 2002 prefix. Therefore, in general, user can only access network resource with a 2002 prefix.

* 
NOTE: Only one 6to4 auto tunnel can be configured on the firewall.
To configure the 6to4 tunnel on the firewall:
1
Navigate to the Network > Interfaces page.
2
Click the Add Interface button.

3
Select the Zone for the 6to4 tunnel interface. This is typically the WAN interface.
4
In the Tunnel Type drop-down menu, select 6to4 Auto Tunnel Interface.
5
By default, the interface Name is set to 6to4AutoTun.
6
Select the Enable IPv6 6to4 Tunnel check box.
7
Optionally, you can configure Management login or User Login over the 6to4 tunnel.
8
Click OK.

Configuring 6to4 Relay for Non-2002 Prefix Access

By default, 6to4 auto tunnel can only access the destination with a 2002 prefix. The 6to4 relay feature can be used to access non-2002 prefix destinations. To enable 6to4 relay, simply create a Route Policy to route all traffic destined for 2003 prefixes over the 6to4 auto tunnel interface, as shown in the following example.

This static route can be added on the 6to4 auto tunnel interface to enable the relay feature, which makes it possible to access the IPv6 destination with non-2002: prefix through 6to4 tunnel. Note that, the gateway must be the IPv6 address with the 2002: prefix.

Configuring a Manual IPv6 Tunnel

To configure the 6to4 tunnel on the firewall:
1
Navigate to the Network > Interfaces page.
2
Click the Add Interface button.

3
Select the Zone for the tunnel interface.
4
In the Tunnel Type drop-down menu, select IPv6 Manual Tunnel Interface.
5
Enter a Name for the tunnel interface.
6
Enter the Remote IPv4 address for the tunnel endpoint.
7
For the Remote IPv6 network select an IPv6 Address object, which can be a group, range, network, or Host.
8
Optionally, you can configure Management login or User Login over the 6to4 tunnel.
9
Click OK.

Configuring a GRE IPv6 Tunnel

GRE can be used to tunnel IPv4 and IPv6 traffic over IPv4 or IPv6. GRE tunnels are static tunnels where both endpoints are specified manually. The following diagram shows a sample GRE IPv6 tunnel.

Sample GRE IPv6 Tunnel Configuration

The configuration of a GRE tunnel is similar to a manual tunnel, except GRE Tunnel Interface is selected for the Tunnel Type.

IPv6 Prefix Delegation

IPv6 Prefix Delegation, also known as DHCPv6 Prefix Delegation (DHCPv6-PD), is an extension to DHCPv6. In DHCPv6, addresses are assigned by a DHCPv6 server to an IPv6 host. In DHCPv6-PD, complete IPv6 subnet addresses and other parameters are assigned by a DHCPv6-PD server to a DHCPv6-PD client.

When DHCPv6-PD is enabled, it is applied to all DHCPv6 interfaces attached to the WAN zone. DHCPv6-PD is an additional subnet-configuration mode that co-exists with DHCPv6.

The IPv6 address is a combination of the prefix provided by the DHCPv6-PD server and the suffix provided by the DHCPv6-PD client. The prefix length is 64 by default, but can be edited.

When the firewall starts, a default address object group called Prefixes from DHCPv6 Delegation is automatically created. Prefixes delegated from the upstream interface are members of this group.

IPv6 Prefix Delegation is configured on:

An Upstream Interface
One or More Downstream Interfaces

When the upstream interface learns the prefix delegation from the DHCPv6-PD server, SonicOS calculates and applies the IPv6 address prefixes to all the downstream interfaces, and the downstream interfaces advertise this information to all the hosts in their network segments.

This section contains the following configuration procedures:

* 
NOTE: Before you disable prefix delegation in your network, we recommend that you release the prefix delegation in the upstream interface first.

Configuring IPv6 Prefix Delegation on the Upstream Interface

To configure IPv6 Prefix Delegation on the upstream interface:
1
Go to the Network > Interfaces page.
2
Select the IPv6 option.

3
Click the Edit icon in the Configure column for the Interface you want to configure as the upstream interface. The Edit Interface dialog appears.

4
The Zone will always be WAN.
5
From the IP Assignment menu, select DHCPv6.
6
Select the Enable DHCPv6 prefix delegation option.
7
From the DHCPv6 Mode menu, select Manual.
8
To see the configured DHCPv6 information, click the Protocol tab.
In the DHCPv6 General Information panel, the DHCPv6 DUID is displayed.
In the Stateful Addresses Acquired via DHCPv6 panel, the stateful IAID is displayed.

In the Delegated Prefixes Acquired via DHCPv6 panel, the delegated IAID is displayed.

9
Click the Renew button. The information for the other columns is displayed.

Configuring IPv6 Prefix Delegation on the Downstream Interface

To configure IPv6 Prefix Delegation on the downstream interface:
1
Go to the Network > Interfaces page.
2
Select the IPv6 option.
3
Click the Edit icon in the Configure column for the Interface you want to configure as the downstream interface. The Edit Interface dialog appears.

4
Select the Enable Router Advertisement option.
5
Click the Advanced tab. The Edit Interface dialog appears.
If the upstream prefix is obtained, it is displayed in the IPv6 Addresses panel.

6
If the upstream prefix cannot be obtained, an alternate address is displayed in the IPv6 Addresses panel.

7
Click the Add Address button. The Add IPv6 Address dialog appears.

8
Select the Add Downstream Delegated IPv6 Address option.
9
(Optional) Select the Advertise Subnet Prefix of Static IPv6 Address option.
10
Click the Router Advertisement tab.
11
Select the Enable Router Advertisement option. If you selected Advertise Subnet Prefix of Static IPv6 Address option under the General tab, the prefix will be listed in the Prefix List Settings panel.

12
To see your new IPv6 PD interfaces, go to the Network > Routing page.
13
Select the IPv6 option.

The two new IPv6 interfaces with prefix delegation (upstream and downstream) are displayed.

About 6rd Tunnel Interfaces

IPv6 Rapid Deployment (6rd) enables IPv6 to be deployed across an IPv4 network quickly and easily. 6rd utilizes a Service Provider’s existing IPv6 address prefixes, ensuring that the 6rd operational domain is limited to the Service Provider’s network and is under the Service Provider’s direct control.

A 6rd tunnel interface is a virtual interface that transports 6rd encapsulated IPv6 packets in an IPv4 network.

* 
NOTE: A 6rd tunnel interface must be bound to a physical or a virtual interface.

When 6rd is deployed, the IPv6 service is equivalent to native IPv6. 6rd mapping of IPv6 addresses to IPv4 addresses provides automatic determination of IPv4 tunnel endpoints from IPv6 prefixes, allowing stateless operation of 6rd.

A 6rd domain consists of several 6rd customer edge (CE) routers and one or more 6rd border relay (BR) routers. IPv6 packets encapsulated by 6rd follow the IPv4 routing topology within the service provider network.

A typical 6rd implementation using customer edge routers and border relay routers requires only one 6rd tunnel interface. A border relay router servicing multiple 6rd domains may have more than one 6rd tunnel interface. However, each 6rd domain can have only one 6rd tunnel interface.

IPv6 packets traverse the border relays when they enter or exit a Service Provider’s 6rd domain. Since 6rd is stateless, packets can be sent to the border relays using the Anycast method, where packets from a single source are routed to the nearest node in a group of potential receivers, or to several nodes, all identified by the same destination address.

Service Providers may deploy 6rd in a single domain or in multiple domains. A 6rd domain can have only one 6rd prefix. Different 6rd domains must use different 6rd prefixes.

On the Network > Routing page, in the Route Policies panel, there are four default route policies for 6rd tunnel interfaces.

There are two configuration modes:

Manual
DHCP

The following four 6rd parameters can be set manually, or they can be set automatically by the DHCPv4 server if you select DHCP as the configuration mode.

IPv4 Mask Length
6rd Prefix
6rd Prefix Length
6rd BR IPv4 Address

In DHCP mode, the 6rd parameters are received from the bound interface. In Manual mode, the 6rd parameters must be configured manually.

Configuring a 6rd Tunnel Interface

A 6rd tunnel interface is configured in the same way as other IPv6 tunnel interfaces. A bound interface is required to configure a 6rd tunnel interface.

To configure a 6rd tunnel interface:
1
Go to the Network > Interfaces page.
2
Select the IPv6 option.

3
At the bottom of the Interface Settings panel, from the Add Interface menu, select Tunnel Interface. The Edit Interface for IPv6 dialog appears.
* 
NOTE: The Protocol tab is shown only when you select DHCP as the Configure Mode.

4
From the Zone menu, select WAN.
5
The Interface Type menu is disabled. It already has Tunnel Interface selected as it was selected from the Add Interface menu in Step 3.
6
From the Tunnel Type menu, select 6rd Tunnel Interface.
7
In the name box, enter a name for your tunnel interface.

For example, 6rd Tunnel.

8
In the Tunnel Interface IPv6 Address box, enter the IPv6 address of the tunnel interface.

For example, 2001::2.

9
In the Prefix Length box, enter the length for the IPv6 prefix. For example, 64.
10
From the Bound to menu, select the interface that you want, such as X1.
11
From the Configure Mode menu, select the mode you want: Manual or DHCP.
* 
NOTE: If you select Manual as the Configure Mode, do steps 12 through 15.

If you select DHCP as the Configure Mode, skip steps 12 through 15.

12
In the 6rd Prefix box, enter the 6rd prefix, such as 2222:2222:: (Manual mode only).
13
In the 6rd Prefix Length box, enter the length for the 6rd prefix, such as 32 (Manual mode only).
14
In the IPv4 Mask Length box, enter the length of the IPv4 subnet mask (Manual mode only).
15
In the BR IPv4 Address box, enter the IPv4 address of the 6rd border relay (Manual mode only).
16
(Optional) In the Comment box, enter a comment to describe the tunnel interface.
17
Select the Add Default Route Automatically option.
18
Select the Management options that you want, or select the User Login options that you want.
If you selected Manual as the Configure Mode, your 6rd Tunnel Interface settings are shown under the General tab.

If you selected DHCP as the Configure Mode, your 6rd Tunnel Interface settings are shown under the Protocol tab.

Accessing the SonicOS Management Interface Using IPv6

After IPv6 addressing has been configured on the firewall, the SonicOS management interface can be accessed by entering the IPv6 of the firewall in your browser’s URL field.

IPv6 Network Configuration

IPv6 DNS

DNS for IPv6 is configured in the same method as for IPv4. Simply click the IPv6 option in the View IP Version radio button at the top left of the Network > DNS page.

Address Objects

IPv6 address objects or address groups can be added in the same manner as IPv4 address objects. On the Network > Address Objects page, the View IP Version radio button has three options: IPv4 only, IPv6 only, or IPv4 and IPv6.

* 
NOTE: Address Objects of type Host, Range and Network are supported. Dynamic address objects for MAC and FQDN are not currently supported for IPv6 hosts.

IPv4 interfaces define a pair of a default Address Object (DAO) and an Address Object Group for each interface. The basic rule for IPv4 DAO is each IPv4 address corresponds to 2 address objects: Interface IP and Interface Subnet. There are also couples of AO groups for Zone Interface IP, Zone Subnets, All Interface IP, All Interface Management IP, etc.

IPv6 interface prepares the same DAO set for each interface. Because multiple IPv6 can be assigned to one interface, all of those address can be added, edited, and deleted dynamically. Therefore, IPv6 DAOs need to be created and deleted dynamically.

To address this, DAOs are not generated dynamically for IPv6 interfaces. Only limited interface DAO are created, which results in limitation support for other module which needs to refer interface DAO.

Policy Based Routing

Policy Based Routing is fully supported for IPv6 by selecting IPv6 address objects and gateways for route policies on the Network > Routing page. On the Network > Routing page, the View IP Version radio button has three options: IPv4 only, IPv6 only, or IPv4 and IPv6. The OSPF feature displays two radio buttons to switch between version 2 and version 3.

Routing Information Protocol next generation (RIPng) is an information routing protocol for IPv6, which allows routers to exchange information for computing routes through an IPv6-based network.

A radio button is added to switch between RIP and RIPng:

IPv6 NAT Policies

IPv6 NAT policies are configured the same as IPv4. On the Network > NAT Policies page, select IPv6 for the View IP Version. Click the Configure button for an IPv6 address object on the Network > NAT Policies page. Refer to Network > NAT Policies for details on configuration.

When configuring IPv6 NAT policies, the source and destination objects can only be IPv6 address objects.

Neighbor Discovery Protocol

The Neighbor Discovery Protocol (NDP) is a new messaging protocol that was created as part of IPv6 to perform a number of the tasks that ICMP and ARP accomplish in IPv4. Just like ARP, Neighbor Discovery builds a cache of dynamic entries, and the administrator can configure static Neighbor Discovery entries. The following table shows the IPv6 neighbor messages and functions that are analogous to the traditional IPv4 neighbor messages.

 

IPv6 Neighbor Messages Analogous to IPv4 Neighbor Messages

IPv4 Neighbor message

IPv6 Neighbor message

ARP request message

Neighbor solicitation message

ARP relay message

Neighbor advertisement message

ARP cache

Neighbor cache

Gratuitous ARP

Duplicate address detection

Router solicitation message (optional)

Router solicitation (required)

Router advertisement message (optional)

Router advertisement (required)

Redirect message

Redirect Message

To configure NDP, navigate to the Network > Neighbor Discovery page.

The Static NDP feature allows for static mappings to be created between a Layer 3 IPv6 address and a Layer 2 MAC address. To configure a Static NDP entry, perform the following steps:

1
On the Network > Neighbor Discovery page, click the Add button.

2
In the IP Address field, enter the IPv6 address for the remote device.
3
In the Interface drop-down menu, select the interface on the firewall that will be used for the entry.
4
In the MAC Address field, enter the MAC address of the remote device.
5
Click OK. The static NDP entry is added.

The NDP Cache table displays all current IPv6 neighbors. The follow types of neighbors are displayed:

REACHABLE - The neighbor is known to have been reachable within 30 seconds.
STALE - The neighbor is no longer known to be reachable, and traffic has been sent to the neighbor within 1200 seconds.
STATIC - The neighbor was manually configured as a static neighbor.

Multicast Routing

The Network > Multicast Routing page is used to configure multicast settings for IPv6, which are divided into the two following sections:

Multicast Proxy

Maintaining interoperability between IPv6 and IPv4 networks is one of the main challenges of implementing IPv6 in a network. While packet-based multicast translation can be used, SonicWALL supports a multicast proxy solution that can be deployed at the border between IPv6 and IPv4 networks. The SonicWALL receives multicast data from the IPv4 network, caches it, and then multicasts the data to the IPv6 network. (And vice versa for sending multicast data from the IPv6 to the IPv4 network.) This is accomplished without the need for packet-based translation.

To configure Multicast Proxy between IPv6 and IPv4 networks:
1
Navigate to the Network > Multicast Routing page.
2
Select the Enable Multicast Proxy check box.
3
In the Upstream Interface drop-down menu, select the interface that is connected to the IPv6 network.
4
In the Downstream Interface drop-down menu, select the interface that is connected to the IPv4 network.
5
Click the Accept button. Multicast data will now be proxied \.

Multicast Listener Discovery

The Multicast Listener Discovery (MLD) protocol is used by IPv6 routers to discover multicast listeners that are directly connected to the firewall. MLD performs a similar function for IPv6 that IGMP is used for in IPv4. There are two versions of MLD. MLDv1 is similar to IGMPv2, and MLDv2 similar to IGMPv3.

 

Multicast Listener Discovery Versions

MLD Version

RFC

URL

MLDv1

RFC 2710

http://tools.ietf.org/html/rfc2710

MLDv2

RFC 3810

http://tools.ietf.org/html/rfc3810

MLD functionality does not require any explicit configuration. There are several variables that can be fine-tuned to modify the MLD behavior:

Multicast Router Query Interval: Specifies the length in seconds between MLD queries. The default value is 125 seconds.
Multicast Last Listener Query Interval: The maximum time that the router waits before deleting a nonresponsive port from the multicast group. Reducing this value will reduce the time required for the firewall to detect the departure of the last listener for a multicast address or source. The default value is 1000 milliseconds (1 second).
Multicast Router Query Response Interval: The Maximum Response Delay that is inserted into the periodic MLD queries. By varying the Multicast Router Query Response Interval, an administrator may tune the burstiness of MLD messages on the link; larger values make the traffic less bursty, as host responses are spread out over a larger interval. The Multicast Router Query Response Interval must be less than the Query Interval.The default value is 10000 milliseconds (10 seconds).
Multicast Router Robustness Variable: Specifies the number of queries that will be sent with no response before the target is deleted. This variable allows tuning the protocol according to the expected packet loss on a link. For lossy links (wireless connections, for example), the value of the Robustness Variable may be increased. The default value is 2. The Robustness Variable should not be configured for less than 2.

DHCPv6 Configuration

DHCPv6 server can be configured similar to the IPv4 DHCP Server after selecting the IPv6 option in the View IP Version radio button on the Network > DHCP Server page. For configuration information, see Network > DHCP Server.

IPv6 Access Rules Configuration

IPv6 firewall access rules can be configured in the same manner as IPv4 access rules by choosing IPv6 address objects instead of IPv4 address objects. On the Firewall > Access Rules page, the View IP Version radio button has three options: IPv4 only, IPv6 only, or IPv4 and IPv6.

When adding an IPv6 access rule, the source and destination can only be IPv6 address objects.

IPv6 IPsec VPN Configuration

IPsec VPNs can be configured for IPv6 in a similar manner to IPv4 VPNs after selecting the IPv6 option in the View IP Version radio button at the top left of the VPN > Settings page.

There are certain VPN features that are currently not supported for IPv6, including:

IKEv2 is supported, while IKE is currently not supported
GroupVPN is not supported
DHCP Over VPN is not supported.

When configuring an IPv6 VPN policy, on the General tab the gateways must be configured using IPv6 addresses. FQDN is not supported. When configuring IKE authentication, IPV6 addresses can be used for the local and peer IKE IDs.

* 
NOTE: DHCP Over VPN and L2TP Server are not supported for IPv6.

On the Network tab of the VPN policy, IPV6 address objects (or address groups that contain only IPv6 address objects) must be selected for the Local Network and Remote Network.

DHCP Over VPN is not supported, thus the DHCP options for protected network are not available.

The Any address option for Local Networks and the Tunnel All option for Remote Networks are removed. Select an all zero IPv6 Network address object could be selected for the same functionality and behavior.

On the Proposals tab, the configuration is identical for IPv6 and IPv4, except for the fact that IPv6 only support IKEv2 mode.

On the Advanced tab, only Enable Keep Alive and the IKEv2 Settings can be configured for IPv6 VPN policies.

* 
NOTE: Because an interface may have multiple IPv6 address, sometimes the local address of the tunnel may vary periodically. If the user needs a consistent IP address, configure the VPN policy to be bound to an interface instead of Zone, and specify the address manually. The address must be one of IPv6 addresses for that interface.

SSL VPN Configuration for IPv6

SonicOS supports NetExtender connections for users with IPv6 addresses. On the SSLVPN > Client Settings page, first configure the traditional IPv6 IP address pool, and then configure an IPv6 IP Pool. Clients will be assigned two internal addresses: one IPv4 and one IPv6.

* 
NOTE: IPv6 DNS/Wins Server are not supported

On the SSLVPN > Client Routes page, user can select a client routes from the drop-down list of all address objects including all the pre-defined IPv6 address objects.

* 
NOTE: IPv6 FQDN is supported.

IPv6 Visualization

IPv6 Visualization for the App Flow Monitor and Real-Time Monitor is an extension of the IPv4 Visualization, providing real-time monitoring of interface/application rates and visibility of sessions in the management interface.

With the new visualization dashboard monitoring improvements for IPv6, administrators are able to respond more quickly to network security vulnerabilities and network bandwidth issues. Administrators can see what websites their employees are accessing, what applications and services are being used in their networks and to what extent, in order to police content transmitted in and out of their organizations.

The App Flow Monitor page has two new options for the View IP Version selection. These allow you to monitor IPv6 only or IPv4 and IPv6 traffic.

The Real-Time Monitor page has the same two new options under the Interface drop-down menu in the Applications and Bandwidth panels.

IPv6 Visualization Feature Limitations

Visualization for IPv6 has the following feature limitations:

The IPv6 URL Rating is not supported, because CFS does not support all aspects of IPv6.
IPv6 Country information is not supported.
IPv6 External Reporting is not supported.

Configuring IPv6 Visualization

App Flow Monitor and Real-Time Monitor Visualization is configured the same in IPv6 and IPv4, select the View IP Version radio buttons to change the view/configuration. Refer to the Visualization Dashboard for more information on general configuration on Visualization.

IPv6 High Availability Monitoring

IPv6 High Availability (HA) Monitoring is implemented as an extension of HA Monitoring in IPv4. After configuring HA Monitoring for IPv6, both the primary and backup appliances can be managed from the IPv6 monitoring address, and IPv6 Probing is capable of detecting the network status of HA pairs.

IPv6 and IPv4 radio buttons display in the High Availability > Monitoring page, toggle between the two views for easy configuration of both IP versions:

Topics:

IPv6 High Availability Monitoring Feature Limitations

The IPv6 HA Monitoring feature limitations are as follows:

Physical/Link Monitoring property cannot be changed in the IPv6 HA Monitoring configuration page. Set the property in the IPv4 HA Monitoring configuration page.
Override Virtual MAC property cannot be changed in IPv6 HA Monitoring configuration page. Set the property in the IPv4 HA Monitoring configuration page.
HA Probing cannot be enabled on both IPv4 and IP{v6 at the same time. That is, if IPv4 probing is enabled, then IPv6 probing must be disabled, and vice versa.

IPv6 High Availability Probing

An ICMPv6 packet is periodically sent out from the primary and backup appliances to probe the IPv6 address, and the response from the probed IPv6 address is monitored. If the active appliance cannot reach the probed IPv6 address, but the idle appliance can, the backup appliance has a better network status and failover initiates.

In IPv6 HA Probing the IPv6 addresses, ICMPv6 echo requests, and ICMPv6 echo replies are used. The logic used to judge network status of the primary and backup appliance is the same for IPv4 and IPv6.

Configuring IPv6 High Availability Monitoring

The IPv6 HA Monitoring configuration page is inherited from IPv4, so the configuration procedures are almost identical. Just select the IPv6 radio button and refer to the About IPv6 for configuration details.

Consider the following when configuring IPv6 HA Monitoring:

The Physical/Link Monitoring and Virtual MAC check boxes are greyed out because they are layer two properties. That is, the properties are used by both IPv4 and IPv6, so user has to configure them in the IPv4 monitoring page.
The primary/backup IPv6 address must be in the same subnet of the interface, and it can not be same as the global IP and Link-Local-IP of the primary/backup appliance.
If the primary/backup monitoring IP is set to (not ::), then they cannot be the same.
If the Management check box is enabled, then primary/backup monitoring IP cannot be unspecified (that is, ::).
If the probe check box is enabled, then the probe IP cannot be unspecified.

IPv6 Diagnostics and Monitoring

SonicOS provides a full compliment of diagnostic tools for IPv6, including the following:

Packet Capture

Packet Capture fully supports IPv6.

IPv6 keywords can be used to filter the packet capture.

IPv6 Ping

The ping tool includes a new Ping IPv6 network preferred option.

When pinging a domain name, it uses the first IP address that is returned and shows the actual pinging address. If both an IPv4 and IPv6 address are returned, by default, the firewall pings the IPv4 address.

If the Ping IPv6 network preferred option is enabled, the firewall will ping the IPv6 address.

IPv6 DNS Lookup and Reverse Name Lookup

When performing IPv6 DNS Lookup or IPv6 Reverse Name Lookup, you must enter the DNS server address. Either an IPv6 or IPv4 address can be used.

SonicWall Support

Technical support is available to customers who have purchased SonicWall products with a valid maintenance contract and to customers who have trial versions.

The Support Portal provides self-help tools you can use to solve problems quickly and independently, 24 hours a day, 365 days a year. To access the Support Portal, go to https://support.sonicwall.com.

The Support Portal provides self-help tools you can use to solve problems quickly and independently, 24 hours a day, 365 days a year. In addition, the Support Portal provides direct access to product support engineers through an online Service Request system.

The Support Portal enables you to:

View knowledge base articles and technical documentation
Download software
View video tutorials
Collaborate with peers and experts in user forums
Get licensing assistance
Access MySonicWall
Learn about SonicWall professional services
Register for training and certification

To contact SonicWall Support, refer to https://support.sonicwall.com/contact-support.

To view the SonicWall End User Product Agreement (EUPA), see https://www.sonicwall.com/legal/eupa.aspx. Select the language based on your geographic location to see the EUPA that applies to your region.