User Ref Oneos Book Advanced Ip

O N E O S
V 5 . 2
A D V A N C E D I P U S E R G U I D E
( E D I T I O N 2 1 )
ONEOS V5.2 ADVANCED IP USER GUIDE (EDITION 21)
OneAccess Networks
Pentagone Plaza
381, Avenue du Général de Gaulle
92140 Clamart
FRANCE
The law of 11 March 1957, paragraphs 2 and 3 of article 41, only authorizes, firstly, "copies and reproductions strictly reserved for use by copyists
and not for general use" and, secondly, "analyses and short quotations for the purpose of example and illustration". Therefore, "any representation
or reproduction, entire or partial, made without the consent of the author or his representatives is illegal” (paragraph 1 of article 40).
Any such representation or reproduction, made in any manner whatsoever, would therefore constitute an infringement of the law as sanctioned by
articles 425 and in accordance with the penal code.
Information contained in this document is subject to change without prior notice and does not constitute any form of obligation on the part of
OneAccess.
OneAccess and the distributors can in no case be held responsible for direct or indirect damage of any kind incurred as a result of any error in the
software or guide.
Every care has been taken to ensure the exactitude of information in this manual. If however you discover an error, please contact OneAccess
after Sales Service division.
Twenty-first edition: April 2016
Advanced IP User Guide Page 1.1-2 of 277

1 I N T R O D U C T I O N
This edition of the OneOS Book corresponds to the V5.2 software releases. It is also available for all
previous software releases of OneOS according to the features matrix described hereafter.
The OneOS software developed for use with the ONE product range offers an extensive range of features
designed to provide a complete & highly powerful range of multi-service access routers:
• Full IP router with NAPT, Security, and Quality of Service management
• Support of voice for analog and ISDN S0/T0 terminals using Voice over IP and Voice over ATM
• Interworking of data protocols (FR, X.25, PAD, XOT, X.31)
• Application layer management tools (WAN Optimization)
• Advanced management tools based on CLI (Command Line Interface), SNMP, FTP/TFTP
This document is the OneOS user guide for Advanced IP functions of the OneOS-based range products.
Eight other user guides and two global indexes are available:
o OneOS – Admin User Guide
o OneOS – Bridging & LAN User Guide
o OneOS – Basic IP User Guide
o OneOS – WAN User Guide
o OneOS – VoIP User Guide
o OneOS – VoATM & CES User Guide
o OneOS – IBC User Guide
o OneOS – Applications User Guide
o Index of OneOS User Guides (global table of contents)
o Index of CLI of OneOS User Guides (global list of CLI commands)

1.1 FEATURE MATRIX
The following table is a resource providing, edition by edition, the released features. The table was done
as of the V3.5R2E3 software release. For simplification, the indicated software release shows the
presence of a feature in a given software release starting with V3.5R2E3. It should be noted that most
features were available in earlier versions.
The table also shows in which edition of the OneOS book a feature was added to the User Guide, starting
with Edition 16.
Present at Added in
Main Function Feature
least in: UG:
IPv6 Functions Dual stack IPv6 / IPv4 V5.1R4E4
TCP(v6), UDP(v6), socket (v6) V5.1R4E4
PMTUD IPv6 (RFC 1981) V5.1R4E4
IPv6 fast forwarding and route V6 caching V5.1R4E4
Support of multiple IPv6 addresses per interface V5.1R4E4
Loopback interfaces, Null interface V5.1R4E4
Static routing IPv6 – IPv6 V5.1R4E4
Manual 6in4 tunnel V5.1R4E4
GRE tunnel V5.1R5E1
ISATAP tunnel V5.1R5E1
TCP MSS (Maximum Segment Size) Clamping on any V5.2R1E1
interface
Virtual Routing and Forwarding (VRF) V5.2R1E1
IPv6 disabled by default; must be enabled per interface V5.1R5E4
Flow-based load sharing per destination, per packet, per V5.2R1 Edition 17
session. Refer to 2.2.5 Flow based Load Sharing.
IPv6 activation procedure updated; refer to V5.1R5 Edition 17
2.2.1 IPv6 activation on an interface.
IPv6 reverse path forwarding on an interface added; refer V5.2R1 Edition 18
to 2.2.11 Enabling IPv6 Reverse Path Forwarding.
SAVI (Source Address Validation Improvements ) for prefix V5.2R1 Edition 18
delegation added; refer to
2.2.12 IPv6 Prefix Delegation binding & filtering (SAVI).
ICMPv6 ICMPv6 (RFC 2463) V5.1R4E4
ICMPv6 redirect V5.1R4E4
Neighbor Discovery (RFC 4861) V5.1R4E4
Address resolution V5.1R4E4
Neighbor unreachable detection V5.1R4E4
Automatic configuration as router (RFC 4862) V5.1R4E4
Automatic configuration as client (RFC 4862) V5.1R4E4
IPv6 Router advertisement options for DNS (RFC 6106) V5.1R4E4
debug ipv6 icmp command added V5.1R5E10
show icmpv6 statistics command added V5.1R5E10
DHCPv6 New command: no dns-server all V5.1R5E3
IP Security Software encryption algorithm: AES, DES, 3DES V3.5R2E3
(IPsec) Software authentication algorithm: SHA, MD5 V3.5R2E3
Hardware encryption algorithm (ONE60 only, on V3.5R2E3
compatible hardware): DES, 3DES
Hardware authentication algorithm (ONE60 only, on V3.5R2E3

Present at Added in
least in: UG:
compatible hardware): SHA
Perfect forward secrecy (PFS) V3.5R2E3
Manual IPsec crypto map V3.5R2E3
Internet Key Exchange (IKE) V3.5R2E3
IKE with X.509 certificates V4.2R5E6
Compression (IP comp algorithm) V3.5R2E3
Configuration of SA lifetime V3.5R2E3
Dynamic crypto maps V3.5R2E3
Applying a crypto map directly on an output interface V3.5R2E3
Applying a crypto map on a GRE tunnel V3.5R2E3
Tunnel keep alive V3.5R2E3
NAT traversal V3.5R3E1
Easy VPN client: Xauth IKE authentication V3.7R13E6
Easy VPN server V5.1R3E1
VRF aware IPsec V5.1R3E1
IPsec profile or protection profile; refer to V5.2R1 Edition 20
5.7 IPsec Configuration by means of an IPsec Profile
(IKEv1 and IKEv2).
IKEv2; refer to 5.9 Configuring IKEv2. V5.2R1 Edition 20
Call Admission Control or CAC; refer to V5.2R1 Edition 20
5.10Call Admission Control for IPsec SA’s.
GET VPN Group Encrypted Transport VPN V5.1R5E2
Group Domain of Interpretation (GDOI) as per RFC 3547 V5.1R5E2
Multicast Group Security Architecture as per RFC 3740 V5.1R5E2
Multicast Security Group Key Architecture as per RFC V5.1R5E2
4046
Interoperability with existing ISR routers and Key Servers V5.1R5E2
Group member part of MIB GDOI implemented V5.1R5 Edition 16
IPv6 Access Standard ACL V5.1R4E4
Control List Extended ACL V5.1R4E4
(ACL)
Rule-based logging V5.1R4E4
Session auditing V5.1R4E4
Rule sequencing and re-sequencing V5.1R4E4
Limiting on half-open and open sessions V5.1R4E4
Per-source-host session limiting and half-open session V5.1R4E4
limiting, thresholds are configurable globally and per host
Reflexive filters (diode-effect rule) V5.2R1E1
Context-Based Access Control (or Stateful Inspection) V5.2R1E1
Reverse Path Forwarding Check (RPF) V5.2R1E1
ICMPv6 messages filtering (RFC 4890) V5.2R1E1
Stateful Inspection commands updated; refer to: V5.2R1 Edition 18
4.2.7 Stateful Inspection, 4.3 ACL Statistics (IPv6)
4.4 ACL Debug (IPv6)
Routing Support of V1 and V2 on any interfaces V3.5R2E3
Information Configuration of RIP version on a per-interface basis V3.5R2E3
Protocol (RIP)
Authentication support V3.5R2E3
Redistribution of static, connected, OSPF and BGP routes V3.5R2E3
Filtering redistributed routes based on route maps V3.5R2E3
Route map feature: match using ACL and prefix-list, V3.5R2E3
match/set tag, set metric
Distribute-list (in/out) using standard ACL V3.5R2E3
Configuration of administrative distance V3.5R2E3
Disabling update source IP address validation V4.3R4E12

Present at Added in
least in: UG:
RIPng for IPv6 (RFC 2080) V5.2R1E1
Commands added:ip rip authentication mode V5.1R5 Edition 21
md5 and ip rip authentication mode text. Refer
to:7.2.4 Configuring Authentication.
Border Network advertisement with a route-map directly applied V3.5R2E3
Gateway onto the advertised network
Protocol (BGP) Support both eBGP and iBGP V3.5R2E3
TCP MD5 authentication V3.5R2E3
Neighbor configuration within peer-groups V3.5R2E3
Support of non-directly connected eBGP neighbors (eBGP V3.5R2E3
multi-hop)
Community support and update filtering with community V3.5R2E3
list
Send default route on a per neighbor basis V3.5R2E3
Limitation of the maximum learnt prefix numbers from a V3.5R2E3
neighbor
Allow routes with two or more times the same AS in its AS V3.5R2E3
path (allowas-in)
Overwrite next hop by router’s address (next-hop-self) V3.5R2E3
Route-map based filtering by neighbors V3.5R2E3
Soft connection reset V3.5R2E3
Support of multi-path routes (load sharing) V3.5R2E3
Redistribution of static, connected, OSPF and RIP routes V3.5R2E3
Filtering redistributed routes based on route maps V3.5R2E3
Route map feature: match using ACL and prefix-list, V3.5R2E3
match/set tag, match/set community, match AS path, set
metric
BGP confederation V3.5R2E3
Weight attribute V3.5R2E3
Distribute-list V3.5R2E3
Route summarization (or aggregation) V3.5R2E3
Route reflector V3.5R2E3
Dampening of flapping routes V3.5R2E3
VRF aware BGP V5.1R3E1
BGP-4 extensions for IPv6 inter domain routing (RFC V5.1R5E1
2545)
Multiprotocol extensions for BGP-4 (RFC 2858) V5.1R5E1
Capabilities advertisement with BGP-4 (RFC 3392) V5.1R5E1
Graceful restart mechanism for BGP (RFC 4724) V5.1R5E1
Limitation of the maximum learnt prefix numbers from a V5.2R1 Edition 17
neighbor – additional options. Refer to 9.2.1.5 Assignment
of Routing Policies and Attributes.
BGP Fall Over via route map or BFP; refer to V5.1R5 Edition 21
9.2.4.6 BGP Fall-over.
Open Shortest Stub areas, NSSA, totally stubby area V3.5R2E3
Path First Virtual links V3.5R2E3
protocol
Authentication V3.5R2E3
(OSPF)
Interface cost tuning V3.5R2E3
Administrative distance V3.5R2E3
Route redistribution V3.5R2E3
LSA opaque as per RFC 2370 V4.3R4E19
OSPFv3 for IPv6 (RFC 2740) V5.2R1E1

Present at Added in
least in: UG:
Bidirectional BFD for IPv4 / IPv6 V5.1R2E2
Forwarding Hello echo V5.1R2E2
Detection (BFD) Asynchronous mode V5.1R2E2
Binding of BFD to static routes V5.1R2E2
MIB for BFD IPv4 / IPv6 V5.1R4E4
BFD Multihop Control - use of port 4784 (RFC5883) V5.1R5E21
Multicast IGMP V1/V2/V3 V3.5R2E3
Routing PIM-SM V2 V3.5R2E3
Source-specific multicast V3.5R2E3
RP group list V3.5R2E3
Bootstrap router support V3.5R2E3
Static multicast routes V3.5R2E3
Scope groups by direction V4.2R5E2
Source interface setting for register address V3.5R2E3
IGMP access-lists V3.5R2E3
Switching to source tree V3.5R2E3
IGMP snooping (RFC 4541) on bridge group with BVI V4.3R4E14
PIM-SM - Configuring longest prefix match criteria V5.2R1
IGMP Proxy; refer to 13.3.3 Configuring IGMP Proxy. V5.2R2 Edition 20
Zone-based Firewall zones, zone-pairs V5.1R3E1
Firewall Firewall policies, Firewall filters V5.1R3E1
FTP, TFTP, SIP and H.323 ALGs V5.1R3E1
Firewall logging and statistics V5.1R3E1
VRF aware Zone-based Firewall V5.1R3E1

1.2 TABLE OF CONTENTS
1 INTRODUCTION ....................................................................................................................................... 1.1-3

1.1 Feature Matrix ................................................................................................................................ 1.1-4
1.2 Table of Contents........................................................................................................................... 1.2-8
2 INTERNET PROTOCOL VERSION 6 (IPV6) .......................................................................................... 1.2-15
2.1 Introduction to OneOS IPv6 Features .......................................................................................... 2.1-15
2.1.1 IPv6 Address Writing Rules .............................................................................................. 2.1-15
2.1.1.1 IPv6 Addresses ..................................................................................................... 2.1-15
2.1.1.2 IPv6 Prefix ............................................................................................................. 2.1-15
2.1.1.3 IPv6 URL ............................................................................................................... 2.1-16
2.1.2 IPv6 Features ................................................................................................................... 2.1-16
2.1.2.1 IPv6 Fast Forwarding ............................................................................................ 2.1-16
2.1.2.2 Multiple IPv6 Addresses per Interface ................................................................... 2.1-16
2.1.2.3 IPv6 Virtual Interfaces ........................................................................................... 2.1-16
2.1.2.4 IPv6 Static Routing ................................................................................................ 2.1-16
2.1.2.5 IPv6 Dynamic Routing ........................................................................................... 2.1-16
2.1.2.6 IPv6 Virtual Routing and Forwarding (VRF) .......................................................... 2.1-16
2.1.2.7 IPv6 Packet Processing Path ................................................................................ 2.1-17
2.2 IPv6 Configuration Commands .................................................................................................... 2.2-17
2.2.1 IPv6 activation on an interface.......................................................................................... 2.2-17
2.2.2 IPv6 Addresses Configuration .......................................................................................... 2.2-18
2.2.2.1 Static IPv6 Address configuration.......................................................................... 2.2-18
2.2.2.2 Stateless Auto-configuration of IPv6 Address ....................................................... 2.2-18
2.2.2.3 Static IPv6 anycast address configuration ............................................................. 2.2-18
2.2.2.4 Static IPv6 address configuration using a EUI-64 interface ID .............................. 2.2-19
2.2.2.5 Static IPv6 link-local address configuration ........................................................... 2.2-19
2.2.2.6 IPv6 address configuration using prefix delegation ............................................... 2.2-19
2.2.2.7 Configuration of IPv6 Addressing for PPP Interfaces ............................................ 2.2-20
2.2.3 Enabling IPv6 Forwarding................................................................................................. 2.2-20
2.2.4 Static IPv6 Routes Configuration ...................................................................................... 2.2-20
2.2.5 Flow based Load Sharing ................................................................................................. 2.2-20
2.2.6 IPv6 Neighbor Discovery Configuration ............................................................................ 2.2-21
2.2.6.1 RA interval configuration ....................................................................................... 2.2-21
2.2.6.2 RA lifetime configuration........................................................................................ 2.2-21
2.2.6.3 RA suppress configuration .................................................................................... 2.2-21
2.2.6.4 ND Reachable time configuration .......................................................................... 2.2-21
2.2.6.5 ND RA flags configuration ..................................................................................... 2.2-22
2.2.7 IPv6 host name/address binding ...................................................................................... 2.2-22
2.2.8 ICMPv6 configuration commands ..................................................................................... 2.2-22
2.2.9 ICMPv6 redirect messages............................................................................................... 2.2-23
2.2.10 IPv6 DNS Configuration Commands ................................................................................ 2.2-23
2.2.10.1 Setting DNS server addresses .............................................................................. 2.2-23
2.2.10.2 Learning DSN server addresses ........................................................................... 2.2-23
2.2.10.3 Using the FQDN .................................................................................................... 2.2-24
2.2.10.4 Setting the IPv6 name server address .................................................................. 2.2-24
2.2.11 Enabling IPv6 Reverse Path Forwarding .......................................................................... 2.2-25
2.2.12 IPv6 Prefix Delegation binding & filtering (SAVI) .............................................................. 2.2-25
2.3 IPv6 Debug and Statistics ............................................................................................................ 2.3-26
2.3.1 IPv6 Statistics ................................................................................................................... 2.3-26
2.3.2 ICMPv6 statistics .............................................................................................................. 2.3-30
2.3.3 IPv6 Debugging ................................................................................................................ 2.3-31
2.4 IPv6 Configuration Example ........................................................................................................ 2.4-33
3 DHCPV6 CONFIGURATION .................................................................................................................. 2.4-34
3.1 DHCPv6 Global Configuration ..................................................................................................... 3.1-34
3.1.1 Enabling/Disabling DHCPv6 ............................................................................................. 3.1-34

3.1.2 DHCPv6 Pool Configuration ............................................................................................. 3.1-35

3.1.3 DHCPv6 Relay Configuration ........................................................................................... 3.1-37
3.1.4 IPV6 Configuration Example - DHCPv6 Pool ................................................................... 3.1-37
3.2 DHCPv6 Configuration at Interface Level .................................................................................... 3.2-38
3.2.1 DHCPv6 Client Configuration ........................................................................................... 3.2-38
3.2.2 DHCPv6 Relay Configuration ........................................................................................... 3.2-38
3.2.2.1 DHCPv6 Relay Destination Configuration ............................................................. 3.2-38
3.2.2.2 DHCPv6 Relay Subscriber-ID Option Configuration.............................................. 3.2-39
3.2.2.3 DHCPv6 Relay Source Interface Configuration ..................................................... 3.2-39
3.2.3 DHCPv6 Server Configuration .......................................................................................... 3.2-39
3.3 DHCPv6 Statistics........................................................................................................................ 3.3-40
3.4 IPv6 Configuration Example - IPv6 prefix delegation as requesting router .................................. 3.4-43
4 IPV6 ACCESS LISTS ............................................................................................................................. 3.4-44
4.1 ACL Features (IPv6) .................................................................................................................... 4.1-44
4.1.1 Access List Filters ............................................................................................................. 4.1-44
4.1.2 ICMP Unreachable ........................................................................................................... 4.1-44
4.1.3 Context Based Access Control ......................................................................................... 4.1-44
4.1.4 Logging and Statistics....................................................................................................... 4.1-44
4.2 ACL Configuration Commands (IPv6) .......................................................................................... 4.2-45
4.2.1 Rules Matching IPv6 Addresses ....................................................................................... 4.2-45
4.2.2 Rules Matching IPv6 Addresses + IP Protocol ................................................................. 4.2-45
4.2.3 Rules Matching IPv6 Addresses + TCP/UDP ................................................................... 4.2-46
4.2.4 Rules Matching IPv6 Addresses + ICMP .......................................................................... 4.2-46
4.2.5 Terminating IPv6 ACL configuration ................................................................................. 4.2-46
4.2.6 Attaching Detaching an ACL on an Interface .................................................................... 4.2-47
4.2.7 Stateful Inspection ............................................................................................................ 4.2-47
4.2.8 Changing the Idle-Timers ................................................................................................. 4.2-48
4.3 ACL Statistics (IPv6) .................................................................................................................... 4.3-48
4.4 ACL Debug (IPv6) ........................................................................................................................ 4.4-49
5 IP SECURITY (IPSEC) ........................................................................................................................... 4.4-50
5.1 Fragmentation and tunnels - Caveats .......................................................................................... 5.1-50
5.2 Introducing IPsec protected tunnel............................................................................................... 5.2-52
5.2.1 Introduction ....................................................................................................................... 5.2-52
5.2.2 Internet Security Association and Key Management Protocol (ISAKMP) ......................... 5.2-56
5.2.3 Pre-shared keys and Digital certificates............................................................................ 5.2-57
5.2.4 IPsec encapsulated GRE and L2TP tunnels..................................................................... 5.2-58
5.2.5 NAT Traversal .................................................................................................................. 5.2-58
5.2.6 IPsec Processing Path and choice between crypto maps and tunnel protection profiles . 5.2-59
5.2.7 IP QoS and IPsec ............................................................................................................. 5.2-59
5.3 Hardware-Accelerated IPsec ....................................................................................................... 5.3-60
5.4 3 Ways of configuring an IPsec protected tunnel ......................................................................... 5.4-61
5.5 IPsec Configuration making use of Crypto Maps (IKEv1) ............................................................ 5.5-62
5.5.1 Configuration Steps .......................................................................................................... 5.5-62
5.5.2 Configuring IPsec Transforms .......................................................................................... 5.5-63
5.5.3 Configuring a Crypto Map ................................................................................................. 5.5-64
5.5.3.1 Manual Crypto Map Entries ................................................................................... 5.5-64
5.5.3.2 Standard ISAKMP Crypto Map Entries .................................................................. 5.5-66
5.5.3.3 Dynamic ISAKMP Crypto Map Entries .................................................................. 5.5-69
5.5.3.4 Easy VPN Crypto Maps ......................................................................................... 5.5-72
5.5.3.5 Applying a Crypto Map to an Interface .................................................................. 5.5-72
5.5.3.6 DF bit in tunnel mode ............................................................................................ 5.5-73
5.6 Easy VPN Configuration .............................................................................................................. 5.6-74
5.6.1.1 Easy VPN Client .................................................................................................... 5.6-74
5.6.1.1.1 Easy VPN Client Configuration .................................................................. 5.6-74
5.6.1.1.2 Applying Easy VPN client configuration on Interfaces................................ 5.6-75
5.6.1.2 Easy VPN Server .................................................................................................. 5.6-76
5.6.1.2.1 Easy VPN Server license activation ........................................................... 5.6-76
5.6.1.2.2 Easy VPN Server authentication configuration........................................... 5.6-77
5.6.1.2.3 Easy VPN Server MODE-CFG client configuration .................................... 5.6-78
5.6.1.2.4 Easy VPN Server statistics......................................................................... 5.6-80
5.7 IPsec Configuration by means of an IPsec Profile (IKEv1 and IKEv2) ......................................... 5.7-81

5.7.1 Protecting a Tunnel with an IPsec Profile ......................................................................... 5.7-81

5.7.2 Configuring an IPsec Profile ............................................................................................. 5.7-82
5.7.2.1 Responder Only .................................................................................................... 5.7-83
5.7.2.2 Setting one or more Transform Sets ..................................................................... 5.7-83
5.7.2.3 Perfect Forward Secrecy or PFS ........................................................................... 5.7-83
5.7.2.4 Security Association Parameters ........................................................................... 5.7-84
5.7.2.5 Setting an ISAKMP profile in the IPsec Profile (IKEv1) ......................................... 5.7-85
5.7.2.6 Setting an IKEv2 profile in the IPsec Profile .......................................................... 5.7-85
5.8 Configuring IKEv1 (ISAKMP) ....................................................................................................... 5.8-86
5.8.1 Enabling Crypto ISAKMP.................................................................................................. 5.8-86
5.8.2 ISAKMP Identity ............................................................................................................... 5.8-86
5.8.3 ISAKMP key ..................................................................................................................... 5.8-86
5.8.4 ISAKMP policy .................................................................................................................. 5.8-87
5.8.5 ISAKMP Keepalive ........................................................................................................... 5.8-89
5.8.6 ISAKMP Aggressive Mode ............................................................................................... 5.8-90
5.8.7 ISAKMP Profile ................................................................................................................. 5.8-91
5.8.8 Configuring an IKEv1 Keyring........................................................................................... 5.8-93
5.8.9 NAT Traversal .................................................................................................................. 5.8-94
5.9 Configuring IKEv2 ........................................................................................................................ 5.9-95
5.9.1 Introducing IKEv2 ............................................................................................................. 5.9-95
5.9.2 IKEv2 Configuration Steps................................................................................................ 5.9-96
5.9.3 IKEv2 Dead Peer Detection .............................................................................................. 5.9-97
5.9.4 Configuring an IKEv2 profile ............................................................................................. 5.9-99
5.9.5 Configuring an IKEv2 Proposal........................................................................................5.9-102
5.9.6 Configuring an IKEv2 Policy ............................................................................................5.9-104
5.9.7 Configuring an IKEv2 Keyring..........................................................................................5.9-105
5.9.8 Smart Defaults .................................................................................................................5.9-106
5.9.8.1 Introducing Smart Defaults ...................................................................................5.9-106
5.9.8.2 Changing the Settings of a Smart Default ............................................................5.9-107
5.9.8.3 Removing a Smart Default ...................................................................................5.9-107
5.9.8.4 Re-enabling a Smart Default ................................................................................5.9-108
5.9.8.5 Reverting from a User Updated Smart Default to the Factory-Default Setting......5.9-108
5.9.9 IKEv2 NAT Traversal .......................................................................................................5.9-109
5.9.10 IKEv2 Show Commands ..................................................................................................5.9-109
5.10 Call Admission Control for IPsec SA’s ......................................................................................5.10-111
5.11 Fragmentation and IPsec - Recommended Settings.................................................................5.11-112
5.11.1 Pre-Fragmentation .........................................................................................................5.11-112
5.11.2 Post-Fragmentation .......................................................................................................5.11-112
5.11.3 Configuration Commands ..............................................................................................5.11-113
5.12 Configuring Certificates.............................................................................................................5.12-114
5.13 IPsec SNMP Traps ...................................................................................................................5.13-115
5.14 IPsec Statistics..........................................................................................................................5.14-115
5.15 IPsec Debug Commands ..........................................................................................................5.15-118
5.16 IPsec Configuration Examples ..................................................................................................5.16-119
5.16.1 Configuration Example - IKEv1 Manual Crypto Entries .................................................5.16-119
5.16.2 Configuration Example - IKEv1 with a standard ISAKMP Crypto Map ..........................5.16-121
5.16.3 Configuration Example - Client-Server case ..................................................................5.16-123
5.16.4 Configuration Example1 - IKEv1 IPsec profile ...............................................................5.16-125
5.16.5 Configuration Example2 - IKEv1 IPsec profile ...............................................................5.16-126
5.16.6 Configuration Example - Easy VPN Client .....................................................................5.16-128
5.16.7 Configuration Example - Easy VPN Server ...................................................................5.16-129
5.16.8 Configuration Example - IKEv2 ......................................................................................5.16-131
5.16.9 Configuration Example - IKEv2 using Pre-Shared Keys and a Tunnel Interface ...........5.16-133
5.16.10 Configuration example - IKEv2 with Certificate Authentication and a Tunnel Interface .5.16-136
6 GROUP ENCRYPTED TRANSPORT VPN (GET VPN) ......................................................................5.16-140
6.1 Introduction to GET VPN ............................................................................................................6.1-140
6.2 GET VPN Configuration ..............................................................................................................6.2-141
6.2.1 GET VPN Server license activation .................................................................................6.2-141
6.2.2 Configuring the GDOI Group on the Group Member (GM) ..............................................6.2-141
6.2.3 Configuring the Crypto Map on the Group Member (GM) ................................................6.2-142
6.2.4 Applying the GDOI Crypto Map to an Interface ...............................................................6.2-143
6.2.5 Configuring the Re-Registration behavior ........................................................................6.2-144
6.2.5.1 Re-Registration on Timeout..................................................................................6.2-144

6.2.5.2 Re-Registration on Rekey ....................................................................................6.2-144

6.2.5.3 Re-Registration None ...........................................................................................6.2-145
6.3 GET VPN statistics and debug....................................................................................................6.3-146
6.3.1 Show and clear commands .............................................................................................6.3-146
6.3.2 Commands to temporarily change the direction of IPsec SAs .........................................6.3-150
6.3.3 Debug commands ...........................................................................................................6.3-150
6.4 GET VPN Example .....................................................................................................................6.4-151
6.4.1 Group Member GM1 configuration ..................................................................................6.4-151
6.4.2 Group Member GM2 configuration ..................................................................................6.4-152
6.4.3 For information: CISCO Key Server configuration ...........................................................6.4-152
7 ROUTING INFORMATION PROTOCOL (RIPV1 AND RIPV2) .............................................................6.4-154
7.1 RIP Features ...............................................................................................................................7.1-154
7.2 RIP Configuration Commands ....................................................................................................7.2-155
7.2.1 Enabling RIP....................................................................................................................7.2-155
7.2.2 Adjusting Timers ..............................................................................................................7.2-155
7.2.3 Setting RIP Versions........................................................................................................7.2-156
7.2.4 Configuring Authentication...............................................................................................7.2-157
7.2.5 Generating a Default Route into RIP ...............................................................................7.2-158
7.2.6 Redistributing Routes ......................................................................................................7.2-158
7.2.7 Route Filtering .................................................................................................................7.2-158
7.2.7.1 Filtering Based on Access Lists............................................................................7.2-159
7.2.7.2 Filtering Based on Prefix Lists ..............................................................................7.2-159
7.2.7.2.1 Prefix List Creation ....................................................................................7.2-159
7.2.7.2.2 Showing Prefix Entries ..............................................................................7.2-160
7.2.7.2.3 Clearing the Hit Count Table of Prefix List Entries ....................................7.2-160
7.2.7.2.4 How the System Filters Traffic by Prefix List .............................................7.2-160
7.2.7.3 Distribute-Lists......................................................................................................7.2-160
7.2.7.4 Route Maps ..........................................................................................................7.2-161
7.2.8 Triggered RIP ..................................................................................................................7.2-162
7.2.9 Administrative Distance ...................................................................................................7.2-162
7.2.10 RIP Update Filtering ........................................................................................................7.2-162
7.2.11 Disabling update source IP address validation ................................................................7.2-163
7.3 RIP Configuration Example .........................................................................................................7.3-164
7.4 RIP Statistics...............................................................................................................................7.4-165
7.5 RIP Debug and Trace .................................................................................................................7.5-166
8 RIP FOR IPV6 OR RIPNG .....................................................................................................................7.5-167
8.1 Introduction .................................................................................................................................8.1-167
8.2 Configuration...............................................................................................................................8.2-168
8.2.1 Global configuration mode ...............................................................................................8.2-168
8.2.2 Router configuration ........................................................................................................8.2-168
8.2.3 Configuring Interface Parameters ....................................................................................8.2-170
8.3 RIPng Statistics...........................................................................................................................8.3-171
8.3.1 General RIPng statistics ..................................................................................................8.3-171
8.3.2 Further RIPng statistics ...................................................................................................8.3-171
8.4 RIPng debugging ........................................................................................................................8.4-172
9 BORDER GATEWAY PROTOCOL (BGP-4) .........................................................................................8.4-173
9.1 Introduction to BGP.....................................................................................................................9.1-173
9.2 BGP Configuration ......................................................................................................................9.2-174
9.2.1 Required BGP Configuration Steps .................................................................................9.2-175
9.2.1.1 Enabling BGP Routing .........................................................................................9.2-175
9.2.1.2 BGP Neighbor Configuration ................................................................................9.2-176
9.2.1.3 BGP Peer Group Creation ....................................................................................9.2-176
9.2.1.4 Neighbor Membership Configuration in a Peer Group..........................................9.2-176
9.2.1.5 Assignment of Routing Policies and Attributes .....................................................9.2-177
9.2.1.6 Disabling a Peer or Peer Group ...........................................................................9.2-180
9.2.2 Additional BGP Configuration Steps ................................................................................9.2-181
9.2.2.1 Configuring TCP MD5 signature option for BGP sessions ...................................9.2-181
9.2.2.2 Load Sharing ........................................................................................................9.2-182
9.2.2.3 Backdoor Routes ..................................................................................................9.2-182
9.2.2.4 Administrative Distance ........................................................................................9.2-182
9.2.2.5 Route Redistribution .............................................................................................9.2-183

9.2.2.6 Modification of BGP Routing ................................................................................9.2-183

9.2.2.6.1 Disabling AS Path Comparison .................................................................9.2-183
9.2.2.6.2 Enabling Router ID Comparison................................................................9.2-184
9.2.2.6.3 Configuration of Router ID.........................................................................9.2-184
9.2.2.6.4 Configuration of Default Local Preference ................................................9.2-184
9.2.2.6.5 Disabling Default Next-Hop Processing ....................................................9.2-184
9.2.2.6.6 Multi Exit Discriminator Metric (MED) Configuration .................................9.2-185
9.2.2.6.7 Administrative Weight ...............................................................................9.2-186
9.2.2.7 BGP Timer Configuration .....................................................................................9.2-186
9.2.3 Routing Policies ...............................................................................................................9.2-187
9.2.3.1 AS Path Filter Definition .......................................................................................9.2-187
9.2.3.2 Community List.....................................................................................................9.2-188
9.2.3.3 Routing Policies Applied to Neighbors .................................................................9.2-188
9.2.3.3.1 Route Filtering ...........................................................................................9.2-188
9.2.3.3.2 AS Path Filtering .......................................................................................9.2-189
9.2.3.3.3 Route Map.................................................................................................9.2-189
9.2.4 BGP Optimizations ..........................................................................................................9.2-190
9.2.4.1 Configuration of Aggregate Address ....................................................................9.2-190
9.2.4.2 AS Confederation .................................................................................................9.2-191
9.2.4.3 Route Reflector Configuration ..............................................................................9.2-192
9.2.4.4 Route Flap Dampening.........................................................................................9.2-192
9.2.4.4.1 Enabling Route Dampening ......................................................................9.2-193
9.2.4.4.2 BGP Flap Dampening Statistics ................................................................9.2-193
9.2.4.5 Route summarization ...........................................................................................9.2-194
9.2.4.6 BGP Fall-over .......................................................................................................9.2-195
9.2.4.6.1 Tracking a peer by means of a route map.................................................9.2-195
9.2.4.6.2 Tracking a peer by means of BFD.............................................................9.2-196
9.3 BGP Management ......................................................................................................................9.3-197
9.3.1 BGP SNMP Traps ...........................................................................................................9.3-197
9.3.2 Connection Resets ..........................................................................................................9.3-197
9.3.2.1 Dynamic Inbound Soft Reset ................................................................................9.3-197
9.3.2.2 Outbound Soft Reset ............................................................................................9.3-197
9.3.2.3 Soft Reset Configuration Using Stored Routing Policy Information ......................9.3-198
9.3.2.4 eBGP Connection Reset after Link Failure ...........................................................9.3-198
9.4 BGP Configuration Example .......................................................................................................9.4-199
9.5 BGP Statistics .............................................................................................................................9.5-200
9.6 BGP debug .................................................................................................................................9.6-203
10 OPEN SHORTEST PATH FIRST PROTOCOL (OSPF) ........................................................................9.6-205
10.1 OSPF Introduction and Features ..............................................................................................10.1-205
10.1.1 Advantages of OSPF .....................................................................................................10.1-206
10.1.2 Disadvantages of OSPF ................................................................................................10.1-206
10.2 OSPF Features .........................................................................................................................10.2-207
10.3 OSPF Configuration ..................................................................................................................10.3-208
10.3.1 Enabling OSPF ..............................................................................................................10.3-208
10.3.1.1 On a Broadcast & Point-To-Point Network .........................................................10.3-208
10.3.1.2 Non-Broadcast Networks....................................................................................10.3-209
10.3.2 Router Priority................................................................................................................10.3-209
10.3.3 Router ID .......................................................................................................................10.3-209
10.3.4 Area Settings .................................................................................................................10.3-210
10.3.4.1 Route Summarization .........................................................................................10.3-210
10.3.4.2 Stub Areas..........................................................................................................10.3-210
10.3.4.3 Not So Stubby Areas (NSSA) .............................................................................10.3-210
10.3.4.4 Virtual Links ........................................................................................................10.3-210
10.3.4.5 Authentication.....................................................................................................10.3-211
10.3.5 Configuring Interface Parameters ..................................................................................10.3-211
10.3.5.1 Interface Passivation ..........................................................................................10.3-211
10.3.5.2 Authentication.....................................................................................................10.3-211
10.3.5.3 Interface Cost .....................................................................................................10.3-212
10.3.5.4 Route Redistribution and Interworking with Other Routing Protocols .................10.3-212
10.3.5.4.1 Administrative Distance...........................................................................10.3-212
10.3.5.4.2 Distribute List ..........................................................................................10.3-212
10.3.5.4.3 Route Redistribution................................................................................10.3-213
10.3.6 OSPF Tuning .................................................................................................................10.3-215
10.3.6.1 Timers ................................................................................................................10.3-215

10.3.6.2 Override MTU Check ..........................................................................................10.3-216

10.3.6.3 Opaque LSA .......................................................................................................10.3-216
10.3.6.4 OSPF Behavior Tuning.......................................................................................10.3-216
10.3.6.5 Overflow Management of External Routes .........................................................10.3-216
10.4 OSPF Statistics .........................................................................................................................10.4-217
10.5 OSPF Debug.............................................................................................................................10.5-218
11 OSPFV3 OR OSPF FOR IPV6.............................................................................................................10.5-219
11.1 Introduction ...............................................................................................................................11.1-219
11.2 Configuration.............................................................................................................................11.2-220
11.2.1 Global configuration mode .............................................................................................11.2-220
11.2.2 Router configuration ......................................................................................................11.2-220
11.2.3 Area configuration .........................................................................................................11.2-223
11.2.4 Configuring Interface Parameters ..................................................................................11.2-225
11.3 OSPFv3 Statistics .....................................................................................................................11.3-227
11.3.1 General OSPFv3 statistics.............................................................................................11.3-227
11.3.2 Further OSPFv3 statistics ..............................................................................................11.3-227
11.4 OSPFv3 Debugging ..................................................................................................................11.4-229
12 BI-DIRECTIONAL FORWARDING DETECTION (BFD) .....................................................................11.4-231
12.1 BFD Features............................................................................................................................12.1-231
12.2 BFD Configuration Commands .................................................................................................12.2-232
12.3 BFD Statistics ...........................................................................................................................12.3-234
12.4 BFD Configuration Example .....................................................................................................12.4-234
13 MULTICAST ROUTING .......................................................................................................................12.4-235
13.1 Principles of Multicast Routing ..................................................................................................13.1-235
13.1.1 Why Multicast ................................................................................................................13.1-235
13.1.2 Components of a Multicast Network ..............................................................................13.1-235
13.2 Protocol Independent Multicast (PIM) .......................................................................................13.2-237
13.2.1 Introduction ....................................................................................................................13.2-237
13.2.2 PIM-SM Configuration Steps .........................................................................................13.2-237
13.2.3 PIM-SM configuration commands ..................................................................................13.2-238
13.2.3.1 Enabling Multicast Routing .................................................................................13.2-238
13.2.3.2 Enabling PIM Sparse Mode on interfaces ..........................................................13.2-238
13.2.3.3 Configuring Static RP .........................................................................................13.2-238
13.2.3.4 Configuring Candidate RP ..................................................................................13.2-239
13.2.3.5 Configuring Candidate BSR ...............................................................................13.2-239
13.2.3.6 Configuring SPT switching threshold..................................................................13.2-239
13.2.3.7 Configuring Register source address .................................................................13.2-240
13.2.3.8 Configuring Source Specific Multicast (SSM) .....................................................13.2-240
13.2.3.9 Configuring PIM logging .....................................................................................13.2-240
13.2.3.10 Configuring IP Multicast Static Route .................................................................13.2-240
13.2.3.11 Configuring longest prefix match criteria ............................................................13.2-241
13.2.3.12 Configuring IP Multicast Route Limit ..................................................................13.2-241
13.2.3.13 Configuring TTL Threshold on interfaces ...........................................................13.2-241
13.2.3.14 Configuring IP Multicast Scope Group on interfaces ..........................................13.2-242
13.2.3.15 Configuring BSR border on interfaces ................................................................13.2-242
13.2.3.16 Configuring DR priority on interfaces ..................................................................13.2-242
13.2.4 Configuration Example ..................................................................................................13.2-243
13.2.5 Statistics ........................................................................................................................13.2-245
13.2.6 Debug and Trace ...........................................................................................................13.2-245
13.3 IGMP .........................................................................................................................................13.3-247
13.3.1 Features ........................................................................................................................13.3-247
13.3.2 Configuring IGMP ..........................................................................................................13.3-247
13.3.2.1 Enabling Multicast Routing .................................................................................13.3-247
13.3.2.2 Enabling IGMP ...................................................................................................13.3-247
13.3.2.3 Configuring IGMP Timers ...................................................................................13.3-248
13.3.2.4 Configuring IGMP Access Policies .....................................................................13.3-248
13.3.2.5 Configuring IGMP Static Group ..........................................................................13.3-248
13.3.2.6 Configuring IGMP snooping ...............................................................................13.3-248
13.3.3 Configuring IGMP Proxy ................................................................................................13.3-249
13.3.3.1 Interface definition ..............................................................................................13.3-249
13.3.3.2 Proxy behavior ...................................................................................................13.3-249

13.3.3.3 Configuring Proxy support ..................................................................................13.3-250

13.3.4 IGMP Statistics ..............................................................................................................13.3-251
13.3.5 IGMP Debugging ...........................................................................................................13.3-252
14 ZONE-BASED FIREWALL ..................................................................................................................13.3-253
14.1 Zone-Based Firewall Overview .................................................................................................14.1-253
14.1.1 Firewall ..........................................................................................................................14.1-254
14.1.2 Zone ..............................................................................................................................14.1-254
14.1.3 Zone-pair .......................................................................................................................14.1-254
14.1.4 Policy .............................................................................................................................14.1-254
14.1.5 Filters .............................................................................................................................14.1-255
14.1.5.1 Address collections ............................................................................................14.1-255
14.1.5.2 Services..............................................................................................................14.1-255
14.1.6 Parameters ....................................................................................................................14.1-256
14.2 Zone-Based Firewall Policy database .......................................................................................14.2-257
14.3 Zone-Based Firewall Configuration ...........................................................................................14.3-259
14.3.1 Basic configuration ........................................................................................................14.3-259
14.3.1.1 Zone-Based Firewall license activation ..............................................................14.3-259
14.3.1.2 Creating a firewall instance ................................................................................14.3-259
14.3.1.3 Using another VRF than the default VRF ...........................................................14.3-259
14.3.1.4 Adding zones to a firewall instance ....................................................................14.3-260
14.3.1.5 Assigning an interface to a zone ........................................................................14.3-260
14.3.1.6 Defining filters on a firewall instance ..................................................................14.3-260
14.3.1.7 Defining policies on a firewall instance ...............................................................14.3-261
14.3.1.8 Adding zone pairs to a firewall instance .............................................................14.3-262
14.3.2 Advanced configuration .................................................................................................14.3-262
14.3.2.1 Inspection configuration......................................................................................14.3-263
14.3.2.2 Filter configuration ..............................................................................................14.3-263
14.3.2.3 Policy configuration ............................................................................................14.3-263
14.3.2.4 Address-collection configuration.........................................................................14.3-264
14.3.2.5 Service configuration ..........................................................................................14.3-265
14.3.2.6 Application Level Gateways – ALG – configuration ............................................14.3-266
14.3.2.7 Maximum number of connections configuration .................................................14.3-267
14.3.2.8 Parameter set configuration ...............................................................................14.3-267
14.3.2.9 Attacks configuration ..........................................................................................14.3-269
14.3.2.10 Flow statistics configuration................................................................................14.3-270
14.3.2.11 Logging configuration .........................................................................................14.3-270
14.4 Zone-Based Firewall Statistics ..................................................................................................14.4-273
15 OPEN SOURCE SOFTWARE .............................................................................................................14.4-277

2 I N T E R N E T P R O T O C O L V E R S I O N 6 ( I P V 6 )
OneOS implementation is intended to fulfill all requirements of the “IPv6-ready silver logo”
(http://www.ipv6ready.org/) and partially “IPv6-ready gold”. IPv6 is introduced in OneOS to make it a dual-
stack IPv4-IPv6 router. “Dual-stack” means that router interfaces can be configured with IPv4 and IPv6
addresses and are able to transmit and receive IPv6 and IPv4 packets.
2.1 INTRODUCTION TO ONEOS IPV6 FEATURES
2.1.1 IPv6 Address Writing Rules
2.1.1.1 IPv6 Addresses
IPv6 address format is specified in RFC 2373; IPv6 addresses are written as a series of 16-bit
hexadecimal fields separated by colons. For example:
• 2001:0DB8:7654:3210:FEDC:BA98:7654:3210
• 2001:0DB8:0:0:8:800:200C:417A
Writing IPv6 addresses can be cumbersome. Fortunately, IPv6 addresses often contain many zeroes,
which enable to simplify the writing of IPv6 addresses in a more compact form. Two colons (::) designate a
portion of the IPv6 address, which is filled with zeroes. There can be only one (::) in the IPv6 address,
which can be at the beginning, middle or end of the address.
Normal Format Compressed Format

2001:0:0:0:0DB8:800:200C:417A 2001::0DB8:800:200C:417A
FF01:0:0:0:0:0:0:101 FF01::101
0:0:0:0:0:0:0:1 ::1
0:0:0:0:0:0:0:0 ::
The hexadecimal writing of IPv6 addresses is not case-sensitive in OneOS CLI.
2.1.1.2 IPv6 Prefix
An IPv6 address prefix is a block of contiguous addresses sharing a common bit-wise prefix. The IPv6
prefixes are documented following recommendation of RFC 2373. The IPv6 prefix is composed of an IPv6
address prefix (encoded in the same format as an IPv6 address) and a prefix length.
The prefix length is a decimal value that indicates how many of the high-order contiguous bits of the
address comprise the prefix (the network portion of the address). For example, 2001:0DB8:8086:6502::/32
is a valid IPv6 prefix. The range value for this prefix is <0 to 128> with 0 and 128 included.

2.1.1.3 IPv6 URL
An HTTP URL is written as follows in IPv4: http://1.2.3.4:8080. This URL form cannot be used as is with
IPv6 as the colon is used as a separator to provide the port number. The RFC 2732 specifies how to write
IPv6-compatible URL by using brackets. RFC examples:
• http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html
• http://[1080:0:0:0:8:800:200C:417A]/index.html
• http://[3ffe:2a00:100:7031::1]
• http://[1080::8:800:200C:417A]/foo
• http://[::192.9.5.5]/ipng
• http://[::FFFF:129.144.52.38]:80/index.html
• http://[2010:836B:4179::836B:4179]
2.1.2 IPv6 Features
The IPv6 stack implements Internet Control Message Protocol (ICMPv6), MLD, Transmission Control
Protocol (TCP), User Datagram Protocol (UDP), as well as a number of advanced features including
Access Control Lists (ACL).
2.1.2.1 IPv6 Fast Forwarding
To achieve high forwarding performance, IP fast-forwarding has been implemented to create a fast routing
of packets once the path to a specific destination has been for the most common IP packets except those,
which require fragmentation or with specific options. It makes use of a route cache to accelerate routing
table lookup and contains many other techniques to optimize fast forwarding processing. As a result, the
overall forwarding performance is considerably improved.
2.1.2.2 Multiple IPv6 Addresses per Interface
Multiple addresses can be assigned to one network interface such that multiple logical networks can be
supported on a single physical network.
2.1.2.3 IPv6 Virtual Interfaces
Virtual network interfaces are software interfaces that do not require a physical interface to run. Currently,
virtual network interfaces include Virtual-Ethernet, Loopback, and Null interfaces. A Virtual-Interface allows
applying IP services in input and/or output of any interface that normally does not allow this (for example,
at the input and output of a Pseudo-Wire Encapsulation tunnel). A Loopback interface loops all output
packets back to IP. It can be used to virtually hold an IP address (not assigned to a physical port). The Null
interface (much like the UNIX /dev/null device) discards all output packets and can be used to easily make
routes unreachable.
2.1.2.4 IPv6 Static Routing
The case where several static routes have the same IPv6 prefix but different destinations (or
gateway/interfaces) is not supported at present (see ECMP in IPv4 chapter).
2.1.2.5 IPv6 Dynamic Routing
BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing are available as of V5.1R5E1 software
release. RIPng for IPv6 and OSPFv3 for IPv6 are available as of V5.2R1E1. Refer to the corresponding
IPv4 chapters for more information about these dynamic routing protocols
2.1.2.6 IPv6 Virtual Routing and Forwarding (VRF)
IPv6 VRF-aware framework is available as of V5.2R1E1 software release. Refer to the corresponding IPv4
for more information about virtual routing and forwarding.

2.1.2.7 IPv6 Packet Processing Path
The processing path is the same as that for IPv4 (see diagram in "IP Packet Processing Path" section of
"IPv4 Features" chapter of "OneOS – Basic IP User Guide" document). But at present, NAT is not
supported with IPv6.
2.2 IPV6 CONFIGURATION COMMANDS
The parameter values given in the configuration commands are all informal. – Users should replace them
with the appropriate values.
2.2.1 IPv6 activation on an interface
IPv6 is disabled by default in ONEOS. One needs to explicitly activate IPv6 per interface by either
configuring an IPv6 address on the interface, or by using the following command in interface configuration
mode:
CLI> configure terminal
CLI(config)> interface <type> <unit>
CLI(config-if)> ipv6 enable
IPv6 will be activated and its processing will be enabled on the interface where the above command is
applied.
The no ipv6 enable command is supported on interface level mode and can be used for de-
activating/disabling IPv6 on different interfaces, independently:
CLI(config)> interface <type> <unit>
CLI(config-if)> no ipv6 enable
IPv6 processing will be disabled on the interface where above command is applied.
Notes:
• In factory-default configuration, IPv6 processing will be disabled on all interfaces, and no information
related to an IPv6 address (or related protocols e.g. ND etc.) will be displayed in the
show ipv6 interface command. An auto-configured IPv6 link local address will not be configured
and displayed on any interface either.
• IPv6 can be activated by explicitly configuring an IPv6 address on the interface.
When all explicitly configured IPv6 addresses are removed from the interface (where the
no ipv6 enable command is configured), IPv6 will get deactivated automatically on that interface.
• If an interface is not configured with the ipv6 enable command and an IPv6 address is configured
on that interface, then the no ipv6 address command will deactivate IPv6 on the interface.
• The show ipv6 interface command will display IPv6 is enabled, only when IPv6 is activated
on that interface.
In factory default setting or when IPv6 is deactivated on all interfaces, no output will be displayed
when running the show ipv6 interface command.
• IPv6 packets will not be processed and will be dropped on the interface, on which IPv6 is not
activated.

2.2.2 IPv6 Addresses Configuration
2.2.2.1 Static IPv6 Address configuration
To assign an IPv6 address to an interface, use the following command in interface configuration mode:
CLI(configure)> interface <type> <unit>
CLI(config-if)> ipv6 address <ipv6-address>/<prefix-len>
The ipv6-address must be written as described in section 2.1.1.1. The prefix-len is a decimal value
ranging from 0 to 128, which indicates the bit mask length of associated interface prefix. This command
can be entered multiple times to add several IPv6 addresses on the interface.
To delete an IPv6 address, use the no form of the above-referenced command:
CLI(config-if)> no ipv6 address <ipv6-address>/<prefix-len>
As of V5.1R5E3 software release, the following commands are obsolete. They cannot be used any longer.
CLI(config-if)> ipv6 address prefix <ipv6-address>/<prefix-len>
CLI(config-if)> no ipv6 address prefix <ipv6-address>/<prefix-len>
2.2.2.2 Stateless Auto-configuration of IPv6 Address
Stateless auto-configuration is a function enabled by ICMPv6 that enables an interface to acquire a global
unicast IPv6 address. Initially, the interface has got a link-local address, which is built from fe80::/10 prefix
and router MAC address. This link-local address enables IPv6 communication with host connected on the
same layer-2 link (such as PPP link or Ethernet interface). Some ICMPv6 messages are exchanged
(namely Router Solicitation and Router Advertisements –RA–), such that the interface can acquire its own
address assigned by the router.
To enable a router to get its IPv6 address via stateless auto-configuration, use the following command in
interface configuration mode. Use the optional default keyword to automatically add a default route
using the default router if any is selected on the interface.
CLI(config-if)> ipv6 address autoconfig [default]
To return to the default value (disabled auto-configuration), use the following command:
CLI(config-if)> no ipv6 address autoconfig
2.2.2.3 Static IPv6 anycast address configuration
To assign an IPv6 anycast address to an interface, use the following command in interface configuration
mode:
CLI(config-if)> ipv6 address <ipv6-prefix>/<prefix-len> anycast
The ipv6-prefix must be written as described in section 2.1.1.1. The prefix-len is a decimal value
ranging from 0 to 128, which indicates the bit mask length of associated interface prefix.
To delete an IPv6 anycast address, use the no form of the above-referenced command:
CLI(config-if)> no ipv6 address <ipv6-prefix>/<prefix-len> anycast
CLI(config-if)> ipv6 address prefix <ipv6-address>/<prefix-len> anycast
CLI(config-if)> no ipv6 address prefix <ipv6-addr>/<prefix-len> anycast

2.2.2.4 Static IPv6 address configuration using a EUI-64 interface ID
To assign an IPv6 EUi-64 address to an interface using a EUI-64 interface ID in the low order 64 bits of the
address, use the following command in interface configuration mode:
CLI(config-if)> ipv6 address <ipv6-prefix>/<prefix-len> eui-64
The ipv6-prefix must be written as described in section 2.1.1.1. The prefix-len is a decimal value
ranging from 0 to 128, which indicates the bit mask length of associated interface prefix.
To delete an IPv6 EUI-64 address, use the no form of the above-referenced command:
CLI(config-if)> no ipv6 address <ipv6-prefix>/<prefix-len> eui-64
CLI(config-if)> ipv6 address prefix <ipv6-address>/<prefix-len> eui-64
CLI(config-if)> no ipv6 address prefix <ipv6-addr>/<prefix-len> eui-64
2.2.2.5 Static IPv6 link-local address configuration
To assign an IPv6 link-local address to an interface and override the link-local address that is automatically
generated for the interface, use the following command in interface configuration mode:
CLI(config-if)> ipv6 address <ipv6-address> link-local
The ipv6-address must be written as described in section 2.1.1.1. Only one link-local address can be
configured on a given interface.
To delete an IPv6 link-local address, use the no form of the above-referenced command:
CLI(config-if)> no ipv6 address <ipv6-address> link-local
2.2.2.6 IPv6 address configuration using prefix delegation
To assign an IPv6 address whose prefix has been learned using DHCP client prefix delegation, use the
following command in interface configuration mode:
CLI(config-if)> ipv6 address prefix-name <name> <ipv6-suffix/prefix-len>
name is the name of the prefix learned using DHCP client prefix delegation. This prefix gives the leading
bits of the IPv6 address.
ipv6-suffix is the part of the address to be concatenated with the prefix. It must be written as described
in section 2.1.1.1.
prefix-len is a decimal value ranging from 0 to 128, which indicates the bit mask length of associated
interface prefix.
The command can be entered multiple times to add several IPv6 addresses on the interface.
To delete an IPv6 address whose prefix has been learned using DHCP client prefix delegation, use the no
form of the above-referenced command:
CLI(config-if)> no ipv6 address prefix-name <name>
<ipv6-address>/<prefix-len>
Refer to 3.2.1 for more information about DHCP client prefix delegation.

2.2.2.7 Configuration of IPv6 Addressing for PPP Interfaces
The PPP protocol has been extended to support IPv6. The IP Control Protocol (IPCP) is adapted to IPv6 in
a new flavor called IPv6CP. With IPv6CP, the PPP peers exchange their IPv6 prefixes. If the PPP interface
of an OneOS-based router is in stateless auto-configuration mode, the PPP interface can get its IP
address through ICMPv6. In other words, there are no PPP-specific commands for IPv6: the OneOS-
based router just needs to be configured with a static IPv6 address/prefix or it must be in stateless
autoconfiguration.
2.2.3 Enabling IPv6 Forwarding
To enable or disable IP forwarding, use the following command in global configuration mode:
CLI(configure)> [no] ipv6 unicast-routing
Default: enabled.
2.2.4 Static IPv6 Routes Configuration
To add a static IPv6 route for any destination, use the following command in global configuration mode:
CLI(configure)> [no] ipv6 route [vrf <vrf-name>] <ipv6-address-prefix>
{ <gateway> | <interface> }
[<distance>] [<bfd-neighbor>]
o ipv6-address-prefix is under the form X:X:X:X::X/<0-128> (see 2.1.1.2).

o gateway is the IPv6 address of the next hop router.
o interface is the interface type and unit number, when routing on a per-interface basis (such
as serial 0/0).
o distance is the administrative distance of the route. The value for distance can be
configured from 1 to 255.
To add a default route through a gateway, use the following command:
CLI(configure)> ipv6 route [vrf <vrf-name>] ::/0 {<gateway>|<interface>}
To add a route to block undesirable traffic (known as black hole routing), use the following command:
CLI(configure)> ipv6 route <ipv6-address-prefix> null 0
Defined traffic will be dynamically routed to a dead interface.
2.2.5 Flow based Load Sharing
To set the load sharing mode, use the following command in global configuration mode:
CLI(configure)> ipv6 load-sharing [vrf <vrf-name>]
{ per-destination | per-session | per-packet }
With:
o per-destination. This is the default mode. The load is shared according to source and
destination IP addresses.
o per-session. The load is shared according to source and destination IP addresses, ports,
and IP protocol number.
o per-packet. The load is shared by sending packets over successive equal cost paths in a
round-robin mode.
o The vrf-name is optional. If not provided, the default VRF is used.

2.2.6 IPv6 Neighbor Discovery Configuration
2.2.6.1 RA interval configuration
To define the interval between two successive RA (Router Advertisement) on a given interface, use the
CLI(config-if)> ipv6 nd ra-interval <max> [<min>]
max value ranges from 4 to 1800 seconds; default value is 200 seconds.
min value must be lower than three quarters of max value. By default, when not defined, min value is set
to one third of the max value.
The actual value used for the interval is randomly taken between max and min values to avoid
synchronized sending.
To return to the default values, use the following command:
CLI(config-if)> default ipv6 nd ra-interval
2.2.6.2 RA lifetime configuration
To define the router lifetime sent in Router Advertisements (RA) on a given interface, use the following
command in interface configuration mode:
CLI(config-if)> ipv6 nd ra-lifetime <lifetime>
lifetime value ranges from 0 to 9000 seconds; default value is 1800 seconds. It represents the time the
router can be used as default router on the interface. Value 0 is used to indicate that the router cannot be
used as default router.
To return to the default value, use the following command:
CLI(config-if)> default ipv6 nd ra-lifetime
2.2.6.3 RA suppress configuration
To suppress Router Advertisements (RA) sending on a given interface, use the following command in
interface configuration mode:
CLI(config-if)> ipv6 nd suppress-ra
By default, RAs are sent on the interface. To re-enable RA sending on the interface, use the no form of the
above-referenced command:
CLI(config-if)> no ipv6 nd suppress-ra
2.2.6.4 ND Reachable time configuration
The reachable timer allows the router to detect unreachable neighbors. To define the time for how long a
router is considered reachable after is has been declared reachable, use the following command in
CLI(config-if)> ipv6 nd reachable-time <reachtime>
reachtime value ranges from 0 to 3,600,000 milliseconds; default value is 0 (unspecified).

To return to the default value (unspecified), use the following command:
CLI(config-if)> default ipv6 nd reachable-time

2.2.6.5 ND RA flags configuration
To set the "other configuration flag" in Router Advertisements (RA) indicating to connected hosts that they
can use Stateless auto-configuration to obtain other information (other than addresses), use the following
CLI(config-if)> ipv6 nd other-config-flag
To return to the default value (flag not set), use the no form of the above-referenced command:
CLI(config-if)> no ipv6 nd other-config-flag
To set the "managed configuration flag" in Router Advertisements (RA) indicating to connected hosts that
they can use Stateful auto-configuration to obtain addresses and other information, use the following
CLI(config-if)> ipv6 nd managed-config-flag
To return to the default value (flag not set), use the no form of the above-referenced command:
CLI(config-if)> no ipv6 nd managed-config-flag
2.2.7 IPv6 host name/address binding
To create an IPv6 host name/address binding, use the following command in global configuration mode:
CLI(configure)> ipv6 host <hostname> <ipv6-address>
To delete the IPv6 host name/address binding, use the no form of the above-referenced command:
CLI(configure)> no ipv6 host
2.2.8 ICMPv6 configuration commands
• Use the following command in global configuration mode to configure the time interval, expressed in
milliseconds, between ICMP error messages that are sent:
CLI(configure)> ipv6 icmp error-interval <0-2147483647>
To reset this interval to the default value, use the default form of this command.
• By default, ICMP unreachable messages are sent. The user however can disable the sending of these
messages by entering the following command in interface configuration mode:
CLI(config-if)> no ipv6 unreachables
• To re-enable the sending of ICMP unreachable messages, use the following command in interface
configuration mode:
CLI(config-if)> ipv6 unreachables
• Use the following command in global configuration mode to set the rate, in milliseconds, with which
ICMP unreachable messages are sent:
CLI(configure)> ipv6 icmp rate-limit unreachable <1-4294967295>

2.2.9 ICMPv6 redirect messages
• If the OneOS software is forced to resend a packet through the same interface on which the packet
was received, an ICMPv6 redirect message is sent.
By default, the sending of these ICMPv6 redirect messages is enabled.
The user however can disable the sending of these messages by entering the following command in
CLI(config-if)> no ipv6 redirects
• To re-enable the sending of the ICMPv6 redirect messages, use the following command in interface
configuration mode:
CLI(config-if)> ipv6 redirects
2.2.10 IPv6 DNS Configuration Commands
2.2.10.1 Setting DNS server addresses
To enable the IPv6 DNS relay/proxy, the only thing required is to set one or more DNS server addresses.
This can be done by using the following command in global configuration mode:
CLI(configure)> ipv6 dns-proxy dns-server <server1>
[<server2>] [<server3>] [vrf <vrf-name>]
o At least one IPv6 address must be specified, <server1>;

another 2 addresses, <server2> and <server3> can be added optionally.
By default, the DNS relay/proxy is disabled.
DNS servers must be defined on a per-VRF basis. OneOS can learn DNS servers (via DHCP, IPCP). The
learnt DNS servers will be valid for the VRF corresponding to the interface from which the DNS servers
were learnt (by default all the interfaces are in the default VRF).
DNS server addresses can also be learned; this is described in the next section.
2.2.10.2 Learning DSN server addresses
In some application cases, the IPv6 DNS server is known via DHCP and/or IPCP (on PPP based
connections). OneOS holds up to 4 learnt DNS server addresses. If one DNS server does not answer, the
next one is queried. The following command in global configuration mode forces the DNS proxy to use the
dynamically learnt DNS servers.
CLI(configure)> ipv6 dns-proxy dns-server learn
[<server2>] [<server3>] [vrf <vrf-name>]
To define the priority among the learnt DNS servers, use the following command in global configuration
mode:
CLI(configure)> [no] ipv6 dns-proxy dns-server learn
priority { dhcp | none } [vrf <vrf-name>]
Another way to define the priority among the learnt servers, independent from the previous one, is to use
the following command in global configuration mode; the priority is given by the order of the given
interfaces:
CLI(configure)> ipv6 dns-proxy dns-server learn from <interface1>
[ <interface2> [ <interface3 [ <interface4> ]]]
[vrf <vrf-name>]
When DNS resolution cannot happen because a DNS server has not been learned yet (for example, when
the PPP connection to learn the DNS from, is not open because DNS resolution has not happened), a
default DNS server address has to be provided so that the DNS proxy can use this address as the default

DNS server as long as it has not learned a DNS server.

Use the following command to set a default DNS server:
CLI(configure)> ip dns-proxy dns-server learn default-server <ip-addr>
[vrf <vrf-name>]
If the default server address is not valid, it is used only to open the connection to learn the DNS.
When the default server address is valid, the default server gets the lower priority.
To stop learning the DNS server addresses, use the following command in global configuration mode:
CLI(configure)> no ipv6 dns-proxy dns-server learn [vrf <vrf-name>]
2.2.10.3 Using the FQDN
To enable the IPv6 DNS relay/proxy making use of a FQDN or Fully Qualified Domain Name, use the
following command:
CLI(configure)> ipv6 dns-proxy fqdn <fqdnName>
o <fqdnName> is in the form <name>.<domain>.<extension>.
2.2.10.4 Setting the IPv6 name server address
To set the IPv6 name server addresses (up to 3), use the following command:
CLI(configure)> ipv6 name-server <dns-address1> [<dns-address2>]
[<dns-address3>] [vrf <vrf-name>]
[family-priority]
[learn-priority { STATIC | default }]
• <dns-address1>. This is the IPv6 address of the name server.

• <dns-address2>. Optionally, a second IPv6 name server address can be added.
• <dns-address3>. Optionally, a third IPv6 name server address can be added.
• vrf <vrf-name>. Optionally, a vrf-name can be added. If not provided the default VRF is used.
• family-priority. Adding this option makes sure that IPv6 DNS servers are used before the IPv4
ones; this is the default behavior.
• learn-priority { STATIC | default }. This option sets the priority between DNS servers
depending on the learning method.
Adding STATIC means that the priority of DNS servers is configured manually.
Adding default sets the learn-priority to default.
To delete the IPv6 domain name or IPv6 name server, use the no form of the command.
CLI(configure)> no ipv6 name-server <dns-address1> [<dns-address2>]
[<dns-address3>] [vrf <vrf-name>]
To globally delete the name servers, to set all DNS-related parameters to their default values, and to
remove all DNS commands from the running configuration, use the following command:
CLI(configure)> no ip name-server [vrf <vrf-name>]

2.2.11 Enabling IPv6 Reverse Path Forwarding
To enable IPv6 reverse path forwarding on an interface, in order to check the reverse path for the source
address of received IPv6 packets, enter the following command in interface configuration mode:
CLI(config-if)> ipv6 verify reverse-path [<acl_name>]
o Optionally, the name of an access list, <acl_name>, can be added to the command.
To disable IPv6 reverse path forwarding, use the no form of the command:
CLI(config-if)> no ipv6 verify reverse-path
2.2.12 IPv6 Prefix Delegation binding & filtering (SAVI)
SAVI stands for Source Address Validation Improvements.

In order to enable SAVI for prefix delegation, trusted and untrusted interfaces must be configured first.
Trusted and untrusted interfaces
An interface connected to a known DHCPv6 Server must be configured as trusted.

Interfaces connected to requesting routers or other switches/relay agents should be configured as
untrusted.
• To configure an interface as trusted, use the following command in interface configuration mode:
CLI(config-if)> ipv6 savi-dhcp trust
Use the no form of the command to undo:

CLI(config-if)> no ipv6 savi-dhcp trust
• To enable SAVI on an untrusted interface, use the following command in interface configuration mode:
CLI(config-if)> ipv6 savi-validation untrust
Use the no form to undo:

CLI(config-if)> no ipv6 savi-validation untrust
• A savi-dhcp trusted interface cannot be configured as savi-validation untrusted interface and

vice versa.
• When an interface is configured with savi-validation untrust, the interface starts dropping
traffic (except DHPCv6), so it is recommended to configure this in a scheduled maintenance.
• For the SAVI to be operational, at least a trusted and an untrusted interface need to be configured.
Configuring SAVI static entries
In order to add static IPv6 entries to the SAVI binding/filtering table, use the following command in general
configuration mode:
CLI(configure)> [no] ipv6 savi-entry <IPv6 prefix/IPv6 prefix length>
<anchor> <interface name/interface unit>
o The <anchor> binds the IPv6 prefix to the interface.

Use the no form of the command to delete a static entry.

2.3 IPV6 DEBUG AND STATISTICS
2.3.1 IPv6 Statistics
• To display the content of the IPv6 routing table, use the following command:
CLI> show ipv6 route
• To display IPv6 related information of an interface, use the following command:

CLI> show ipv6 interface [<type> <unit>]
o Example:
show ipv6 interface fastethernet 0/0
FastEthernet 0/0 is up, line protocol is down
Flags: (0x8021) MULTICAST ARP, interface index is 101
Encapsulation: Ethernet v2, MTU 1500 bytes
Down-time 01:38:55, status change count 0
Hardware address is 08:00:51:13:08:05, ARP timeout 7200 sec
Line speed unknown
Mean IP input/output rate 0/0 bits/s, 0/0 packets/s (over the last 4 seconds)
Output queuing strategy: fifo, output queue length/depth 0/126
Reliability: 255/255
IN: 0 packets, 0 bytes, 0 queue drops
0 broadcasts, 0 multicasts, 0 errors, 0 discards
0 unknown protocols
OUT: 0 packets, 0 bytes, 0 queue drops
0 broadcasts, 0 multicasts, 0 errors, 1 discards
• To display IP routing and TCP/UDP statistics, use the following command:

CLI> show ipv6 traffic
o Example:
IPv6 statistics:
IN: 0 total, 0 local destination (0/0 queue length/drops)
0 too short, 0 bad version, 0 can't forward
0 bad option, 0 bad scope
0 fragments received, 0 packets reassembled, 0 fragments dropped, 0 timeouts
0 dropped by services
OUT: 0 forwarded, 0 local source
0 no route, 0 no buffer
0 packets fragmented, 0 can't fragment, 0 fragments created
0 dropped by services
UDPv6 statistics:
IN: 0 total, 0 no port (unicasts), 0 no port (broadcasts)
0 buffer-full drops, 0 checksum errors, 0 bad length, 0 too short
OUT: 0 total
TCPv6 statistics:
IN: 0 total
0 checksum error, 0 bad offset, 0 too short
0 packets (0 bytes) in sequence
0 dup packets (0 bytes)
0 partially dup packets (0 bytes)
0 out-of-order packets (0 bytes)
0 packets (0 bytes) with data after window
0 packets after close
0 window probe packets, 0 window update packets
0 dup ack packets, 0 ack packets with unsend data
0 ack packets (0 bytes)
OUT: 0 total, 0 urgent packets
0 control packets
0 data packets (0 bytes)
0 data packets (0 bytes) retransmitted
0 ack only packets (0 delayed)
0 connections established (including 0 initiated, 0 accepted)
0 connections closed (including 0 dropped, 0 embryonic dropped)
0 total rxmt timeout, 0 connections dropped in rxmt timeout
0 keepalive timeout, 0 keepalive probe, 0 connections dropped in keepalive

• Use the following command to display the IPv6 DNS server addresses:
CLI> show ipv6 name-server [vrf <vrf-name>]
Used DNS servers addresses :
80.201.237.239
80.201.237.238
o Optionally, a VRF name can be added.

• Use the following command to display the IPv6 DNS server addresses that were learned:
CLI> show ipv6 name-server by-learn [vrf <vrf-name>]
Available DNS servers addresses :
---------------------------------
Configured :
Learned by DHCP :
80.201.237.239
80.201.237.238
Learned by IPCP :
Learned by RA :
o Optionally, a VRF name can be added.

• Use the following command to show the resolver configuration:
CLI> show ipv6 name-server config [vrf <vrf-name>]
Max used DNS servers addresses : 6
Retransmission time interval : 5 sec
Number of retransmission : 2
Number of servers learned : 2

Type priority set : STATIC 1 DHCP 2 RA 3 IPCP 4
Family priority set : IPv4 2 IPv6 1
Local domain name : (null)Optionally, a VRF name can be added.
• Use the following command to show IPv6 route cache:

CLI> show ipv6 cache [vrf <vrf-name>]
• Use the following command to show global IPv6 configuration parameters:

CLI> show ipv6 inspect config
tcp synwait-time is 30 sec
tcp finwait-time is 120 sec
tcp idle-time is 1800 sec
udp idle-time is 180 sec
icmpv6 idle-time is 30 sec
other idle-time is 300 sec
ftp idle-time is 30 sec
maximum opened sessions 5000
sessions alarm threshold 90
stateful packet inspection disabled

• Use the following command to show active IPv6 sessions:

CLI> show ipv6 inspect sessions <interface> <unit>
• Use the following command to show active stateful inspection sessions:

CLI> show ipv6 inspect stateful
• Use the following command to show IPv6 session statistics:

CLI> show ipv6 inspect statistics
• Use the following command to show IPv6 neighbor cache entries:

CLI> show ipv6 neighbors <interface> <unit>
• Use the following command to show the SAVI (Source Address Validation Improvement) status:
CLI> show ipv6 savi
IPv6 SAVI:
Status: Disable
SAVI binding num: 0
SAVI max binding num: 0
SAVI interface configuration:
DHCP Server Trusted interface(s):
SAVI untrusted interface(s):
• Use the following command to show the Binding State Table:

CLI> show ipv6 savi bst
• Use the following command to show the Forwarding Table:

CLI> show ipv6 savi ft
• Use the following command to show SAVI Statistics:

CLI> show ipv6 savi statistics
• Use the following command to show IPv6 reverse-path statistics, i.e. counter values and its access list
if there is an access list configured:
CLI> show ipv6 verify statistics

• Use the following command to clear IPv6 traffic statistics:

CLI> clear ipv6 traffic
• Use the following command to clear the IPv6 route cache:

CLI> clear ipv6 cache [vrf <vrf-name>]
• Use the following command to clear the IPv6 Network Discovery (ND) cache:
CLI> clear ipv6 neighbors [vrf <vrf-name>]
• Use the following command to clear IPv6 routing and TCP/UDP statistics:
CLI> clear ipv6 traffic
• Use the following command to clear the IPv6 active sessions:

CLI> clear ipv6 inspect session <ifname>
• Use the following command to clear the global statistics of IPv6 access lists:
CLI> clear ipv6 inspect statistics
Use the following command to reset the OSPFv3 process:

CLI> clear ipv6 ospf process [vrf <vrf-name>]
Use the following command to clear RIPng statistics:

CLI> clear ipv6 rip [vrf <vrf-name>]
Use the following command to clear SAVI (Source Address Validation Improvement) statistics:
CLI> clear ipv6 savi statistics
Use the following command to reset all IPv6 reverse path forwarding counters attached to interfaces:
CLI> clear ipv6 verify

2.3.2 ICMPv6 statistics
• To display ICMPv6 statistics, use the following command:

CLI> show icmpv6 statistics
ICMP statistics:
IN : 0 input, 0 checksum errors, 0 too short
0 unknown info type, 0 unknown error type, 0 unknown code
unreach msg: 0 routing, 0 admin, 0 scope, 0 address, 0 port
parameter problem: 0 header, 0 next header, 0 option
0 too big, 0 hoplimit exceeded, 0 reassembly timeout
0 echo request, 0 echo reply
0 group query, 0 group report, 0 group reduce
0 router solicit, 0 router advert, 0 redirects
0 neighbor solicit, 0 neighbor advert
OUT : 2 output, 0 rate-limited
unreach msg: 0 routing, 0 admin, 0 scope, 0 address, 0 port
parameter problem: 0 header, 0 next header, 0 option
0 too big, 0 hoplimit exceeded, 0 reassembly timeout
0 echo request, 0 echo reply
0 group query, 0 group report, 0 group reduce
0 router solicit, 0 router advert, 0 redirects
2 neighbor solicit, 0 neighbor advert
ICMPv6 error messages limited to 100 packets per seconds
• To reset the accounted flows (including counters) , use the following command:
CLI> clear icmpv6 counters

2.3.3 IPv6 Debugging
• Use this command to display debugging messages with regard to IPv6 packet traffic:
CLI> debug ipv6 packet { in | out }
To disable the debugging and return to default behavior, use the following command:
CLI> no debug ipv6 packet { in | out }
• Use this command to display debugging messages with regard to ICMPv6 neighbor discovery
transactions:
CLI> debug ipv6 nd
CLI> no debug ipv6 nd
• Use this command to display debugging messages with regard to ICMPv6 transactions:
CLI> debug ipv6 icmp
Note that ICMPv6 neighbor discovery transactions are not taken into account in this command, since
for these, the debug ipv6 nd command can be used.
CLI> no debug ipv6 icmp
• Use this command to debug IPv6 route cache:

CLI> debug ipv6 cache
CLI> no debug ipv6 cache
• Use this command to enable IPv6 DHCP debugging:

CLI> debug ipv6 dhcp
CLI> no debug ipv6 dhcp
• Use this command to enable ACLv6 inspection:

CLI> debug ipv6 inspect
CLI> no debug ipv6 inspect
• Use this command to debug the internal resolver:

CLI> debug ipv6 name-server
CLI> no debug ipv6 name-server
• Use this command to debug PBR:

CLI> debug ipv6 policy-based-routing
CLI> no debug ipv6 policy-based-routing

• Use this command to debug the IPv6 routing table:

CLI> debug ipv6 routing
CLI> no debug ipv6 routing
• Use this command to enable SAVI (Source Address Validation Improvement) debugging:
CLI> debug ipv6 savi
CLI> no debug ipv6 savi

2.4 IPV6 CONFIGURATION EXAMPLE
configure terminal
interface FastEthernet 0/0
ip address 220.24.2.1 255.255.255.0
ipv6 address prefix 2200::0010/64
description %%%%%%%%%%%% FastEthernet %%%%%%%%
no ip unreachables
exit
ip address 1.1.1.2 255.255.255.0
ip address 193.168.1.224 255.255.255.0 secondary
exit
ip address 2.2.2.2 255.255.255.0
exit
ip address 3.3.3.2 255.255.255.0
exit
ip address 4.4.4.2 255.255.255.0
exit
interface Loopback 100
exit
virtual-template ppp 10
authentication no
no password
magic number not-negotiable
reconnection automatic
execute
exit
interface serial 0/0
physical-layer
G703-G704-Interface
clock master
no ts 1-31
ts 1-31
exit
exit
profile 10
execute
exit
ip route 0.0.0.0 0.0.0.0 serial 0/0
ipv6 route 6200::/64 Serial 0/0
exit

3 D H C P V 6 C O N F I G U R A T I O N
For the time being, only DHCPv6 stateless autoconfiguration is available.
3.1 DHCPV6 GLOBAL CONFIGURATION
3.1.1 Enabling/Disabling DHCPv6
• To globally enable DHCPv6 stateless autoconfiguration at router level, use the following command in
global configuration mode:
CLI(configure)> ipv6 dhcp enable
• To globally disable DHCPv6 stateless auto-configuration at router level, use the following command in
CLI(configure)> ipv6 dhcp disable

3.1.2 DHCPv6 Pool Configuration
IPv6 addresses are leased to an interface for a fixed length of time. Each address has an associated
lifetime that indicates how long the address is bound to an interface. When a lifetime expires, the binding
and address become invalid and the address may be reassigned to another interface elsewhere. To
handle the expiration of address bindings gracefully, an address goes through two distinct phases while
assigned to an interface.
Initially, an address is preferred, meaning that its use in arbitrary communication is unrestricted. Later, an
address becomes deprecated in anticipation that its current interface binding will become invalid.
New communication (e.g., the opening of a new TCP connection) should use a preferred address when
possible. A deprecated address should be used only by applications that have already been using it and
would have difficulty switching to another address without a service disruption.
• To configure DHCPv6 server pool options, first enter in pool configuration mode using the following
command in global configuration mode:
CLI(configure)> [no] ipv6 dhcp pool <pool-name>
CLI(config-dhcpv6)>
To remove the DHCPv6 pool, use the no form of this command.

• To configure an IPv6 address to be distributed, use the following command in DHCP pool
configuration mode:
CLI(config-dhcpv6)> address <ipv6-addr> <client-duid>
[lifetime <valid-lifetime> <preferred-lifetime>]
With:
o <ipv6-addr>. This is the IPv6 address to be distributed.
o <client-duid>. This is the DHCP Unique Identifier of the client. This is used by a client to
get an IP address from the DHCPv6 server.
o <valid-lifetime>. This is the valid lifetime of the IPv6 address, expressed in seconds.
o <preferred-lifetime>. This is the preferred lifetime of the IPv6 address, expressed in
seconds. This time indicates how long the address keeps its preferred state, i.e., the time until
deprecation.
To stop the distribution, use the no form of the command:
CLI(config-dhcpv6)> no address <ipv6-addr> <client-duid>
• To configure the DNS Server option, use the following command in DHCP pool configuration mode:
CLI(config-dhcpv6)> dns-server <ipv6-address>
It is possible to configure more than one DNS server by repeating the command with the IPv6 address
of another DNS server.
To remove the DNS Server option, use the no form of the above-referenced command:
CLI(config-dhcpv6)> no dns-server { <ipv6-address> | all }
By entering an IPv6 address in this command, it is possible to remove this one specific DNS server.
By using the option all, all configured DNS servers will be removed from the IPv6 DHCP pool.
• To configure the Domain Name option, use the following command in DHCP pool configuration mode:
CLI(config-dhcpv6)> domain-name <name>
To remove the Domain Name option, use the no form of the above-referenced command:
CLI(config-dhcpv6)> no domain-name <name>

• To configure an IPv6 prefix to be distributed, use the following command in DHCP pool configuration
mode:
CLI(config-dhcpv6)> prefix-delegation <ipv6-prefix/prefix-length>
<client-duid> [lifetime <valid-lifetime>
<preferred-lifetime>]
With:
o <ipv6-prefix/prefix-length>. These are the IPv6 address prefix and prefix length.
o <client-duid>. This is the DHCP Unique Identifier of the client. This is used by a client to
get an IP address from the DHCPv6 server.
deprecation.
CLI(config-dhcpv6)> no prefix-delegation <ipv6-prefix/prefix-length>
<client-duid> [lifetime <valid-lifetime>
<preferred-lifetime>]
• To configure an IPv6 address range to be distributed, use the following command in DHCP pool
configuration mode:
CLI(config-dhcpv6)> range <min-ipv6-address> <max-ipv6-address>
With:
o <min-ipv6-address>. This is the start address of the IPv6 address range.
o <max-ipv6-address>. This is the end address of the IP address range.
deprecation.
CLI(config-dhcpv6)> no range <min-ipv6-address> <max-ipv6-address>
• To configure Refresh Time option, use the following command in DHCP pool configuration mode:
CLI(config-dhcpv6)> refresh-time <days> [<hours> [<minutes>]]
To indicate that the client should never refresh its options, use the following command:
CLI(config-dhcpv6)> refresh-time infinite
To return to the default value of the Refresh Time option, use the following command:
CLI(config-dhcpv6)> no refresh-time
• To configure the SIP Server option, use the following command in DHCP pool configuration mode:
CLI(config-dhcpv6)> [no] sip-server <ipv6-address>
To remove the SIP Server option, use the no form of the above-referenced command.
• To terminate the DHCPv6 pool configuration and return to the global configuration mode, use the
following command in DHCP pool configuration mode:
CLI(config-dhcpv6)> exit
CLI(configure)>

3.1.3 DHCPv6 Relay Configuration
• To validate Relay information options in RELAY-REPLY messages, use the following command in
CLI(configure)> [no] ipv6 dhcp relay information check
To return to the default behavior, use the no form of the above-referenced command.
• To define the IPv6 address of another interface than the output interface as source address for
DHCPv6 relay messages, use the following command in global configuration mode:
CLI(configure)> ipv6 dhcp relay source-interface <type> <number>
To return to the default behavior (IPv6 address of the output interface), use the following command:
CLI(configure)> no ipv6 dhcp relay source-interface
3.1.4 IPV6 Configuration Example - DHCPv6 Pool
This example shows the configuration of a DHCPv6 pool with the DNS server option configured in the pool
with a refresh time of 10 minutes.
interface GigabitEthernet 0/0

ip address 172.25.3.52 255.255.252.0
description Management Interface
exit
bridge-group 1
exit
interface Bvi 1
ip address 192.168.163.10 255.255.255.0
ipv6 nd other-config-flag
ipv6 address 33ee:d:1::10/64
ipv6 dhcp server DHCPv6server
bridge-group 1
description LAN
vrrp 1
tracking-list WAN-BGP 0 0
preempt 60
priority 110
address 192.168.163.25 255.255.255.0
exit
vrrp 2
tracking-list WAN-BGP 0 0
preempt 60
priority 110
ipv6 address fe80::5:73ff:fea0:2/128
ipv6 address 33ee:d:1::25/64
exit
exit
ipv6 dhcp pool DHCPv6server
dns-server 2a01:c916::194:2:0:20
dns-server 2a01:c916:1:0:194:2:0:50
refresh-time 1 0 0
exit
end

3.2 DHCPV6 CONFIGURATION AT INTERFACE LEVEL
3.2.1 DHCPv6 Client Configuration
Note that, on a given interface, DHCPv6 client, relay, and server are mutually exclusive. An error message
is displayed when trying to configure a different mode while another is in force.
To enable the DHCPv6 client prefix delegation through a specified interface, use the following command in
interface configuration mode.
CLI(config-if)> ipv6 dhcp client pd <prefix-name> [rapid-commit]
prefix-name is the name of the prefix learned using DHCP client prefix delegation. This prefix gives the
leading bits of the IPv6 address when using prefix delegation (see 2.2.2.6).
Use the rapid-commit option to enable the use of the two-message exchange for prefix delegation and
other configuration as described in paragraph 22.14 of RFC 3315.
To disable DHCPv6 client prefix delegation, use the no form of this command:
CLI(config-if)> no ipv6 dhcp client pd <prefix-name>
3.2.2 DHCPv6 Relay Configuration
Note that, on a given interface, DHCPv6 client, relay, and server are mutually exclusive. An error message
is displayed when trying to configure a different mode while another is in force.
3.2.2.1 DHCPv6 Relay Destination Configuration
To enable DHCPv6 relay on a given interface, and define the destination to send (relay) client messages,
received on the interface, to, use the following command in interface configuration mode:
CLI(config-if)> ipv6 dhcp relay destination <ipv6-address> [<interface>]
o <ipv6-address> must be written as described in section 2.1.1.1.

o The optional parameter <interface> (type + number) defines the output interface to be used
to reach the destination; when not used, the output interface is determined by the routing
tables (the destination must be reachable).
The command can be entered multiple times to define several destinations. When a message is received,
it is forwarded to all configured relay destinations.
To remove a relay destination, use the no form of the above-referenced command:
CLI(config-if)> no ipv6 dhcp relay destination <ipv6-address> [<intface>]
Note: when all relay destinations are removed from the interface, DHCPv6 relay is then disabled.

3.2.2.2 DHCPv6 Relay Subscriber-ID Option Configuration
To define DHCPv6 relay Subscriber-ID Option as defined in RFC 4580, use the following command in
CLI(config-if)> ipv6 dhcp relay information option subscriber-id <string>
This command requires DHCPv6 relay to be enabled on the interface to be taken into account.
To remove the subscriber-ID option, use the no form of the above-referenced command:
CLI(config-if)> no ipv6 dhcp relay information option subscriber-id
3.2.2.3 DHCPv6 Relay Source Interface Configuration
By default, the source address used for relay messages is the IP address of the output interface.
To define another source interface whose IP address is taken as source address for DHCPv6 relay
messages, use the following command in interface configuration mode:
CLI(config-if)> ipv6 dhcp relay information source-interface <interface>
This command requires DHCPv6 relay to be enabled on the interface to be taken into account.
To remove the configured source address and return to the default output interface address, use the no
form of the above-referenced command:
CLI(config-if)> no ipv6 dhcp relay information source-interface
3.2.3 DHCPv6 Server Configuration
Note: on a given interface, DHCPv6 client, relay, and server are mutually exclusive. An error message is
displayed when trying to configure a different mode while another is in force.
To enable the DHCPv6 server on a given interface, use the following command in interface configuration
mode:
CLI(config-if)> [no] ipv6 dhcp server <pool-name> [preference <0-255>]
o pool-name is the name of the address pool defined in global configuration mode.
o preference allows defining the preference option value in the advertise message sent by the
server. Default value is 0.
To disable DHCPv6 server, use the no form of the above-referenced command:

3.3 DHCPV6 STATISTICS
Use the following command to show DHCPv6 binding information:

CLI> show ipv6 dhcp binding [vrf <vrf-name>]
Use the following command to show DHCPv6 information for a specific BVI interface:
CLI> show ipv6 dhcp interface bvi <1-255>
Use the following command to show DHCPv6 information for a specific fast Ethernet interface:
CLI> show ipv6 dhcp interface fastethernet <unit>
Use the following command to show DHCPv6 information for a specific Gigabit Ethernet interface:
CLI> show ipv6 dhcp interface gigabitethernet <unit>
Use the following command to show DHCPv6 information for a specific Virtual-Ethernet interface:
CLI> show ipv6 dhcp interface virtual-ethernet <1-255>
Use the following command to show DHCPv6 statistics:

CLI> show ipv6 dhcp statistics [vrf <vrf-name>]
Use the following command to clear the DHCPv6 binding database:

CLI> clear ipv6 dhcp binding [vrf <vrf-name>]
Use the following command to clear the DHCPv6 statistics:

CLI> clear ipv6 dhcp statistics [vrf <vrf-name>]
Example 1
The following example shows a result of running the show ipv6 dhcp interface bvi command:
CLI> show ipv6 dhcp interface bvi 1
Bvi 1 is in server mode
Using pool: DHCPv6server
Preference: 0
Rapid-Commit is disabled

Example 2
The following example shows the output of some show commands, in a DHCPv6 client-server setup on
OneOS devices.
DHCPv6 server:
CLI> show ipv6 dhcp statistics vrf VPN1
DHCPv6 statistics:
Server: IN: info-req 0
solicit 3
Request 2
Renew 0
Rebind 0
Release 0
Decline 0
Confirm 0
OUT: Advertise 3
Reply 2
Memory: 2645 bytes
Client: IN: advertise 0

reply 0
OUT: info-req 0
solicit 0
request 0
renew 0
rebind 0
release 0
Memory: 0 bytes
Relay: IN: rely-forw 0

rely-repl 0
OUT: rely-forw 0
rely-repl 0
Memory: 0
Errors: unicast 0
internal 0
interface 0
packet fields 0
packet length 0
packet option 0
packet type 0
CLI>
CLI> show ipv6 dhcp binding vrf VPN1

DUID : 000300010012efe15400
IAPD : IA ID 22273, T1 1296000, T2 2073600
Prefix 33ee:abcd:abcd:1::/64
prefered lifetime 604800, valid lifetime 2592000
CLI> show ipv6 dhcp interface gigabitethernet 1/0.1

GigabitEthernet 1/0.1 is in server mode
Using pool: RelayforM03
Preference: 0
Rapid-Commit is disabled
oab-step-M03-primary-CO>

DHCP client:
CLI> show ipv6 dhcp interface gigabitethernet 1/0.1
GigabitEthernet 1/0.1 is in client mode
Prefix Prefix_VRF1, state is active
Delegating server address: 33ee:aaaa:aaaa:aa08::2
DUID: 00:03:00:01:00:12:ef:e1:81:4b
Preference: 0
Options:
IA PD: 22273, T1 302400 s, T2 483840 s
Prefix : 33ee:abcd:abcd:1::/64
pltime 604800 s, vltime 2592000 s
Dns server: bbbb::1
Domain name: oneaccess.org
Prefix Rapid-Commit disabled
CLI> show ipv6 dhcp statistics vrf VPN1

DHCPv6 statistics:
Server: IN: info-req 0
solicit 0
Request 0
Renew 0
Rebind 0
Release 0
Decline 0
Confirm 0
OUT: Advertise 0
Reply 0
Memory: 0 bytes
Client: IN: advertise 1

reply 1
OUT: info-req 0
solicit 2
request 1
renew 0
rebind 0
release 0
Memory: 736 bytes
Relay: IN: rely-forw 0

rely-repl 0
OUT: rely-forw 0
rely-repl 0
Memory: 0
Errors: unicast 0
internal 7
interface 0
packet fields 0
packet length 0
packet option 0
packet type 0

3.4 IPV6 CONFIGURATION EXAMPLE - IPV6 PREFIX DELEGATION AS

REQUESTING ROUTER
In this example, the WAN interface of the OnesOS device is the DHCPv6 client, and gets an IPv6 prefix
from a delegating router.
• WAN interface:
CLI(configure)> interface gigabitethernet 1/0
CLI(config-if)> ipv6 address autoconfig default
CLI(config-if)> ipv6 dhcp client pd prefix-delegation-from-isp
CLI(config-if)> exit
CLI(configure)>
• LAN interface:
o The delegated prefix for example is: 2002:fafa::/64.
o The IP address of the LAN interface is 2002:fafa::1/64.
o LAN clients will get IP addresses in this range.
CLI(configure)> interface GigabitEthernet 0/0

CLI(config-if)> ipv6 address prefix-name
prefix-delegation-from-isp ::1/64
CLI(configure)>

4 I P V 6 A C C E S S L I S T S
This section describes the features of IPv6 Access Control Lists (ACL) and their configuration.
4.1 ACL FEATURES (IPV6)
4.1.1 Access List Filters
IPv6 access lists are comparable with extended IPv4 access lists. They can filter packets using any
combination of the following IP and transport protocol header fields: IP source and destination addresses,
DSCP code, IP protocol identifier, TCP/UDP source and destination port numbers/port range, as well as
ICMP type and code.
4.1.2 ICMP Unreachable
When a packet is dropped by an access list, an ICMP unreachable message can be sent according to a
configuration parameter.
4.1.3 Context Based Access Control
This control mode enables also full TCP packet inspection, namely detection of TCP SYN packets initiating
the connection, RST or FIN packets ending the connection. TCP packet inspection also protects from TCP
sequencing replay.
Such control also limits the configured maximum number of sessions and TCP half-sessions on the router.
(A half session is a session for which only a SYN packet was intercepted and the router waits for a
SYN_ACK packet). When the limits are reached, packets are dropped.
4.1.4 Logging and Statistics
Access lists provide log information for matching packets, either denied or permitted. Information can be
displayed either on the console, or logged to a file. Upon the first match of a filter, a log message will be
issued. Then upon succeeding matches, a summary log message is periodically issued. The level of
logging detail can be configured.

4.2 ACL CONFIGURATION COMMANDS (IPV6)
To create an IPv6 access list, use the following command in global configuration mode:
CLI(configure)> ipv6 access-list <acl-name>
CLI(config-ipv6-acl)>
To add comments (remark) in an access-list, use the following command in access-list configuration mode:
CLI(config-ipv6-acl)> remark <string 1-100 characters>
Only one remark is allowed. It is placed at the end of the access-list configuration. Use the following
command to remove the remark:
CLI(config-ipv6-acl)> no remark
The default summary log message period for IPv6 access-list logging is 512 occurrences of succeeding
matches. Use the following command to modify the logging interval:
CLI(config-ipv6-acl)> log-update <occurences>
Use the following command to return to the default period:

CLI(config-ipv6-acl)> no log-update
Then, ACL rules can be defined to permit or deny traffic.
4.2.1 Rules Matching IPv6 Addresses
The syntax to create a permit/deny rule working only at the IP layer is:
CLI(config-ipv6-acl)> [no] permit ip <src-ipv6-prefix> <dest-ipv6-prefix>
[dscp <0..63>] [log] [sequence <seq>]
CLI(config-ipv6-acl)> [no] deny ip <src-ipv6-prefix> <dest-ipv6-prefix>
To delete a rule, use the no form of the above command. The first part of the rule is related to the source
address of the packet, whereby the source IPv6 address must be either any address, or exactly a given IP
address or matching an IPv6 prefix. The second part is respectively related to the destination IPv6
address. A log message will be created when the rule is matched if the log parameter is added. The
sequence argument allows the insertion of a rule at a specific location. IPv6 ACL re-sequencing is not
supported at the moment.
Remarks:
• The IPv6 prefix to match any IPv6 address is: ::/0.
• The IPv6 prefix to match a host address is <host>/128. For example: 2002::31/128
Examples:
deny ip ::/0 2007::1234/64 dscp 8 log sequence 60
deny ip 2002::3456/128 2002::1234/64 dscp 5
4.2.2 Rules Matching IPv6 Addresses + IP Protocol
CLI(config-ipv6-acl)> [no] permit ip <protocol-nbr>
<src-ipv6-prefix> <dest-ipv6-prefix>

CLI(config-ipv6-acl)> [no] deny ip <protocol-nbr>

Examples:
deny ip 10 2005::2345/120 2002::4456/128
deny ip 33 2006::2345/120 2002::4456/123 dscp 10
deny ip 254 2007::2345/120 2003::4456/128 dscp 11 log
deny ip 150 2008::2345/120 2002::4456/128 dscp 12 sequence 10
deny ip 0 2009::2345/120 2003::4456/128 dscp 13 log sequence 12
deny ip 13 2056::2345/120 2022::3456/55
deny ip 70 2056::2345/120 2023::3456/55 dscp 10
deny ip 230 2057::2345/120 2024::3456/55 dscp 20 log
deny ip 250 2058::2345/120 2025::3456/55 dscp 30 sequence 20
deny ip 17 2059::2345/120 2025::3456/55 dscp 40 log sequence 22
4.2.3 Rules Matching IPv6 Addresses + TCP/UDP
The syntax to create a permit/deny rule working only at the TCP/UDP layer is:
CLI(config-ipv6-acl)> [no] permit { tcp | udp }
<src-ipv6-prefix> [<src-port> [<src-port-end>]]
[<dest-ipv6-prefix> [<src-port> [<src-port-end>]]]
CLI(config-ipv6-acl)> [no] deny { tcp | udp }

<src-ipv6-prefix> [<src-port> [<src-port-end>]]
[<dest-ipv6-prefix> [<src-port> [<src-port-end>]]]
Examples:
deny tcp ::/0 2002::3456/128 dscp 5
deny tcp ::/0 2004::3456/128 100 60400 dscp 5
deny tcp 2003::3458/128 100 any dscp 7 sequence 15
deny tcp 2042::3456/128 335 2048::1234/128 100 60600 dscp 5
deny tcp 2004::1234/64 ::/0 dscp 5
4.2.4 Rules Matching IPv6 Addresses + ICMP
CLI(config-ipv6-acl)> [no] permit icmp
[<icmp-type> [<icmp-code>]]
CLI(config-ipv6-acl)> [no] deny icmp

[<icmp-type> [<icmp-code>]]
Examples:
deny icmp ::/0 ::/0 6 dscp 15
deny icmp ::/0 ::/0 255 10 dscp 25
deny icmp ::/0 2004::3456/128 100 60 dscp 5
4.2.5 Terminating IPv6 ACL configuration
To terminate the IPv6 ACL configuration and return in global configuration mode, use the following
command in IPv6 ACL configuration mode:
CLI(config-ipv6-acl)> exit
CLI(configure>

4.2.6 Attaching Detaching an ACL on an Interface
To attach the access list on an interface, apply the following command under interface configuration mode:
CLI(config-if)> ipv6 access-group <ipv6-acl-name> { in | out }
To detach the ACL:

CLI(config-if)> no ipv6 access-group {in | out}
4.2.7 Stateful Inspection
• By default, stateful inspection is not enabled. Stateful inspection means that the TCP flags are
checked to validate TCP protocol transaction validity. To activate this inspection, use the following
command:
CLI(configure)> ipv6 inspect stateful
To deactivate, use the no form of the command:

CLI(configure)> no ipv6 inspect stateful
• When a SYN packet is received, a session is created for this communication. The default value for
waiting for a response to this SYN is 30 seconds. If this time is elapsed, the associated session is
freed.
To change the TCP SYN-wait timeout, use the following command:
CLI(configure)> ipv6 inspect tcp synwait-time <seconds>
• Use the following command to restore the default value for the TCP SYN-wait timeout:
CLI(configure)> default ipv6 inspect tcp synwait-time
• When a FIN or RST packet is received, a timeout timer is started to give a chance to the packets from
the other side to find the valid session. The default value for waiting for a response to these FIN or
RST packets is 120 seconds. If this time is elapsed without receiving any packet from other side, the
associated session is freed.
It is possible to change the TCP FIN/RST-wait timeout with the following command:
CLI(configure)> ipv6 inspect tcp finrst-time <seconds>
Note that if other no-FIN packets are received from the side that sent the FIN packet, they will be
dropped as they are not valid.
Use the following command to restore the default value for the TCP FIN/RST-wait timeout:
CLI(configure)> default ipv6 inspect tcp finrst-time

4.2.8 Changing the Idle-Timers
When the TCP 3-way handshake is done, the session is fully opened.
When this is the case and there is no activity for this session, the idle timer starts counting.
The default value of this timer is 1800 seconds.
When this time is elapsed without any valid packets exchanged, the associated session is freed.
It is possible to change the TCP Idle Timeout with the following command:
CLI(configure)> default ipv6 inspect tcp idle-time <seconds>
Use the following command to restore the default value for the TCP Idle Timeout:
CLI(configure)> default ipv6 inspect tcp idle-time
4.3 ACL STATISTICS (IPV6)
To view ACL statistics, use the following command:

CLI> show ipv6 access-list [<acl-name >]
To clear access lists counters, use the following command:

CLI> clear ipv6 access-lists [<acl-name>]
To view a list of all the TCP sessions that are currently opened, use the following command:
CLI> show ipv6 inspect stateful sessions
The following information is shown:

o Input address / port
o Output address / port
o Remaining time for timeout
o The current state of session
To view stateful inspection statistics, use the following command:
CLI> show ipv6 inspect stateful statistics
The following statistics are shown:

o Total active sessions
o Total closed sessions
o Total failed sessions
o Total permitted packets
o Total dropped packets
Use the following command to clear ACLv6 stateful statistics:
CLI> clear ipv6 inspect stateful statistics

4.4 ACL DEBUG (IPV6)
To debug access lists, use the following command:

CLI> debug ipv6 access-list
To disable this debugging, use the no form of the command:

CLI> no debug ipv6 access-list
To enable debugging of stateful inspection, use the following command:

CLI> debug ipv6 inspect stateful
To disable this debugging, use the no form of the command:

CLI> no debug ipv6 inspect stateful
Alternatively, to disable the debugging, use the global no debug command.

5 I P S E C U R I T Y ( I P S E C )
• This section explains how to configure IPsec tunnels on the OneOS device.
• IPsec tunnels can be configured in 3 ways:
o A crypto map can be applied on a physical interface; this is available for IKEv1 only.
o By means of Easy VPN; this is available for IKEv1 only
o An IPsec profile can be applied on a tunnel interface; this is available for IKEv1 and IKEv2.
• The preferred way is to make use of IPsec profiles, since the IPsec performance is significantly better
compared to when using crypto maps.
• IPsec is VRF aware.
5.1 FRAGMENTATION AND TUNNELS - CAVEATS
• Keep the explanation in this section in mind when configuring tunnels.

• Also refer to 5.11 Fragmentation and IPsec - Recommended Settings, this section gives some
recommendations with regard to fragmentation and IPsec.
Introducing Fragmentation
• When a packet is to be sent out an interface, the MTU of this interface is checked to see if the packet
needs to be fragmented or not. If the MTU is exceeded, fragmentation is normally initiated.
In IPv4, fragmentation only proceeds if the DF-bit in the TOS field is not set. If it is, an ICMP – Too Big
message is sent back to the sender.
In IPv6, fragmentation is never done by an intermediate router.
• In case of tunnel interfaces, a packet effectively passes multiple MTU checks:
The first one on the tunnel interface, and after encapsulation, again on the physical interface.
This could lead to double fragmentation: depending on the MTU settings on the tunnel interface and
physical interface, it is possible that a single packet is fragmented into two fragments after the tunnel
interface, which each get fragmented again to a total of 4 fragments.

Preventing Double Fragmentation
• Double fragmentation is almost never the desired behavior. One can solve the double fragmentation
problem by forcing fragmentation to take place at one place, by carefully configuring the MTUs of the
different interfaces involved or by bypassing the MTU check on the tunnel interface entirely.
• In general, 2 main options are available, both have their advantages and drawbacks:
o Pre-fragmentation, i.e. packets are fragmented before the tunnel encapsulation is added.
 Pre-fragmentation is configured by configuring a low enough MTU on the tunnel
interface that allows enough room for the tunnel encapsulation.
 Advantage: reassembly is done by the endpoint of the tunneled packet; there is no
reassembly overhead on the tunnel endpoint.
 Disadvantage: the lower MTU is visible to the end points; variable encapsulation
overhead of IPSec requires automatic MTU detection mechanisms.
o Post-fragmentation, i.e. packets are fragmented after the tunnel encapsulation is added.
 Post-fragmentation is achieved either by configuring a large MTU on the tunnel
interface, at least equal to the expected maximum MTU size of the service offered, or ,
for IPsec tunnels, by configuring fragmentation-after-encryption;
refer to 5.11.3 Configuration Commands.
 Advantage: transparent to the end user.
 Disadvantage: reassembly increases the CPU load on the tunnel endpoint.

5.2 INTRODUCING IPSEC PROTECTED TUNNEL
5.2.1 Introduction
• IP Security or IPsec is a suite of IP protocols that permit IP flows to be encrypted and/or

authenticated.
• For example, to transport information securely from one sub-network A to another sub-network B by
using an untrusted network, for example, the internet, IPsec provides some guarantees about several
security levels for delivering packets from A to B and vice-versa. This is illustrated in the following
figure:
The packets exchanged between sub-networks A and B are transported in an IPsec tunnel.
Transport Mode and Tunnel Mode
IPsec is actually broken down in two flavors: transport mode and tunnel mode.
• The transport mode is usually applied when the IPsec session is terminated directly in the hosts.
In this case, the IP header is not modified, only the payload changes.
• When using the tunnel mode, a new IP header is added which corresponds to the source and
desti¬nation addresses of the IPsec gateways as shown in the figure above.
When no authentication and encryption is applied, an IPsec tunnel is quite similar to a GRE tunnel.

• The following figure illustrates both modes when using an Authentication Header (AH).
IP Security
IP security protocols are based on cryptographic algorithms. The keying material between two hosts
pro¬vides several properties:
• Integrity of the packet: if modified, the packet is recognized as such and is then dropped.
For example, a malicious user cannot change the source IP address of the packet so as to speak on
behalf of the real emitter.
• Authenticity: it is guaranteed that the packet comes from host X, because the packet has not been
altered and the encryption could only be performed by means of secret keying material.
• Confidentiality: the packet can be fully encrypted; therefore it cannot be read by any third party that
has no prior knowledge of the keying material.
• Security: the security protocols protect against certain attacks such as unauthorized insertion of
frames.

IPsec Encapsulations
• There are two types of IPsec encapsulations:

o The Authentication Header (AH) provides authenticity by using one of the two following
hashing algorithms: HMAC-SHA1 or HMAC-MD5 (RFC 2104). Refer to diagram above for the
AH packet structure.
o The Encapsulation Security Payload (ESP) provides encryption and optional authentication
using the following protocol algorithms: for encryption NULL (no encryption), DES (64 bits),
3DES (92 bits) or AES (128, 192 or 256 bits), and for authentication HMAC-SHA1 (80 bits),
HMAC-MD5 (64 bits) or no authentication.
An ESP packet has the following structure:
• Optional compression is provided when using authentication and/or encryption. The compression is
applied on outbound packets (IP header + payload), and is then authenticated and/or encrypted.
The resulting compressed data requires less CPU power for encryption.
Furthermore, it limits the overhead due to the encapsulation (20 bytes for an IPv4 packet) plus IPsec
overhead (12 bytes for AH, variable-size for an ESP packet with padding).
Transform Set
• The encapsulation type of an IP packet in one of the IPsec modes is a transform set.
• A transform set is a certain combination of security protocols and algorithms.
During the IPsec security association (SA) negotiation, the peers agree to use a particular transform
set for protecting a particular data flow.
• Multiple transform sets can be specified, and then one or more of these transform sets can be
specified in a crypto map entry. The transform set defined in the crypto map entry is used in the IPSec
SA negotiation to protect the data flows specified by that crypto map.
• During IPsec security association (SA) negotiations with IKE, the peers search for a transform set that
is the same at both peers. When such a transform set is found, it is selected and is applied to the
protected traffic as part of both peers’ IPsec SAs.
With manually established SAs, there is no negotiation with the peer, so both sides must specify the
same transform set.
• If you change a transform set definition, the change is only applied to crypto map entries that
reference the transform set. The change is not applied to existing security associations, but is used in
subsequent negotiations to establish new SAs. If you want the new settings to take effect sooner, you
can clear all or part of the SA database by using the clear crypto sa command.

Security Protocol Index (SPI)
• To enable peer IPsec gateways to understand each other, both instances of the IPsec protocol
contain a Security Protocol Index (SPI), that is added to the protocol type (AH or ESP) and the IP
destination.
SPI and source address uniquely identify a Security Association (SA).
• As a tunnel is bi-directional, two SAs are required, one for each direction.
Security Policy Database (SPD)
• IPsec not only defines how the traffic is secured, but also which traffic should be encrypted. This is
managed by the Security Policy Database (SPD): this is a table with several entries.
• The SPD is a table whose entries provide a set of selectors and associated actions.
A selector is a filtering criterion that determines the action to apply on a packet; it can be forwarded,
dropped, or processed with specified IPsec SA parameters.
For example, when using crypto maps, all inbound traffic passes through a crypto map. If a packet is
not encrypted and if it matches a SPD entry, then the packet is dropped. If the packet is not encrypted
and does not match an SPD entry, it is forwarded.
Keys
• IPsec protocols are highly robust but this robustness is as good as the secrecy of the keying material.
Obviously, poor management of the keying material weakens many robust cryptographic techniques.
Some solutions to increase the robustness of the security associations are:
o Decreasing the lifetime of a security association by renewing the keys quite often. Since the
keys are refreshed, a hacker has to compute and break keys much more often. Therefore, it
makes it harder for a pirate to eavesdrop. For example, 1200 seconds is reasonable for a
simple DES transform.
o Using strong keying material; some key generators are weak and keys are thus easier to
break.
o Using advanced transforms. For example, 3DES is stronger than DES, because the key length
is three times longer than the DES transform. AES is also stronger than 3DES, due to the
encryption method.
o Using proprietary transforms. Unlike the DES family or AES, some transforms are not known
by the public. Hence it is harder to break keys without prior knowledge of the technique used.

5.2.2 Internet Security Association and Key Management Protocol (ISAKMP)
As the renewal of keys must be synchronized at both end points of the IPsec tunnel, a framework called
ISAKMP or Internet Security Association and Key Management Protocol is implemented.
ISAKMP provides the following services:
Internet Key Exchange (IKE) - IKE phase 1
• IKE permits to dynamically negotiate an IPsec SA between two IPsec peers. Before negotiating the
SA, a secure data channel must be established between the peers. Once this secure channel is
established, the peers can faster and more efficiently negotiate the setup of the IPsec SA, as the
exchanged information is already secured.
• Therefore, this channel is a management channel. The channel is called an ISAKMP Security
Association (SA) - which can be rather confusing -; this special SA should not be mixed up with the
conventional IPsec SA.
• This part is also referred to as IKE phase 1. During this phase, the authentication data permits the
validation and completion of the IKE SA establishment.
• The keys for IKE SA authentication are retrieved through an external mechanism, independent of the
IKE protocol .
• During IKE phase 1, the peers exchange:
o ISAKMP SA parameter offer.
o Keying material.
o Identification and authentication data.
o Negotiation of security attributes: ISAKMP sends to the remote peer which traffic should be
selected, and how it should be encrypted.
IPsec SA Negotiation - this part is also referred to as IKE phase 2.
• As an IKE SA was created in phase 1, a secure communication path exists between the two IPsec
peers. This second phase enables the creation of an IPsec SA, which creates a secure
communication tunnel for user traffic.
• IKE will create the SA by exchanging the SA parameters stored in the Security Policy Database (SPD)
and generate the keys. The keys are automatically generated by IKE for each SA using Oakley key
determination protocol (RFC 2412). Here, the user can select the aggressive mode (1.5 round trips
taking less time to establish) or the main mode (3 round trips; more robust towards attacks).
• As the encryption keys are relatively short (56 bits for DES), it does not take long for a computer to
crack a key. Therefore, the keys need to be refreshed quite often.
• The Oakley quick mode is used for key refreshing, and the refresh timer can be adjusted (short key
refreshed quite often – less computation – or longer/more robust key refreshed after longer intervals).
• Once the IPsec SA is created, it is registered in the Security Association Database. The IPsec SA
exists as long as there is user traffic for that SA. If no user traffic transits through that SA during a
configured inactivity period, it is destroyed.

5.2.3 P re -s h a r e d k e ys a n d D i g i ta l c e r ti f i c a te s
• Pre-shared keys are the simplest way to authenticate during IKE phase 1. In this method both the
initiator and responder must have the same pre-shared keys. The keys are agreed upon in advance
using an out-of-band technique.
One disadvantage of this method is that the distribution of the secret to the peers must occur in a
secured way, or is based on trust.
Another disadvantage is that in IKE main mode, because the ID payloads are encrypted, the
responder is not aware of the identity of the initiator. In remote access scenarios such as telecom-
muting, the source IP address of the initiator is not known in advance to the responder. In such cases,
aggressive mode is the only choice with pre-shared key authentication.
• Digital certificates are supported as an alternative method to authenticate peers. Each peer has a
private key and corresponding public key.
The private key is used for encryption purposes of the information to send.
The public key is put in a certificate along with the peer’s ID. The certificate is signed (digital
signature) by a Certificate Authority (CA).
Each peer sends its certificate to the other peer during IKE phase 1. On reception of the certificate
each peer first authenticates the certificate by re-calculating its digital signature using the CA public
key which is in the root certificate. If a digital signature match is found, the router can trust its peer,
based on its trust in the Certificate Authority.
Next the hash values exchanged during IKE phase 1 are signed by the private keys of each peer. The
recipients of the signature will use the signer’s public key to decrypt and verify the message.
• The set-up of an IP VPN network with digital certificates is based on a public key infrastructure.
Each router needs a private and public key pair and a corresponding digital certificate. The digital
certificate (self-certificate) is stored on the router, typically on the file system.
To generate the certificate, the contents are prepared and sent to the CA in a pre-defined format. The
most widely used format for digital certificates is X.509, which is supported by OneOS.
The CA signs it (i.e. add a digital signature of the certificate contents using the CA private key) and
returns the signed certificate to the requester, who then stores it on the router.
The Certificate Authority can be a company specialized in delivering this service (e.g. VeriSign).
Alter¬natively, the organization that owns the routers can set-up its own Certificate Authority. The
latter is worth considering if it concerns a large network with many routers and according certificates.
• Each OneOS based router may have a single certificate for IPsec VPN. In addition, the router must
also store the CA root certificate for authenticating the peer’s certificate. Note that each certificate has
also a validity period, which is checked. The validity period of a certificate is typically 20 years.
• A trust-point encapsulates the certificate revocation check rules, used by an ISAKMP profile. It is used
to verify the validity of the certificate used to set up a secure connection. When an ISAKMP profile is
configured to use a trust-point (referenced via its name string) during the setup of an SA, it will use the
revocation-checks configured for that trust-point.

5.2.4 IPsec encapsulated GRE and L2TP tunnels
• Designing a VPN using IPsec for connectivity between peers has some inherent limitations; these are:
o IPsec can only encrypt/decrypt IP traffic.
o IP traffic destined to a multicast or broadcast IP address cannot be handled by IPsec, which
means they cannot traverse the IPsec tunnel. Broadcast and multicast packets are typically
used by routing protocols.
• IPsec encapsulated GRE or IPsec encapsulated L2TP tunnels (RFC 3193) provide a solution. Like
native IPsec, they can be set-up in transport and tunnel mode.
Unlike native IPsec tunnels, IPsec encapsulated GRE and L2TP tunnels are almost always used in
IPsec transport mode as GRE or L2TP already provide a new IP header on the payload. This is the
supported mode in OneOS.
The following figures respectively show a packet for GRE over IPsec and L2TP over IPsec.
5.2.5 NAT Traversal
• Because of the integrity check performed by IPsec, IPsec packets may not be modified, by no means.
If a Network Address Translator (NAT) is found along the IPsec packet path, the packets are not valid
anymore.
• To allow IPsec packets to go through NAT, the NAT-Traversal (NAT-T) feature is needed. NAT-T is by
default active in IKEv1 and mandatory in IKEv2. NAT-T consists of two functions:
o NAT discovery: during the IKE peering session establishment, the endpoints try to determine
whether their remote peer supports NAT-T. The NAT will be detected by comparing hashes of
the sent NAT discovery payloads. If NAT is detected, NAT-Traversal must be enabled.
o NAT-transparent encapsulation: once the NAT is discovered and the peers agreed to use NAT-
T, the IPsec packets are not directly encapsulated in an IP tunnel packet but rather within an
UDP packet. Such encapsulation enables to pass several tunnels using a single public IP
address.

5.2.6 I Ps e c P ro c e s s i n g Pa th a n d c h o i c e b e tw e en c r yp t o m a p s a n d t u n n e l
protection profiles
The IPSEC processing path is different depending on the method of configuring the IPsec protected
tunnel, as described in 5.4 3 Ways of configuring an IPsec protected tunnel.
In case of crypto maps
• IPsec crypto maps can be applied in two ways:

o On a general interface. It means in egress direction that the traffic on this interface is checked
against an access-list. Traffic matching the access-list is put in the IPsec tunnel, while traffic
not matching the access-list is forwarded unchanged. The SPD is built based on the access-
list.
In ingress direction, the traffic received in the IPsec tunnel and matching the SPD is decrypted
and decapsulated and then routed.
o On a tunnel interface. In such case all traffic routed to the tunnel interface is checked against
an access-list. Traffic matching the access-list is put in the IPsec tunnel, while traffic not
matching the access-list is forwarded unencrypted on the tunnel interface. The SPD is built
based on the access-list.
In ingress direction, the traffic received in the IPsec tunnel and matching the SPD is decrypted
and decapsulated and then routed.
It means on a tunnel interface, IPsec can be combined with a GRE or L2TP tunnel.
• IPsec is applied, if enabled, at the following stages of the IP processing path:
o Outbound: after NAT processing, i.e. the source IP address of tunneled packets is the IP
address of the output interface.
o Inbound: before NAT processing.
• As a result, if you enabled NAT overload on an interface where a crypto map is enabled, IPsec may
not function properly.
The reason is: when a packet is routed to the interface, it is first NAT-ted. Then the packet passes
through the IPsec policy. Because the packet was NAT-ted, it may not match the IPsec policy any
more.
Two solutions are possible: the first solution is to configure NAT overload for packets not matching the
IPsec policy (selective NAT overload: packets are filtered through an ACL; if they match, then packets
are NAT-ted).
The second solution is to detach the crypto map from the interface and to configure a tunnel interface.
The second solution requires that the IPsec peer supports NAT-Traversal.
In the case of using tunnel interfaces, the second method (see below) is recommended
In case of protection profiles
• Explicit tunnels using protection profiles are a more elegant way to handle IPSEC encapsulation than
crypto maps, since they clearly separate the inner-packet processing steps from the outer-packet
processing steps.
• Dealing with NAT on a physical interface has no impact on the inner-steps that can be configured in
the tunnel interface. The state of the tunnel interface is also coupled with whether or not IPsec has
been successfully configured, leading to easily-configurable back-up mechanisms.
Also, since the tunnel destination may be routed over any physical interfaces, multiple uplink inter-
faces may serve the same single IPSEC tunnel.
5.2.7 IP QoS and IPsec
• To allow appropriate output QoS processing, the payload packet TOS byte can be copied in the tunnel
header. This copy enables the TOS marking at the input of the router, and the output traffic can be
classified based on the TOS/DSCP/precedence fields.

5.3 HARDWARE-ACCELERATED IPSEC
• Enabling the hardware accelerator significantly improves the IPsec performance of an OneOS device.
• To enable hardware-accelerated encryption, use the following command in configuration mode:

CLI(configure)> crypto engine enable
To disable hardware-accelerated encryption, use the following command in configuration mode:

CLI(configure)> crypto engine disable
By default, the hardware-accelerated encryption is disabled.

5.4 3 WAYS OF CONFIGURING AN IPSEC PROTECTED TUNNEL
Preliminary notes:
• IPsec profiles have been introduced as of OneOS v5.2R2. Crypto maps exist since IPsec is
supported.
• The IPsec performance significantly improves when using IPsec profiles to configure IPsec tunnels.
Therefore, the use of IPsec profiles, instead of crypto maps, is strongly recommended
There are 3 different ways to configure an IPsec protected tunnel:

• By applying a crypto map on a physical interface.
o This is available for IKEv1 only.
o Refer to ...
 5.5 IPsec Configuration making use of Crypto Maps (IKEv1)
 5.8 Configuring IKEv1 (ISAKMP)
... for further details.
• By means of Easy VPN.

o This is available for IKEv1 only.
o Refer to …
 5.5.3.4 Easy VPN Crypto Maps
 5.6 Easy VPN Configuration.
• By applying an IPsec profile on a tunnel interface.

o This is available for IKEv1 and IKEv2.
o Refer to ...
 5.7 IPsec Configuration by means of an IPsec Profile (IKEv1 and IKEv2)
 5.8 Configuring IKEv1 (ISAKMP)
 5.9 Configuring IKEv2
... for further details.
Note that an IPsec profile is also referred to as a tunnel protection profile, or just protection profile.

5.5 IPSEC CONFIGURATION MAKING USE OF CRYPTO MAPS (IKEV1)
Note that the IPsec performance has significantly improved when using IPsec profiles to configure the
IPsec tunnels; this is however not the case when using crypto maps.
Therefore, the use of IPsec profiles, instead of crypto maps, is strongly recommended.
5.5.1 Configuration Steps
The configuration steps are:

• 1. Define one or more IPsec transform set(s): transform sets are templates where you define a type of
packet processing for encryption and authentication. The transform set is applied later on one or more
interfaces.
• 2. Choose how the IPsec SA’s (Crypto Maps) are managed:
o Using manual crypto maps.
o Using standard ISAKMP crypto maps.
o Using dynamic ISAKMP crypto maps; standard ISAKMP SAs are (nevertheless) established
dynamically when a packet must be sent by one of the tunnel peers; that peer being the
initiator of the ISAKMP communication. However, there are some cases where the remote peer
does not have a predefined IP address (for example, nomad users). Dynamic ISAKMP crypto
maps solve this issue: a server responds to ISAKMP clients. Only the target IP address of
received packets is checked.
o Using Easy VPN crypto maps.

5.5.2 Configuring IPsec Transforms
• An IPsec Transform defines how an IP packet should be secured; it defines the IPsec encapsulation
used: AH or ESP. It contains information on the algorithm(s) used within the transform.
• To create an IPsec transform and enter in IPsec Transform configuration mode, use the following
CLI(configure)> crypto ipsec transform-set <name>
CLI(crypto-trans)>
o Enter a <name> for the IPsec transform.

To remove an IPsec transform, use the no form of the command:
CLI(configure)> no crypto ipsec transform-set <name>
• To configure AH encapsulation, use the following commands in transform configuration mode:

CLI(crypto-trans)> ah-sha-hmac
CLI(crypto-trans)> ah-md5-hmac
AH encapsulation supports HMAC-SHA1 and HMAC-MD5 algorithms.
• To configure ESP encapsulation, use the following command in transform configuration mode:
CLI(crypto-trans)> esp-des [esp-sha-hmac | esp-md5-hmac]
CLI(crypto-trans)> esp-3des [esp-sha-hmac | esp-md5-hmac]
CLI(crypto-trans)> esp-aes [esp-sha-hmac | esp-md5-hmac]
CLI(crypto-trans)> esp-aes-192 [esp-sha-hmac|esp-md5-hmac]
CLI(crypto-trans)> esp-aes-256 [esp-sha-hmac|esp-md5-hmac]
ESP encapsulation supports the NULL, DES, 3DES, AES-192 and AES-256 algorithms for encryp-
tion. HMAC-SHA1 and HMAC-MD5 authentication algorithms are optional.
If ESP is used, it is strongly advised to use AES with a 256-bit key, since long keys almost have no
impact on performance and guarantee a higher level of security.
NULL encryption is supported but authentication is then compulsory.
CLI(crypto-trans)> esp-null { esp-sha-hmac | esp-md5-hmac}
• To change the mode associated with the transform set, use the following command:
CLI(crypto-trans)> mode { transport | tunnel }
o transport. Transport mode adds an IPsec header to the packet.

o tunnel. Tunnel mode adds a new IP header and an IPsec header to the packet; this is the
default setting.

5.5.3 C o n fi g u r i n g a C r yp t o M a p
• A crypto map is a set of IPsec properties applied to an interface. It corresponds to the Security Policy
Database configuration.
• A crypto map has several entries, each one standing for a security policy entry and associates
o the IP traffic to secure,
o the Transform used and,
o the remote tunnel end-point.
• To configure IKEv1, refer to 5.8 Configuring IKEv1 (ISAKMP).
5.5.3.1 Manual Crypto Map Entries
• To configure a manual crypto map entry named name, and enter in crypto map configuration mode,
use the following command:
CLI(configure)> crypto map ipsec-manual <name> <sequence-number>
CLI(crypto-manual)>
o sequence-number indicates the order/priority in which a packet is matched with selectors.

To remove a manual crypto map entry, use the following command:
CLI(configure)> no crypto map <name>
• To define the selector (IP filter that needs to be processed using IPsec), attach an access-list to it.
Use the following command in crypto map configuration mode:
CLI(crypto-manual)> match address <acl-name>
To remove the access-list and make all packets being authenticated/encrypted, use the no form of the
command:
CLI(crypto-manual)> no match address
• To configure the remote tunnel end-point, use the following command in crypto map configuration
mode:
CLI(crypto-manual)> set peer { <A.B.C.D> | <hostname> }
o A.B.C.D or hostname designates the address of the remote IPsec endpoint.

To remove the tunnel endpoint and deactivate the crypto map entry, use the no form of the command:
CLI(crypto-manual)> no set peer { <A.B.C.D> | <hostname> }
• Only one transform set can be applied per manual crypto map entry. To apply the selected IPsec
Transform to the crypto map entry, use the following command in crypto map configuration mode:
CLI(crypto-manual)> set transform-set <name>
To detach the IPsec Transform from the crypto map entry, use the no form of the command:
CLI(crypto-manual)> no set transform-set

• Configuring keying material manually is permitted on manual entries.

Primary, it is compulsory to set two security parameter indexes (SPI), one for each direction.
Secondly, keying material must be provided according to the chosen transforms.
o AH transform: HMAC-SHA1 requires a 20-byte key length, whereas HMAC-MD5 requires a key
length of only 16-bytes.
To configure AH keying material, use the following commands in crypto map configuration
mode:
CLI(crypto-manual)> set security-association inbound ah <spi>
{ <HEX-KEY-STRING-20B> | <HEX-KEY-STRING-16B> }
CLI(crypto-manual)> set security-association outbound ah <spi>

{ <HEX-KEY-STRING-20B> | <HEX-KEY-STRING-16B> }
o ESP transform: DES requires an 8-byte key length, AES-128 requires a 16-byte key length,
3DES and AES-192 require a 24-byte key length and AES-256 requires a 32-byte key length.
HMAC-SHA1 requires a 20-byte key length, whereas HMAC-MD5 requires a key length of only
16-bytes.
To configure ESP keying material, especially encryption keys, use the following commands in
crypto map configuration mode. The first argument is the key for encryption and the second
one for authentication. When the encryption is NULL, the authentication key must be provided.
CLI(crypto-manual)> set security-association inbound esp <spi>
{<HEX-KEY-STRING-8B> | <HEX-KEY-STRING-16B> | <HEX-KEY-STRING-24B> |
<HEX-KEY-STRING-32B>} [<HEX-KEY-STRING-20B> | <HEX-KEY-STRING-16B>]
CLI(crypto-manual)> set security-association outbound esp <spi>

{<HEX-KEY-STRING-8B> | <HEX-KEY-STRING-16B> | <HEX-KEY-STRING-24B> |
<HEX-KEY-STRING-32B>} [<HEX-KEY-STRING-20B> | <HEX-KEY-STRING-16B>]
o If the IPsec Transform requires compression, two compression parameter indexes must be
configured, using the following command:
CLI(crypto-manual)> set security-association outbound ipcomp <cpi>
CLI(crypto-manual)> set security-association inbound ipcomp <cpi>
You must provide the compression ID (cpi) with the same values at both ends of the IPsec
tunnel (cpi range: 0…65535).
• Use the following command to remove all inbound keying material:

CLI(crypto-manual)> no set security-association inbound
• Use the following command to remove all outbound keying material:

CLI(crypto-manual)> no set security-association outbound
• Then exit the crypto map configuration mode with the exit command:
CLI(crypto-manual)> exit
CLI(configure)>

5.5.3.2 Standard ISAKMP Crypto Map Entries
Before you start
• Standard IPsec ISAKMP crypto maps must be used in the following cases:
o IPsec clients using IKE, the remote peer is a server using dynamic ISAKMP crypto maps.
o Symmetric mode: when the concept of client/server is not used, both IPsec peers must use
such standard ISAKMP crypto maps.
Configuration
• To configure a standard ISAKMP crypto map entry named name, and enter in crypto map
configuration mode, use the following command:
CLI(configure)> crypto map ipsec-isakmp <name> <sequence-number>
CLI(crypto-isakmp)>
o <name> is the name of the crypto map.

o <sequence-number> indicates the order/priority in which a packet is matched with selectors.
To remove an ISAKMP crypto map entry, use the following command:
CLI(configure)> no crypto map <name>
• Within a crypto map entry, to select IP traffic, use the following command to attach an access list to it:
CLI(crypto-isakmp)> match address <acl-name>
Note that only permit rules with true network or host addresses must be used within the access list. It
may not contain a rule such as: permit ip 0.0.0.0 255.255.255.255 ….
To modify IP selectors for a next SA negotiation, or to prevent a future SA negotiation, you can detach
the access list from the crypto map entry, using the following command:
CLI(crypto-isakmp)> no match address
• To configure the tunnel end-point, use the following command:

CLI(crypto-isakmp)> set peer { <A.B.C.D> | <hostname> }
To remove the tunnel endpoint and deactivate the crypto map entry, use the following command:
CLI(crypto-isakmp)> no set peer { <A.B.C.D> | <hostname> }
• Only one transform set can be applied per ISAKMP crypto map entry. To apply the selected IPsec
Transform to the crypto map entry, use the following command:
CLI(crypto-isakmp)> set transform-set <name>
CLI(crypto-isakmp)> no set transform-set
• Other security parameters are negotiated with the ISAKMP endpoint.

• The lifetime of the SA is a parameter and can be expressed in kilobytes and/or in seconds.
For example, an IPsec SA will need to be refreshed when the total quantity of secured packets
reaches 100 megabytes.
To configure the SA lifetime, use the following commands:
CLI(crypto-isakmp)> set security-association lifetime seconds <60-131071>
CLI(crypto-isakmp)> set security-association lifetime kilobytes

<500-500000000>
o The default value for the SA lifetime is 3600 seconds and less than 100 MB.
To reset the lifetime to default values, use the default command:
CLI(crypto-isakmp)> default set security-association lifetime
{ seconds | kilobytes }
The lifetime in kilobytes and the lifetime in seconds can be configured at the same time. Both are
taken into account (default behavior); the one that triggers first causes the SA pair to be renegotiated.
Note that the IPsec service is not interrupted by renegotiation of the SA.
In addition to the hard limit configured, a soft limit is derived. This soft limit is reached when a high
percentage of the hard limit (such as 90%) is reached and the SA-refresh then starts to take place.
To disable a lifetime setting (seconds or kilobytes) to be taken into account for the lifetime of the SA,
CLI(crypto-isakmp)> no set security-association lifetime
• Perfect Forward Secrecy (PFS) is an optional service for exchanging keys.

PFS allows the use of keys that are not derived from the initial IKE negotiation. It is so that this initial
negotiation makes it easier for hackers to extract the pre-shared secret.
When renegotiating the SA, if PFS is configured, keys are regenerated, and exchanged by means of
PFS.
To configure PFS on a crypto map entry, use the following command:
CLI(crypto-isakmp)> set pfs groupx
o groupx can be one of the following:

 group1 - D-H Group1 (768-bit modp)
 group19 - D-H Group19 (256-bit ecp)
 group24 - D-H Group24 (2048-bit modp, 256 bit subgroup)
To remove PFS, use the no form of the command:

CLI(crypto-isakmp)> no set pfs

• It is possible to define when the ISAKMP negotiation shall start, using the following command:
CLI(crypto-isakmp)> set type { incoming | leased-line | dial }
o leased-line. The IPsec tunnel is automatically connected when the crypto map is
configured on an interface. Use this when the IPsec SA connection is to be available
regardless of user data.
o dial. This specifies the manual setting, to direct the crypto map to wait for user data before
attempting to establish the IPsec connection; this is the default setting.
o incoming. The crypto map will wait for an incoming request to establish an IPsec connection.
(passive mode).
To return to the (default) dial type, use the no form of the command:
CLI(crypto-isakmp)> no set type
• To apply an ISAKMP profile to the crypto map, use the following command:
CLI(crypto-isakmp)> set isakmp-profile <isakmp-profile-name>
To remove the ISAKMP profile from the crypto map, use the no form of the above command:
CLI(crypto-isakmp)> no set isakmp-profile
• To configure the extended authentication settings, use the following command:

CLI(crypto-isakmp)> set xauth username <username> password <password>
[<level>]
o Enter a <username> and <password>; the password can be 30 characters maximum if not
encrypted.
o The optional <level> parameter determines the level and type of encryption that will be used
to display the password when running the show running-config command.
If not specified, the passphrase in plain text will be displayed.
<level> can either be 0 or 1, depending on how the <password> is entered:
 0 means that the password is to be encrypted.
 1 means that the password is already encrypted.
• To exit the crypto map configuration mode, use the following command:
CLI(crypto-isakmp)> exit
CLI(configure)>

5.5.3.3 Dynamic ISAKMP Crypto Map Entries
Before you start
• Dynamic crypto maps must be used on the ISAKMP server (responder side).
The clients (ISAKMP initiators) must use standard crypto map entries. Because the server does not
know the peer IP address, only the source address of outgoing packets (source policy) is checked.
• The dynamic crypto map configuration is achieved in two steps:

o 1. Define the dynamic crypto map configuration template.
o 2. Declare a policy in the Security Policy Database using the template.
• The differences between the standard and the server modes are:
o The peer IP addresses are not known in advance, therefore the peer IP address is not
configured.
o Because the peer IP address is not known, the permit rules of the access list cannot filter any
destination network.
The permit rules must have the following form: permit ip <local-network> any.
Configuration
• Use the following command to enter in dynamic crypto map configuration template mode:
CLI(configure)> crypto dynamic <template-name>
CLI(crypto-template)>
To remove a dynamic crypto map configuration template, use the following command:
CLI(configure)> no crypto dynamic <template-name>
• Within a crypto map entry, to select IP traffic, use the following command to attach an access list to it:
CLI(crypto-template)> match address <acl-name>
Note that only permit rules with true network or host addresses must be used within the access list. It
may not contain a rule such as: permit ip 0.0.0.0 255.255.255.255 ….
To modify IP selectors for a next SA negotiation, or to prevent a future SA negotiation, you can detach
the access list from the crypto map entry, using the following command:
CLI(crypto-template)> no match address
• Only one transform set can be applied per ISAKMP crypto map entry. To apply the selected IPsec
Transform to the crypto map entry, use the following command:
CLI(crypto-template)> set transform-set <name>
CLI(crypto-template)> no set transform-set
• Other security parameters are negotiated with the ISAKMP endpoint.

• The lifetime of the SA is a parameter and can be expressed in kilobytes and/or in seconds.
For example, an IPsec SA will need to be refreshed when the total quantity of secured packets
reaches 100 megabytes.
To configure the SA lifetime, use the following commands:
CLI(crypto-template)> set security-association lifetime
seconds <60-131071>
CLI(crypto-template)> set security-association lifetime kilobytes

<500-500000000>
o The default value for the SA lifetime is 3600 seconds and less than 100 MB.
To reset the lifetime to default values, use the default command:
CLI(crypto-template)> default set security-association lifetime
The lifetime in kilobytes and the lifetime in seconds can be configured at the same time. Both are
taken into account (default behavior); the one that triggers first causes the SA pair to be renegotiated.
Note that the IPsec service is not interrupted by renegotiation of the SA.
In addition to the hard limit configured, a soft limit is derived. This soft limit is reached when a high
percentage of the hard limit (such as 90%) is reached and the SA-refresh then starts to take place.
To disable a lifetime setting (seconds or kilobytes) to be taken into account for the lifetime of the SA,
CLI(crypto-template)> no set security-association lifetime

PFS.
To configure PFS on a crypto map entry, use the following command:
CLI(crypto-template)> set pfs groupx
o groupx can be one of the following:

 group24 - D-H Group24 (2048-bit modp, 256 bit subgroup)
To remove PFS, use the no form of the command:

CLI(crypto-template)> no set pfs

• To apply an ISAKMP profile to the crypto map, use the following command:
CLI(crypto-template)> set isakmp-profile <isakmp-profile-name>
To remove the ISAKMP profile from the crypto map, use the no form of the above command:
CLI(crypto-template)> no set isakmp-profile
• To perform Reverse Route Injection (RRI), use the following command:

CLI(crypto-template)> reverse-route
Reverse route injection (RRI) is the ability to automatically insert routes in the routing process for
networks and hosts protected by a remote tunnel endpoint:
o When using a dynamic crypto map, the CO does not know which remote devices are going to
connect with which networks.
o When a remote device connects, an ACL is negotiated which is required to set up the SA’s, but
can also be used as source for routing information.
o Refer to the following example:
 [
 Assume that the CO has a dynamic crypto map installed on its GE 1/0 uplink, and the
CPE has a crypto access list configured protecting traffic from its internal network:
192.168.1.0/24.
 After the client connects to the CO device, the CO device knows that if traffic goes
through its interface GE1/0 to 192.168.1.0/24, this traffic must be encrypted.
 But first, the traffic that should go through GE1/0 must be routed, so routing information
is required.
 This can be ensured by Reverse Route Injection (RRI): RRI makes sure that when the
phase 2 SA is created, a route is added from 192.168.1.0/24 to GE1/0.
 When running the show ip route command, the route is marked with a specific
IPSEC flag.
• Exit from this mode and return to the global configuration mode to create the dynamic crypto map in
the policy database, using the following commands:
CLI(crypto-template)> exit
CLI(configure)> crypto map dynamic <name> <sequence-number>
<template-name>
o <name> is the name of the policy map, later used in the configuration to apply it to an interface.
o <sequence-number> is the index of the crypto map in the policy database.
To remove a dynamic crypto map entry, use the following command:

CLI(configure)> no crypto map dynamic <name> <sequence-number>
<template-name>

5.5.3.4 Easy VPN Crypto Maps
• Easy VPN simplifies the design of an IPsec network with multiple remote sites to be connected to one
central site (hub-and-spoke topology).
• Typically, the remote sites have an extension of the corporate private LAN of the company's
headquarters (i.e. a private subnet on their LAN side).
Both on the central site and on the remote sites, the configuration is simplified by applying Easy VPN.
• The central IPsec concentrator automatically learns the private IP networks through Mode
Configuration (MODE-CFG) when establishing the tunnels, which simplifies configuration of IP routing
in the IPsec concentrator.
The private IP networks are reached by the remote IPsec via the tunnel. These private networks are
defined as inside interfaces.
The interface to reach the remote IPsec is defined as outside interface.
• Authentication with IKE Extended Authentication (Xauth) also helps in simplifying management as the
authentication passwords for IKE establishment are held in a central database.
• OneOS supports Easy VPN in client and server modes. Refer to 5.6 Easy VPN Configuration for more
information.
5.5.3.5 Applying a Crypto Map to an Interface
Before you start
• The crypto map is directly applied on the output interface.

• The packets which have been routed to this output interface are processed by IPsec (encryption,
encapsulation in case of tunnel mode).
In case of IPsec tunnel mode, the packets are routed again with the tunnel endpoint IP address.
Configuration
• To apply the IPsec crypto map on an interface, use the following command in the interface
configuration mode:
CLI(config-if)> crypto map <name>
If crypto map entries are properly configured, this command fills in security associations and
associated selectors in the IPsec databases.
Use the no form of the command to remove entries of the databases.
CLI(config-if)> no crypto map

5.5.3.6 DF bit in tunnel mode
• IP fragmentation may be prevented by means of the DF bit in the IP header.

• To modify the DF bit in the encapsulating IP header for a specific interface, use the following
CLI(config-if)> crypto ipsec df-bit { clear | set | copy }
o clear. The DF bit of the outer IP header is cleared.

o set. The DF bit of the outer IP header is set.
o copy. The DF bit is taken from the inner IP header and copied into the outer IP header; this is
the default setting.
• Note that:
o This command is not applicable for IPsec tunnels in transport mode, in case of crypto maps on
a physical interface.
o This command is not taken into account when tunnel path-mtu-discovery is enabled.

5.6 EASY VPN CONFIGURATION
5.6.1.1 Easy VPN Client
An Easy VPN client group has several Easy VPN client entries, each one standing for a security policy
entry. This entry associates the IP traffic to be secured and the remote tunnel end-point.
A crypto IPsec Easy VPN client always uses ISAKMP. One SA connection (i.e. a separate tunnel) is
established for each inside interface. Keep the following principles in mind:
• IKE aggressive mode is used for the exchange of parameters.
• Only ISAKMP policy group 2 is supported on Easy VPN servers.
• All inside interfaces, whether they belong to a tunnel, are listed in interface configuration mode as an
inside interface, along with the tunnel name.
• There is no default inside interface.
• Easy VPN only supports one outside interface. If you attempt to assign it to more than one outside
interface, an error message is displayed. You must remove the configuration from the first interface
before assigning it to the second interface.
5.6.1.1.1 Easy VPN Client Configuration
• To configure a crypto IPsec Easy VPN client entry, and enter in crypto IPsec Easy VPN client
configuration mode, use the following command in global configuration mode:
CLI(configure)> [no] crypto ipsec client ezvpn <name>
CLI(crypto_ezvpn)>
o name identifies the Easy VPN client configuration with a unique and arbitrary name.
o Use the no form of the command to remove the Easy VPN client configuration.
o Note: you cannot use the no form of the command to delete a crypto IPsec Easy VPN client
that is assigned to an interface. You must remove that crypto IPsec Easy VPN client
configuration from the interface before you can delete the configuration.
• By defining which inside interfaces belong to the Easy VPN client configuration (see further), all traffic
from the subnets on these interfaces that are routed to the outside interface are automatically put in
the IPsec tunnel. To send other outgoing IP traffic on this interface also through the tunnel, you can
attach an access-list to it. The access list must not contain a rule such as permit ip any any, the
permit rules must always have the following form:
permit ip <local-network> <destination-network>
Use the following command to attach the ACL:

CLI(crypto_ezvpn)> match address <acl-name>
To detach an access-list from the crypto IPsec Easy VPN client entry:
CLI(crypto_ezvpn)> no match address
To configure the tunnel end-point, use the following command:

CLI(crypto_ezvpn)> peer { <A.B.C.D> | <hostname> }
To remove tunnel endpoint and deactivate crypto IPsec Easy VPN client entry, use the following
command:
CLI(crypto_ezvpn)> no peer

• IPsec can either be established automatically when Easy VPN is configured on the interface (auto) or
only when an IP packet is routed to the interface and that packet matches the IPsec policy (manual –
default behavior). Use the following command to set the desired behavior:
CLI(crypto_ezvpn)> connect { auto | manual }
• Easy VPN requires a group name and pre-shared key to be exchanged. With the group name the
server side can distinguish between different Easy VPN groups. Note that this group name may be
different from the name entered when creating the Easy VPN client entry.
To configure the group name and key (that must match the ones configured on the Easy VPN server),
CLI(crypto_ezvpn)> [no] group <group-name> key <group-key>
Within an Easy VPN group, the IPsec clients must be individually authenticated by Xauth (note that
only PAP authentication is supported with Easy VPN). A username and password must be provided:
CLI(crypto_ezvpn)> [no] username <user-name> password <user-password>
• Because the client device does not have a user interface option to enable or disable PFS negotiation,
the server will notify the client device of the central site policy during IKE MODE-CFG. The Diffie-
Hellman (D-H) group that is proposed for PFS will be the same as negotiated in Phase 1 of the IKE
negotiation.
• To complete the Easy VPN group configuration, enter the following command:
CLI(crypto_ezvpn)> exit
CLI(configure)>
5.6.1.1.2 Applying Easy VPN client configuration on Interfaces
• Note that:
o The outside interface is the interface from which the tunnel is established (only one outside
interface is allowed/supported).
o An inside interface connects to an IP network that is reached via the tunnel and advertised to
the peer by Easy VPN IKE extensions. Multiple inside interfaces are supported.
• To assign an client Easy VPN configuration to an interface, specify with the following command in
interface configuration mode whether the interface is outside or inside, and configure one outside and
one or more inside interfaces. To remove the Easy VPN configuration from the interface, use the no
form of this command.
CLI(config-if)> crypto ipsec client ezvpn <name> { outside | inside }
CLI(config-if)> no crypto ipsec client ezvpn <name>
• Notes:
o An inside reference is only allowed if the interface has a fixed IP address.
o An Easy VPN client configuration should be created before assigning it to an interface.

5.6.1.2 Easy VPN Server
Easy VPN server is not aware of the IP addresses the VPN client (whether a CPE or a PC-based client
software) will be using to set up the VPN tunnel. The remote user can be connected behind a NAT router
(NAT-T feature as per RFC 3947 is supported). Xauth is supported for remote user authentication as an
IKE phase 1 is done in aggressive mode. Without Xauth, the end user cannot be authenticated because
the pre-shared key (PSK) is common to a group of users.
IKE Mode configuration (MODE-CFG) is supported for native IPsec clients. MODE-CFG is based on the
draft-dukes-ike-mode-cfg-02 document. The transactions are protected by the ISAKMP SA. The following
parameters can be given to the nomad users:
• IPv4 address
• IPv4 network mask
• IPv4 Domain Name Server (DNS) addresses (up to 2)
• IPv4 NetBIOS Name Server (WINS) addresses (up to 2)
Reverse Route Injection (RRI) ensures that for each client address a static route is created on the server
through the VPN tunnel. Refer to 5.5.3.3 Dynamic ISAKMP Crypto Map Entries for more information on
RRI configuration.
5.6.1.2.1 Easy VPN Server license activation
• Easy VPN server functionalities are only available when the ezVPN server software license, which is
part of the ASIP license, is activated. The related commands are rejected if the license is not activated
on the router. License activation is possible if the product has sufficiently hardware resources and is
pre-loaded with the rights to use the license.
• The ezVPN server software license is part of the ASIP license; use the following command in global
configuration mode to activate the ASIP license:
CLI(configure)> license activate asip
--------------------------------------------------------------
End-User License Agreement
--------------------------------------------------------------
You are only allowed to use the features covered by this
license, if OneAccess has granted permissions to you or your
company. The features covered by the license are:
-ezVPN server, GET VPN, Zone based Firewall
By using one of the above mentioned features, you acknowledge
that you got these permissions.
--------------------------------------------------------------
This license also covers feature : com-port-server
By using the above mentioned feature, you acknowledge
that you got that permission.
--------------------------------------------------------------
'asip' license successfully enabled.
CLI(configure)>
• Note that the ezVPN server software license is also activated with
the license activate ezvpnserver command.

5.6.1.2.2 Easy VPN Server authentication configuration
Use the following command, in global configuration mode, to define whether Easy VPN clients'
authentication, achieved using Xauth, is done locally or through RADIUS or TACACS+ server.
CLI(configure)> [no] aaa authentication login <list-name> { radius
| tacacs
| local
| <group-name>}
list-name is a string of 32 characters at most defining the name of the authentication list. This name is
referenced to in a crypto ISAKMP profile (see below).
group-name refers to a list of RADIUS or TACACS+ servers to be used for the authentication.
This command can be entered several times with the same list name. They are then considered in the
order they have been entered. For example: if RADIUS and local are entered in this order, to reach the
RADIUS server for the authentication is tried first; if this fails, the local authentication is done.
Use the no form of the command to remove the authentication list entry.
Use the following command, in crypto ISAKMP profile configuration mode, to enable Xauth authentication
using the authentication list defined above.
CLI(crypto_profile)> [no] client authentication list <list-name>
Use the no form of the command to disable Xauth authentication (default behavior).
Use the following command, in global configuration mode, to define user names and passwords for Easy
VPN clients if local Xauth authentication is used.
CLI(configure)> username <user-name> password <user-password> [0|1]
user-name is a string of 64 characters at most

When last parameter is set to 0 (or not set – default value), user-password is entered in clear-text as a
string of 32 characters at most. It will then be stored and displayed encrypted. To enter user-password
already encrypted: set last parameter to 1.
Use the following command to remove a client's name and password.
CLI(configure)> no username <user-name>

5.6.1.2.3 Easy VPN Server MODE-CFG client configuration
Easy VPN Server can provide the remote users with their network parameters (MODE-CFG). The
supported allocation methods are:
• Local allocation: The client's parameters are all configured locally (see below).
• Using DHCP: IP address, network mask, DNS servers addresses and WINS servers addresses are
lookup via a DHCP request to an internal or external server. In this case the locally configured
parameters – in any – are not taken into account.
• Using RADIUS: When authentication is done through a RADIUS server, it can be configured to return
also the IP address and the network mask. These parameters are then returned to the client during
MODE-CFG. Other parameters are not supported in this method.
Use the following command, in global configuration mode, to enter in client group parameters local
configuration mode.
CLI(configure)> [no] crypto isakmp client configuration group { default
| <group-name> }
CLI(crypto_group)>
group-name is a string of 32 characters at most corresponding to the one received in the client request.
default is the group name used for all users who do not offer a group name that matches a group-
name argument. Default group parameters can only be configured locally.
Use the no form of the command to remove the client group configuration and all associated locally
configured parameters.
Use the following command, in client group configuration mode, to define the IKE pre-shared key for group
policy attribute definition. This command is mandatory if the client identifies itself with a pre-shared key.
CLI(crypto_group)> key <crypto-key> [0|3]
crypto-key is either a clear-text string of 90 bytes at most that can be used encrypted (set the last
parameter to 0) or not (do not use the last parameter), or an already level 3 encrypted string of 128 bytes
at most (set the last parameter to 3).
Use the no form of the command to remove the IKE pre-shared key definition.
CLI(crypto_group)> no key
Use the following command, in client group configuration mode, to allow a client to save his Xauth
password locally. This command is optional.
CLI(crypto_group)> save-password
Use the no form of the command to disallow the client to save his password.
CLI(crypto_group)> no save-password
Use the following command, in client group configuration mode, to assign a local pool of IP addresses to
the clients' group. This command is mandatory unless RADIUS gives already the IP address or a DHCP
server is configured.
CLI(crypto_group)> pool <pool-name>
Use the no form of the command to remove the pool of IP addresses.

CLI(crypto_group)> no pool
Use the following command, in client group configuration mode, to define the network mask of the client.
CLI(crypto_group)> netmask <mask>

Use the no form of the command to remove the network mask configuration.
CLI(crypto_group)> no netmask
Use the following command, in client group configuration mode, to define the primary DNS server (and
optionally the secondary DNS server) for the clients' group. This command is optional.
CLI(crypto_group)> dns <dnsserver1> [<dnsserver2>]
Use the no form of the command to remove the DNS servers' configuration.
CLI(crypto_group)> no dns
Use the following command, in client group configuration mode, to define the primary WINS server (and
optionally the secondary WINS server) for the clients' group. This command is optional.
CLI(crypto_group)> wins <winsserver1> [<winsserver2>]
Use the no form of the command to remove the WINS servers' configuration.
CLI(crypto_group)> no wins
Use the following command, in client group configuration mode, to define the DNS domain the clients'
group belongs to. This command is optional.
CLI(crypto_group)> domain <domain-name>
Use the no form of the command to remove the domain configuration.

CLI(crypto_group)> no domain
Use the following command, in client group configuration mode, to tell the client to propose Perfect
Forward Secrecy (because he has no other mean to be asked to propose PFS). This command is optional.
CLI(crypto_group)> pfs
Use the no form of the command to remove PFS configuration.

CLI(crypto_group)> no pfs
Use the following command, in client group configuration mode, to define a domain name that must be
appended for resolution to the private network. This command is optional.
CLI(crypto_group)> split-dns <domain-name>
Use the no form of the command to remove the split DNS domain configuration.
CLI(crypto_group)> no split-dns
Use the following command, in client group configuration mode, to define the access control list (ACL) for
the traffic that passes through the VPN tunnel (split tunneling). This command is optional. Without this
command all traffic from the client passes through the tunnel.
CLI(crypto_group)> acl <acl-name>
Use the no form of the command to remove the ACL configuration.

CLI(crypto_group)> no acl

Use the following command, in client group configuration mode, to define the address of the DHCP server
used to retrieve the IP address, the network mask, the DNS and WINS servers' addresses from. If
configured, these parameters overrule the locally configured parameters.
CLI(crypto_group)> dhcp server <IP-address>
Use the following command, in client group configuration mode, to define the DHCP gateway IP address
(GIADDR) used in the DHCP request message. This command is optional. Without this command the
Easy VPN Server will pass its address that will determine the scope for the client IP assignment.
CLI(crypto_group)> dhcp giaddr <IP-address>
Use the no form of the command to remove the DHCP configuration.

CLI(crypto_group)> no dhcp
5.6.1.2.4 Easy VPN Server statistics
Use the following command, in global mode, to display the number of active Easy VPN connections per
client group.
CLI> show crypto session groups
group connections
MyGroup 2
RD 1
Use the following command, in global mode, to display the active connections for each client group.
CLI> show crypto session summary [<group-name>]
group MyGroup has 2 connections

rohnny with ip 192.168.21.200
jan
group RD has 1 connection
stefan

5.7 IPSEC CONFIGURATION BY MEANS OF AN IPSEC PROFILE (IKEV1

AND IKEV2)
Preliminary notes:
• IPsec profiles have been introduced as of OneOS v5.2R2. Crypto maps exist since IPsec is
supported.
• The IPsec performance significantly improves when using IPsec profiles to configure IPsec tunnels.
Therefore, the use of IPsec profiles, instead of crypto maps, is strongly recommended
5.7.1 Protecting a Tunnel with an IPsec Profile
• Both an IPsec in IPv4 tunnel and a GRE tunnel can be protected with a protection profile: first set the
tunnel mode, and then set an IPsec profile.
IPSec in IPv4 Transport or GRE
• To create a tunnel interface, use the following command in global configuration mode:
CLI(configure)> interface tunnel <unit>
CLI(config-if)>
• To configure a tunnel using IPsec encapsulation with IPv4 as the transport mechanism, use the
following command:
CLI(config-if)> tunnel mode ipsec ipv4
• To configure a GRE tunnel, use the following command:

CLI(config-if)> tunnel mode gre
Tunnel IPsec Protection
• IPsec can be used to protect the tunnel interface, by means of an IPsec profile. To do so, use the
following command:
CLI(config-if)> tunnel protection ipsec profile <prof-name>
o <prof-name> is the name of the IPsec profile; section 5.7.2 Configuring an IPsec Profile
describes the creation of an IPsec profile.

Caveats
Keep the following in mind when configuring a tunnel:

• Make sure to double-check the source and destination of the tunnel, and the match statements
(e.g. pre-shared key, IKEv2 profile), especially when NAT is involved.
• Tunnels will start to negotiate spontaneously, under the condition that the IPsec profile has not been
configured as responder-only.
• OneOS only supports GRE tunnels in transport mode; make sure to set the transform sets that are
used in the IPsec profile, in transport mode as well.
Note that:
o a GRE tunnel can be configured with the tunnel mode gre command;
refer to section 3.2.3 Setting tunnel encapsulation mode of the Basic IP User Guide for further
details.
o a transform set can be set in transport mode with the mode transport command;
section 5.5.2 Configuring IPsec Transforms explains how to create and configure transform
sets.
• IPv4 in IPv4 tunnels must be configured with the tunnel mode ipsec ipv4 command, and not via
the tunnel mode ipip command (this will give an IPv4 in IPv4 tunnel without IPsec);
IPv4 in IPv4 tunnels only work in tunnel mode.
• Note that, when updating the configuration of a tunnel interface, the changes only take effect after
exiting the configuration with the exit or end command.
5.7.2 Configuring an IPsec Profile
• In the case of IKEv2, an IPsec profile with IKEv2 support must be created, i.e. an IKEv2 profile must
be referenced in the IPsec profile;
refer to 5.7.2.6 Setting an IKEv2 profile in the IPsec Profile.
• In the case of IKEv1, an IPsec profile with IKEv1 support must be created, i.e. an ISAKMP profile must
be referenced in the IPsec profile;
refer to 5.7.2.5 Setting an ISAKMP profile in the IPsec Profile (IKEv1).
Note that ISAKMP SAs can be established without mapping an ISAKMP profile to the IPsec profile.
• To define the IPsec parameters that are to be used for IPsec protection between two peers and to
enter IPsec profile configuration mode, use the following command in global configuration mode:
CLI(configure)> crypto ipsec profile <profile-name>
CLI(ipsec-profile)>
To delete an IPsec profile, use the no form of this command:

CLI(configure)> no crypto ipsec profile <profile-name>

5.7.2.1 Responder Only
• To configure the OneOS device as responder-only, i.e. SAs are not initiated by the OneOS device,
use the following command in IPsec profile configuration mode:
CLI(ipsec-profile)> responder-only
Note that in this case, IPsec SA’s are not rekeyed either. The OneOS device expects the initiator to
rekey.
5.7.2.2 Setting one or more Transform Sets
• To define one or more transform sets to be used by the IPsec profile, use the following command:
CLI(ipsec-profile)> set transform-set <transform-set-name1>
<transform-set-name2>
This command allows specifying a list of transform sets in order of priority. Up to 6 transform sets can
be configured.
• Section 5.5.2 Configuring IPsec Transforms explains how to create transform sets.
5.7.2.3 Perfect Forward Secrecy or PFS

PFS.
• When using PFS, a Diffie-Hellman (D-H) group must be set. The bigger the DH group is, the more
secured the exchange is, but the more time is required to calculate the key.
• Both peers in a VPN exchange must use the same DH group.
• To configure PFS on the IPsec profile, use the following command:
CLI(ipsec-profile)> set pfs { group1 | group14 | group15 | group16 |
group19 | group2 | group20 | group24 | group5 }
One of the following Diffie-Hellman groups can be set:

o group1 - D-H Group1 (768-bit modp)
o group19 - D-H Group19 (256-bit ecp)
o group20 - D-H Group20 (384-bit ecp)
o group24 - D-H Group24 (2048-bit modp, 256 bit subgroup)

5.7.2.4 Security Association Parameters
The following security association parameters can be set:
Idle Time
• The SA idle time is the time without traffic on the IPsec tunnel, after which the IPsec SA is deleted.
To set the SA idle time, use the following command:
CLI(ipsec-profile)> set security-association idle-time <60-86400>
Any value between 60 and 86400 seconds can be set. By default, the idle time is disabled, i.e. 0.
Life Time
• The SA life time, i.e. the time the SA remains valid, can be expressed in kilobytes (volume-based key
duration) and/or in seconds (time-based key duration).
• To configure the SA lifetime, use the following commands.

o Use the following command for volume-based key duration.
CLI(ipsec-profile)> set security-association lifetime kilobytes
<2560-4294967295>
 Any value between 2560 and 4294967295 kilobytes can be set. By default, the lifetime
is disabled, i.e. 0.
o Use the following command for time-based key duration.
CLI(ipsec-profile)> set security-association lifetime seconds
<120-86400>
 Any value between 120 and 86400 seconds can be set. By default, the lifetime is
disabled, i.e. 0.
• To disable volume-based key duration, use the following command:

CLI(ipsec-profile)> set security-association lifetime kilobytes disable
• To return to the default values, use the following commands:

CLI(ipsec-profile)> no set security-association lifetime seconds
CLI(ipsec-profile)> no set security-association lifetime kilobytes

5.7.2.5 Setting an ISAKMP profile in the IPsec Profile (IKEv1)
• Note that this applies to IKEv1.

• To apply an ISAKMP profile to be used by the IPsec profile, use the following command:
CLI(ipsec-profile)> set isakmp-profile <profile-name>
Section 5.8 Configuring IKEv1 (ISAKMP) explains how to create an ISAKMP profile.
5.7.2.6 Setting an IKEv2 profile in the IPsec Profile
• To set an IKEv2 profile to be used by the IPsec profile, use the following command:
CLI(ipsec-profile)> set ikev2-profile <ikev2-profile-name>
• Section 5.9.4 Configuring an IKEv2 profile describes the configuration of an IKEv2 profile.
• How an IKEv2 profile is selected during the IKEv2 negotiations, is different for the initiator and
responder:
o In case of the Initiator: the IKEv2 profile is found using the reference from the IPsec profile.
o In case of the Responder: the IKEv2 profile is selected through matching (using the match
statements). When the IKEv2 negotiation proceeds, the reverse references are cross-checked
to ensure that the configuration is valid.
• For more information about IKEv2, refer to 5.9 Configuring IKEv2.

5.8 CONFIGURING IKEV1 (ISAKMP)
5.8.1 E n a b l i n g Cr yp t o I S AK M P
• ISAKMP packets are sent using UDP on port 500. To permit transmission of ISAKMP packets from
the OneOS based router, use the following command in configuration mode:
CLI(configure)> crypto isakmp enable
Use the no form of the command to disable ISAKMP exchange:

CLI(configure)> no crypto isakmp enable
• Use the following command to verify the ISAKMP connection:

CLI(configure)> crypto isakmp check-interval <10-120>
o This verifies the connection at regular intervals, which can be set between 10 and 120
seconds.
o Use the no form of the command to stop the verification process.
5.8.2 ISAKMP Identity
• ISAKMP entities identify themselves using either the outgoing IP address or the hostname.
Use the following command to define the identity (address is the default value).
CLI(configure)> crypto isakmp identity { address | hostname }
Use the no form of the command to apply the default value:

CLI(configure)> no crypto isakmp identity
5.8.3 ISAKMP key
• ISAKMP peers share a secret to authenticate each other. This secret is used to encrypt ISAKMP
traffic. The secret is stored locally and associates to a peer.
A secret for a given address or hostname can be entered by using the following command:
CLI(configure)> crypto isakmp key <key> { address <A.B.C.D>
[<mask>] | hostname <host> } [0 | 3 | 4]
[vrf <vrf-name>]
o The optional parameters [0 | 3 | 4] allow:

 When not used, to enter the secret in clear text and display it in clear text.
 When set to 0, to enter the secret in clear text and display it encrypted.
 When set to 3, to enter the secret in level 3 encrypted form and display it encrypted.
 When set to 4, to enter the secret in level 4 encrypted form and display it encrypted.
o In case of dynamic server, wild cards can be used (such as 0.0.0.0 0.0.0.0) since the peer IP
addresses are not known in advance.
• The key can be removed by using the no form of the command:

CLI(configure)> no crypto isakmp key <key> { address <A.B.C.D>
[<mask>] | hostname <host> } [0 | 3 | 4]
[vrf <vrf-name>]

5.8.4 ISAKMP policy
• Prior to establishing IKE phase 1, both peers agree on the policy used for communicating.
They select the policy by sending a list of proposals that contains a list of ISAKMP policies ordered in
preference order.
To enter in ISAKMP policy configuration mode, use the following command:
CLI(configure)> crypto isakmp policy <identifier>
CLI(config-isakmp)>
o <identifier> indicates the preference order. 1 stands for the highest priority, while 10000
stands for the lowest priority. A policy is made up of encryption and hash algorithms.
To remove an ISAKMP policy, use the no form of the command:
CLI(configure)> no crypto isakmp policy <identifier>
• To configure the encryption used in an ISAKMP policy, use the following command:
CLI(config-isakmp)> encryption {encryptionStandard}
o {encryptionStandard} can be one of the following:

3des => Three key triple DES
aes => AES - Advanced Encryption Standard (128 bit keys)
aes-192 => AES - Advanced Encryption Standard (192 bit keys)
aes-256 => AES - Advanced Encryption Standard (256 bit keys)
aes-cbc-128 => AES - Advanced Encryption Standard (128 bit keys)
des => DES - Data Encryption Standard (56 bit keys)
The default encryption algorithm is des and is activated with the following default command:
CLI(config-isakmp)> default encryption
• To configure the hashing algorithm used in an ISAKMP policy, use the following command:
CLI(config-isakmp)> hash { md5 | sha1 | sha256 | sha384 | sha512 }
With:
o md5 => Message Digest 5
o sha1 => Secure Hash Algorithm-1
o sha256 => Secure Hash Standard 2 (256 bit)
The default hashing algorithm is sha1 and is activated with the following default command:
CLI(config-isakmp)> default hash

• The authentication method tells how to authenticate with the remote peer; a pre-shared key and RSA
signatures are authorized.
To configure pre-shared authentication, use the following command:
CLI(config-isakmp)> authentication pre-share
To configure authentication by using RSA signatures, use the following command:

CLI(config-isakmp)> authentication rsa-sig
To set the default authentication method (pre-share), use the following command:
CLI(config-isakmp)> default authentication
• The lifetime of an ISAKMP SA can be set with the following command:

CLI(config-isakmp)> lifetime <60-131071>
To set the default value, 86400, use the following command:

CLI(config-isakmp)> default lifetime
• Key exchange requires the selection of a Diffie-Hellman group (DH). The bigger the DH group is, the
more secured the exchange is. By default, group 2 is provided.
To configure a DH group, use the following command:
CLI(config-isakmp)> group { 1 | 2 | 5 | 14 | 15 | 16 | 19 | 20 | 24}
o With:
1 => Group 1 (768-bit Diffie-Hellman)
To set the default group, use the following command:

CLI(config-isakmp)> default group
These commands configure the proposed group list that is sent to the remote ISAKMP peer.
The remote chooses the transform and replies. Once agreed on the transform, both peers forge their
keys, and pass it to the remote peer using the chosen group.
• To finalize the ISAKMP policy configuration, exit the ISAKMP policy configuration mode:
CLI(config-isakmp)> exit
CLI(configure)>

5.8.5 ISAKMP Keepalive
• ISAKMP keepalive stands for a facility that enables IPsec gateways to detect dead peers. It is
compliant with RFC 3706, which specifies that each device must reply to DPD queries from remote
IKE peers.
• The implementation of dead IKE peer detection involves the following:
When sending keepalive packets, the ISAKMP peer must respond to the received message.
If no answer is received, the ISAKMP peer seems to be dead. To make sure the peer is not alive, two
additional keepalive messages are sent.
If no answer is received on both messages, the ISAKMP peer is considered as dead.
The ISAKMP connection is reset locally as well as its IPsec SAs.
• During the ISAKMP negotiation, the peers exchange whether they support keepalive or not.
If the peer does not support keepalive, the router will not send keepalive packets over the IPsec
tun¬nel, even if it is globally configured to do so.
• Two timers can be configured:
o The trigger timer: this is the inactivity period during which no traffic has been detected coming
from the ISAKMP peer or from the corresponding tunnel. If this timer expires, a keepalive
mes¬sage is sent to the remote peer to check if it is still alive. The default timer value is 30
seconds.
o The retry timer: this is the number of seconds between keepalive retries if the previous keep-
alive message fails; the default timer value is 10 seconds.
A total of 5 retries is sent before the connection with the remote ISAKMP peer is considered as
lost. Using the default values this occurs after 30 + 5*10 + 10 = 90 seconds.
• ISAKMP keepalive is not enabled by default. To enable ISAKMP keepalive, use the following com-
mand:
CLI(configure)> crypto isakmp keepalive [<5-3600> [<2-60>]
[periodic | on-demand]]
o The first parameter, <5-3600>, is the trigger timer, expressed in seconds;

the second one, <2-60>, is the retry timer, expressed in seconds.
o By default, keepalive packets are sent regularly except when there already is incoming traffic
from the remote peer.
To modify this behavior, use the following optional keywords:
 periodic. Keepalive packets are always sent, even if traffic was detected on the
tunnel: in that case, the trigger timer is just the duration between two keepalive
messages sent.
 on-demand. Keepalive packets are sent only when outgoing traffic has been initiated.
To restore the default values, use the following command:
CLI(configure)> crypto isakmp keepalive
To disable ISAKMP keepalive, use the following command:

CLI(configure)> no crypto isakmp keepalive

• Application cases for ISAKMP keepalive are:

o Re-initialization of IKE: the shutdown command resets active sessions on the interface.
The no shutdown command allows the re-initialization of IPsec connections if they were
present initially. Usually, such reconnection request fails and a 3-minute timer is fetched.
ISAKMP keepalive accelerates the reconnection time.
o Ability to track the tunnel interface state: the tunnel is up if the ISAKMP connection is up.
When the tunnel is down, the command show interfaces tunnel displays the remaining
time until the next IPsec re-establishment retry.
5.8.6 ISAKMP Aggressive Mode
• To configure an IKE peer for aggressive mode, use the following command:
CLI(configure)> crypto isakmp peer { address <ip> [<mask>] |
hostname <host> } [vrf <vrf-name>]
CLI(config-isakmp-peer)>
 address <ip>. <ip> is the IP address of the remote peer.

 <mask> is the IP Netmask of the remote network.
 hostname <host>. <host> is the hostname of the remote peer.
 vrf <vrf-name>. Optionally, a different VRF than the default VRF can be used.
Use the no form of the command to remove the crypto isakmp peer:
CLI(configure)> no crypto isakmp peer { address <ip> [<mask>] |
hostname <host> } [vrf <vrf-name>]
• Use the following command to enter the aggressive mode pre-shared key:
CLI(config-isakmp-peer)> set aggressive-mode password <psk> [<level>]
o <psk> is the pre-shared key.

<level> can either be 0, 3 or 4, depending on how the <psk> is entered:
 0 means that the <psk> is entered in plain text, and is to be encrypted.
 3 means that the <psk> is already level 3 encrypted (legacy).
 4 means that the <psk> is already level 4 encrypted.
To remove the aggressive mode pre-shared key, enter the following command:
CLI(config-isakmp-peer)> no set aggressive-mode password
Example:
crypto isakmp peer address 172.31.124.229
set aggressive-mode password presharedkey
exit
• Use the following command to use the user-fqdn as tunnel-client-endpoint:

CLI(config-isakmp-peer)> set aggressive-mode client-endpoint
user-fqdn <user-fqdn>
To remove the aggressive-mode client-endpoint user-fqdn, use the no form of the

command:
CLI(config-isakmp-peer)> no set aggressive-mode client-endpoint
• Use the following command to disable ISAKMP aggressive mode:

CLI(configure)> crypto isakmp aggressive-mode disable

5.8.7 ISAKMP Profile
• An ISAKMP profile is an enhancement to the ISAKMP configuration. It is used to set parameters of an

IPsec connection. These parameters consist of the identity of IKE phase 1 connections including IP
address, fully qualified domain name (FQDN) and the user FQDN (email address).
The match command allows verifying the peer's identity against a list of known and trusted peers.
If the identity of a peer is hidden within a certificate, a certificate map can provide even more
information about the peer's identity.
An ISAKMP profile will be applied to an ISAKMP crypto map;
refer to 5.5.3 Configuring a Crypto Map.
• To configure an ISAKMP profile and enter in ISAKMP profile configuration mode, use the following
command:
CLI(configure)> crypto isakmp profile <name>
CLI(conf-isa-prof)>
To remove an ISAKMP profile, use the following command:

CLI(configure)> no crypto isakmp profile <name>
• To define the identity that the local IKE will use to identify itself to the remote peer, use the following
command. Note that if no ISAKMP profile is configured, IKE will use the globally configured value with
the crypto isakmp identity command.
CLI(conf-isa-prof)> self-identity { address <address> | key-id <key-id> |
user-fqdn <user-fqdn> }
o address <address>. This is the IP address of the egress interface; this is the default value
within the ISAKMP profile.
o user-fqdn <user-fqdn>. This is a 64-char long string, usually an email address.
To make IKE use the globally configured value again, use the following command:
CLI(crypto_profile)> default self-identity
• To define the identity that the local IKE has to check against the peer's identity, use the following
command. Multiple match identity commands can be configured.
The peer is mapped to the ISAKMP profile when its identities (as given in the ID payloads of the IKE)
match the identities defined in the profile.
CLI(conf-isa-prof)> match identity { address <address> [<mask>] |
key-id <key-id> | user-fqdn <user-fqdn> }
o <address> is the value to check against the ID_IPV4_ADDR type field; optionally, a netmask
can be entered as well, <mask>.
o <user-fqdn> is the value to check against the ID_USER_FQDN type field.
To remove an identity from the list to check, use the no form of the command.

• To use a VRF different from the default VRF, use the following command:
CLI(conf-isa-prof)> [no] vrf <vrf-name>
To remove the VRF, use the no form of the above command.
• When certificates are used for authentication, the following command allows verifying the content of
the fields of the peer's certificate. This is accomplished by applying a certificate map to the profile.
CLI(conf-isa-prof)> [no] match certificate <name>
o <name> is the name of the certificate map.

To remove the certificate matching from the profile, use the no form of the command.
• Prior to the certificate matching, the following command allows checking the revocation of the
certificate. This is accomplished by activating a trust-point in the profile to check the revocation.
CLI(conf-isa-prof)> [no] trustpoint <name>
o <name> is the name of the trust-point that is activated to check the revocation of the certificate.
To disable the trust-point checks from the profile, use the no form of the command.
• Use the following command to specify an ISAKMP keyring:

CLI(conf-isa-prof)> keyring <keyring-name>
• Use the following command to start the aggressive mode in the phase 1 negotiation:
CLI(conf-isa-prof)> initiate mode aggressive
Use the no form of the command to switch back from aggressive mode to main mode (default mode),
i.e. the phase 1 negotiation is done in main mode:
CLI(conf-isa-prof)> no initiate mode
• Use the following command to set a keepalive interval for use with IOS peers:
CLI(conf-isa-prof)> keepalive <period-in-seconds> retry <retry-timer>
o <period-in-seconds> is the number of seconds between keepalive messages; any number

between 10 and 3600 seconds can be set.
o With retry <retry-timer>, the retry interval can be set if keepalive fails. The retry interval
is expressed in seconds, any value between 2 and 60 seconds can be set.

5.8.8 C o n fi g u r i n g a n I KE v 1 Ke yr i n g
• To configure an IKEv1 keyring, first enter keyring configuration mode:

CLI(configure)> crypto keyring <keyring-name> [vrf <vrfname>]
CLI(crypto_keyring)>
To remove the IKEv1 keyring, use the no form of the command:

CLI(configure)> no crypto keyring <keyring-name> [vrf <vrfname>]
• Use the following commands to specify a pre-shared key:

CLI(crypto_keyring)> pre-shared-key { address <ipAddr> [<mask>] |
hostname <name> } key <key> [level <level>]
o <ipAddr>, <mask>. This is the IP address of the remote peer; optionally, a subnet mask can
be entered. The default netmask is 255.255.255.255.
o <name> is the hostname of the remote peer.
o <key> is the key itself. This must be entered as clear text, or as an encrypted string.
Depending on what is used, the <level> must be set accordingly.
<level> can either be 0, 3 or 4, depending on how the <key> is entered:
 0 means that the <key> is entered in plain text, and is to be encrypted.
 3 means that the <key> is already level 3 encrypted (legacy).
 4 means that the <key> is level 4 encrypted.
To remove the pre-shared key, use the no form of the command:

CLI(crypto_keyring)> no pre-shared-key address <ipAddr> [<mask>]
CLI(crypto_keyring)> no pre-shared-key hostname <name> key <key>
Configuration example
In following example, keyring IKEv1_Keyring is configured and used in ISAKMP profile

IKEv1_Profile.
crypto keyring IKEv1_Keyring

pre-shared-key address 3.0.0.1 255.255.255.255 key oneaccess
exit
crypto isakmp profile IKEv1_Profile
initiate mode aggressive
keepalive 25 retry 3
match identity address 3.0.0.1 255.255.255.255
match identity user-fqdn CommonName.OneAccessBelgium.com
keyring IKEv1_Keyring
exit

5.8.9 NAT Traversal
NAT Traversal Activation
• To disable NAT Traversal on the router, and prevent it from using UDP port 4500, use the following
CLI(configure)> no crypto isakmp nat-traversal udp-encapsulation
To restore the default configuration, and enable NAT Traversal on the equipment, and use UDP port
4500 when possible, use the active form of the above command:
CLI(configure)> crypto isakmp nat-traversal udp-encapsulation [force]
NAT Traversal on a Port
• To configure NAT Traversal on a specific port, use the following command in global configuration
mode:
CLI(configure)> crypto isakmp nat-traversal port <1-65535>
To restore the default configuration, use the no form of the command:

CLI(configure)> no crypto isakmp nat-traversal port
NAT Traversal Keepalive
• The NAT Traversal detects NAT devices in the middle of the IPsec tunnel path.
• NAT devices maintain a context to keep track of the IPsec session (tunnel). The context is removed
after a certain timeout.
In order to maintain the NAT entry in the intermediate NAT device, dummy UDP packets (with no
payload) are periodically sent every 20 seconds.
To change the emission frequency of UDP keepalive packets, use the following command in
configuration mode:
CLI(configure)> crypto isakmp nat keepalive seconds <5-3600>
To disable the NAT keepalive function, use the no form of the command:
CLI(configure)> no crypto isakmp nat keepalive
NAT Traversal Vendor-ID
• Some IPsec connection setups may fail due to compatibility issues regarding the NAT Traversal
payload type, encapsulation mode and vendor-id hash. Forcing the nat-traversal vendorid to
draft-03 may solve this problem:
o rfc3947: (default) uses the RFC 3947 settings regarding ISAKMP NATD and NATOA
payload, UDP encapsulation mode and vendor-id hash. ISAKMP will fall back to the draft
settings when the peer does not support the RFC 3947.
o draft-03: uses the draft-ietf-ipsec-nat-t-ike-03 settings regarding ISAKMP NATD and NATOA
payload, UDP encapsulation mode and vendor-id hash.
The command is the following:
CLI(configure)> crypto isakmp nat-traversal vendorid {rfc3947 | draft-03}
To restore the default configuration (rfc3947), use the no form of the command:
CLI(configure)> no crypto isakmp nat-traversal vendorid

5.9 CONFIGURING IKEV2
5.9.1 Introducing IKEv2
• IKE is a component of IPsec used for performing mutual authentication and establishing and
maintaining security associations (SAs).
• IKEv2 is a major redesign of IKEv1. However, for security reasons, version 2 of IKE does not
interoperate with version 1, although both can be used at the same time.
• IKEv2 preserves most of the features of the original IKE, including identity hiding, perfect forward
secrecy, two phases, and cryptographic negotiation, while greatly redesigning the protocol for
efficiency, security, robustness, and flexibility.
• IKEv2 provides a number of benefits of its predecessor IKEv1, such as ability for asymmetric
authentication methods, greater protection over IKE DoS attacks, interoperability between vendors for
DPD/NAT-T, and less overhead and messages during SA establishment.
IKEv2 reduces the complexity in IPsec establishment between different VPN products.
• IKEv2 has a faster rekey time. IKEv2 rekey for SA offers improved security performance and
decreases the number of packets lost in transition. Due to the redefinition of certain IKEv1
mechanisms in IKEv2, fewer packets are lost and duplicated in IKEv2. Therefore, there is less need to
rekey SAs.
• IKEv2 requires less bandwidth than IKEv1.

5.9.2 IKEv2 Configuration Steps
To configure and use IKEv2, the following is required:

• Step1. Create an IPsec protected tunnel, which refers to an IPsec profile configured for IKEv2.
Refer to 5.7.1 Protecting a Tunnel with an IPsec Profile.
• Step2. Create and configure the IPsec profile.

Refer to 5.7.2 Configuring an IPsec Profile.
• Step3. In the IPsec profile, configure one or more transform sets.

Refer to 5.7.2.2 Setting one or more Transform Sets.
• Step4. In the IPsec profile, configure an IKEv2 profile.

Refer to 5.9.4 Configuring an IKEv2 profile.
The following is optional but strongly recommended:

• Step5. Configure DPD.
Refer to 5.9.3 IKEv2 Dead Peer Detection.
The following is optional:

• Step6. Configure one or more IKEv2 proposal(s).
Refer to 5.9.5 Configuring an IKEv2 Proposal.
• Step7. Configure an IKEv2 policy, which refers to at least 1 IKEv2 proposal.

Refer to 5.9.6 Configuring an IKEv2 Policy.
If the IKEv2 policy and IKEv2 proposal are not configured by the user, the Smart Defaults will be used.
Refer to 5.9.8 Smart Defaults for further details.

5.9.3 IKEv2 Dead Peer Detection
It is strongly recommended to enable IKEv2 Dead Peer Detection or DPD.
• As specified in RFC5996 and its successors, even without DPD being activated, all IKEv2
communication is acknowledged. If replies to requests do not arrive in time, retransmissions will be
sent following an exponential-back-off mechanism. After a number of sequential unacknowledged
retransmissions, IKEv2 will deem the peer to be down, and remove all associated IPSEC SA's.
• However, even though loss of connectivity with a peer will be detected when replies do not arrive in
time, without DPD configured, it can take a long time before any peer decides to communicate to the
other side. As a result, a loss of connectivity with the peer might only be detected long after it became
unreachable (possibly hindering back-up mechanisms, new set-up attempts, ..).
• To ensure regularly polling the status of the peer, IKEv2 Dead Peer Detection should be configured.
DPD can be configured on configure level.
• Summarized, DPD allows to:
o Ensure regularly refreshing the peer's liveliness state.
o Overrule the slower exponential back-off mechanism by a configurable fixed retransmit-time
behavior (starting from the retransmission for which the fixed retransmit behavior would send
out the retransmission faster).
• For DPD, two timers can be configured:
o The trigger timer or DPD R-U-THERE interval: this is the inactivity period during which no
traffic has been detected coming from the IKEv2 peer or from the corresponding tunnel. If this
timer expires, a keepalive message is sent to the remote peer to check if it is still alive.
o The retry timer or DPD Retry Interval: this is the number of seconds between keepalive retries
if the previous keepalive message fails.
A total of 5 retries is sent before the connection with the remote peer is considered as lost.

Configuring DPD
• DPD is not enabled by default; to enable it, use the following command:
CLI(configure)> crypto ikev2 dpd <10-3600> <2-60> {periodic | on-demand}
o The first parameter is the trigger timer or DPD R-U-THERE interval, expressed in seconds.
Any value between 10 and 3600 can be set.
o The second one is the retry timer or DPD Retry Interval, expressed in seconds.
Any value between 2 and 60 can be set.
o periodic. When adding this keyword, DPD queries are sent at regular intervals, even if traffic
was detected on the tunnel.
o on-demand. When adding this keyword, DPD queries are sent only as needed.
• Use the no form of the command to disable DPD:

CLI(configure)> no crypto ikev2 dpd

5.9.4 Configuring an IKEv2 profile
• An IKEv2 profile is a repository of the non-negotiable parameters of an IKEv2 security association

(SA), such as local and remote identities, authentication methods and the services that will be
available to the authenticated peers that match the profile.
• To configure an IKEv2 profile, use the following command in global configuration mode:
CLI(configure)> crypto ikev2 profile <profile-name>
CLI(config-ikev2-profile)>
To delete the profile, use the no form of this command:

CLI(configure)> no crypto ikev2 profile <profile-name>
• An IKEv2 profile has following characteristics:

o It must be attached to an IPsec profile, on both IKEv2 peers.
o It must have a local and a remote authentication method.
o The following rules apply to match statements:
 An IKEv2 profile must contain a match identity; otherwise, the profile is considered
incomplete and is not used. An IKEv2 profile can have more than one match
identity statements.
 An IKEv2 profile can only have one single match fvrf statement.
 When a profile is selected, multiple match statements of the same type are logically
OR’ed (i.e. a logical OR function is applied), and multiple match statements of different
types are logically AND’ed (i.e. a logical AND function is applied).
The match identity statements are considered to be the same type of statements
and are OR’ed.
 Configuration of overlapping profiles is considered a misconfiguration. In the case of
multiple profile matches, no profile is selected.
Local and a remote authentication method
• Use the following command to set the local authentication method to using a pre-shared Key:
CLI(config-ikev2-profile)> authentication local pre-share
The key itself can be set with the crypto ikev2 keyring command, described further down.
• Use the following command to set the local authentication method to using an RSA (Rivest-Shamir-
Adleman) Signature:
CLI(config-ikev2-profile)> authentication local rsa-sig
• Use the following command to set the remote authentication method to pre-shared Key:
CLI(config-ikev2-profile)> authentication remote pre-share
• Use the following command to set the remote authentication method to RSA (Rivest-Shamir-Adle-
man) Signature:
CLI(config-ikev2-profile)> authentication remote rsa-sig

IKEv2 Profile Matching
• Use the following command to match the IKEv2 profile on a local address:
CLI(config-ikev2-profile)> match address local <ip-address>
• Use the following command to match the IKEv2 profile on FVRF (Front-Door VPN Routing and For-
warding - FVRF or outside VRF, the VRF that contains the encrypted traffic):
CLI(config-ikev2-profile)> match fvrf { any | <fvrf-name> }
o any. Use this argument to match any FVRF.

o <fvrf-name>. Use this argument to match a specific FVRF.
• Use the following command to match the IKEv2 Profile on a peer that identifies using a fully qualified
email string:
CLI(config-ikev2-profile)> match identity remote email <email>
• Use the following command to match the IKEv2 Profile on a peer that identifies using a fully qualified
domain name string (FQDN):
CLI(config-ikev2-profile)> match identity remote fqdn <string>
o <string> is the FQDN name, in the form of <name>.<domain>.<extension>,

for example host.example.com.
Additional settings
• Use the following command to specify an IKEv2 keyring with which the OneOS device authenticates
itself, in case the local authentication method has been set to using a pre-shared Key:
CLI(config-ikev2-profile)> keyring local <keyring-name>
o <keyring-name>. The device authenticates with pre-share <keyring-name>.
• Use the following command to specify the local IKE identity to use for the negotiation with the remote
device:
CLI(config-ikev2-profile)> identity local { email <email>|
fqdn <fqdn-string> }
o email <email>. In this case, the local IKE identity is a fully qualified email string.
o fqdn <fqdn-string>. In this case, the local IKE identity is fully qualified domain name
string.
• Use the following command to set the lifetime for an IKEv2 SA:
CLI(config-ikev2-profile)> lifetime <lifetime>
o <lifetime>. This is the lifetime, expressed in seconds; it ranges from 120 to 86400
seconds.
To return to the default value, use the no form of the command:
CLI(config-ikev2-profile)> no lifetime

• IKEv2 has a default authorization policy to allow receiving and applying configuration parameters,
such as IP addresses and routes, given that the following options are set in the IKEv2 profile:
CLI(config-ikev2-profile)> config-exchange request
CLI(config-ikev2-profile)> config-exchange set accept
CLI(config-ikev2-profile)> config-exchange set send
o request. This enables the configuration exchange request.

o set. This enables the configuration exchange request set options:
 accept. This accepts the configuration exchange request set.
 send. This enables the sending of the configuration exchange set.
• To specify the trustpoints that are used with the RSA signature authentication method, use the
following command:
CLI(config-ikev2-profile)> pki trustpoint <trustpoint>
o <trustpoint> is the name of the trustpoint.

To remove a trustpoint, use the no form of this command:
CLI(config-ikev2-profile)> no pki trustpoint <trustpoint>

5.9.5 Configuring an IKEv2 Proposal
• An IKEv2 proposal is a set of transforms used in the negotiation of IKEv2 SA‘s.

It allows configuration of one or more transforms for each transform type.
An IKEv2 proposal does not have any associated priority.
• An IKEv2 proposal is regarded as complete only when it has at least the following configured:
o an encryption algorithm,
o an integrity algorithm, and
o a Diffie-Hellman (DH) group.
• To use IKEv2 proposals in negotiation, they must be attached to IKEv2 policies.
• To configure an IKEv2 proposal, use the following command in global configuration mode:
CLI(configure)> crypto ikev2 proposal <proposal-name>
CLI(config-ikev2-proposal)>
Note that it is possible to configure more than 1 IKEv2 proposal.
• To delete the IKEv2 proposal, use the no form of this command:

CLI(configure)> no crypto ikev2 proposal <proposal-name>
Encryption algorithm
• Use the following command to set the encryption algorithm(s) for the proposal:
CLI(config-ikev2-proposal)> encryption <encryption>
o <encryption>. Possible values for the encryption are:

3des, aes-cbc-128, aes-cbc-192, aes-cbc-256, des.
Note that it is possible to configure more than 1 encryption algorithm.
Integrity algorithm
• Use the following command to set the integrity hash algorithm(s) for the proposal:
CLI(config-ikev2-proposal)> integrity <integrity>
o <integrity>. Possible values for the hash algorithm are:

md5, sha1, sha256, sha384, sha512.
Note that it is possible to configure more than 1 hash algorithm.
Diffie-Hellman (DH) Group
• Use the following command to set the Diffie-Hellman group(s) for the proposal:
CLI(config-ikev2-proposal)> group <dh-group(s)>
o <dh-group(s)>. The following groups can be set: 1, 14, 15, 16, 19, 2, 20, 24, 5.
Note that it is possible to configure more than 1 DH group.

Multiple transforms
• When multiple transforms are configured for a transform type, the order of priority is from left to right.
• A proposal with multiple transforms for each transform type translates to all possible combinations of
transforms. If only a subset of these combinations is required, then they must be configured as
individual proposals.
Example:
CLI(configure)> crypto ikev2 proposal proposal-1
CLI(config-ikev2-proposal)> encryption aes-cbc-128,aes-cbc-192
CLI(config-ikev2-proposal)> integrity sha1,sha256
CLI(config-ikev2-proposal)> group 14
The commands shown above translate to the following transform combinations:

aes-cbc-128, sha1, 14
aes-cbc-192, sha1, 14
aes-cbc-128, sha256, 14
aes-cbc-192, sha256, 14
To configure the first and last transform combinations individually, use the following commands:
CLI(config-ikev2-proposal)> encryption aes-cbc-128
CLI(config-ikev2-proposal)> integrity sha1
CLI(config-ikev2-proposal)> exit
CLI(config-ikev2-proposal)> encryption aes-cbc-192
CLI(config-ikev2-proposal)> integrity sha256

5.9.6 Configuring an IKEv2 Policy
• An IKEv2 policy contains the proposals that are used to negotiate the encryption, integrity,
Pseudorandom Function (PRF) algorithms and Diffie-Hellman (DH) group when the connection is
being initiated.
• An IKEv2 policy must contain at least one proposal to be considered as complete, and can have
several proposals and match statements.
• An IKEv2 policy can have several match statements, which are used as selection criteria to select a
policy for negotiation.
• A policy can have similar or different match statements. Match statements that are similar are logically
OR’ed (i.e. a logical OR function is applied) and match statements that are different are logically
AND’ed (i.e. a logical AND function is applied).
There is no precedence between match statements of different types. If there are policies with similar
match statements, the first policy configured is selected. If there are policies with overlapping match
statements, the policy with the best or most specific match is selected.
• A policy is matched as follows:
o If no IKEv2 policy is configured, the default policy is used for negotiating a SA that uses any
local address in a default VRF.
o If IKEv2 policies are configured, the policy with the best match is selected.
o If none of the configured policies matches, the initiation of the connection does not start.
• To configure an IKEv2 policy, use the following command in global configuration mode:
CLI(configure)> crypto ikev2 policy <policy-name>
CLI(config-ikev2-policy)>
o <policy-name> is the name of IKEv2 policy.

To delete a policy, use the no form of this command:
CLI(configure)> no crypto ikev2 policy <policy-name>
• To attach an IKEv2 proposal to an IKEv2 policy, use the following command:

CLI(config-ikev2-policy)> proposal <proposal-name>
o <proposal-name> is the name of the proposal to be used in the IKEv2 policy;

also refer to 5.9.5 Configuring an IKEv2 Proposal.
o Note that it is possible to attach more than one proposal to the IKEv2 policy.
• To configure match statements for the IKEv2 policy, use the following commands:
o To match a local IPv4 address, use the following command:
CLI(config-ikev2-policy)> match address local <ip-address>
 <ip-address> is a local IPv4 address to match.

o To match a specific or any fvrf, use the following command:
CLI(config-ikev2-policy)> match fvrf { any | <fvrf-name> }
 any. Use this argument to match any FVRF.

 <fvrf-name>. Use this argument to match a specific FVRF.

5.9.7 C o n fi g u r i n g a n I KE v 2 Ke yr i n g
• IKEv2 key rings are independent of IKEv1 key rings. The main differences are:
o IKEv2 key rings support symmetric and asymmetric pre-shared keys.
o IKEv2 key rings do not support Rivest, Shamir, and Adleman (RSA) public keys.
o IKEv2 key rings are specified in the IKEv2 profile and are not looked up, unlike IKEv1, where
keys are looked up on receiving MM1 (Main Mode 1 – Initial Contact) to negotiate the pre-
shared key authentication method. The authentication method is not negotiated in IKEv2.
IKEv2 key ring keys must be configured in the peer configuration (sub)mode that defines a peer sub-
block.
In the peer configuration (sub)mode, the peer and associated keys can be configured.
Note that an IKEv2 keyring can have multiple peer sub-blocks.
• To configure an IKEv2 keyring, first enter keyring configuration mode:

CLI(configure)> crypto ikev2 keyring <keyring-name>
CLI(config-ikev2-keyring)>
Then, with the peer command, enter peer configuration mode:

CLI(config-ikev2-keyring)> peer <peer-name>
CLI(config-ikev2-keyring-peer)>
o <peer-name>. This is the name of the peer sub-block.
• A peer sub-block contains a single symmetric or asymmetric key pair for a peer or peer group
identified by the IP address and related network mask, <mask>, in case of a peer group.
CLI(config-ikev2-keyring-peer)> address <address> [<mask>]
o <address> is the IP address of the remote peer.
• Use the following command to specify the pre-shared keys:

CLI(config-ikev2-keyring-peer)> pre-shared-key { local | remote }
<key> <level>
o Use the local or remote keywords to specify an asymmetric key:

 Add the local keyword to specify the signing key (152 bytes alphanumerical key string
/ 90 bytes to be encrypted alphanumerical key string).
 Add the remote keyword to specify the verifying key (152 bytes alphanumerical key
string / 90 bytes to be encrypted alphanumerical key string).
o <key> is the key itself. This must be entered as clear text, or as an encrypted string.
Depending on what is used, the <level> must be set accordingly.
o The <level> parameter determines the level and type of encryption that will be used to
display the password when running the show running-config command.
<level> can either be 0 or 4, depending on how the <key> is entered:
 0 means that the <key> is entered in plain text, and is to be encrypted.
 4 means that the <key> is already level 4 encrypted.
To disable the pre-shared key, use the no form of this command:
CLI(config-ikev2-keyring-peer)> no pre-shared-key
{ local | remote } <key>

• To delete an IKEv2 keyring, use the no form of the command:

CLI(configure)> no crypto ikev2 keyring <keyring-name>
• IKEv2 key rings are not associated with VPN routing and forwarding (VRF) during configuration.
The VRF of an IKEv2 key ring is the VRF of the IKEv2 profile that refers to the key ring.
• A single key ring can be specified in an IKEv2 profile, unlike an IKEv1 profile, which can specify
mul¬tiple key rings.
• A single key ring can be specified in more than one IKEv2 profile, if the same keys are shared across
peers matching different profiles.
5.9.8 Smart Defaults
A factory-default router has a default IKEv2 Policy and a default IKEv2 Proposal, each with its own default
settings; these are referred to as Smart Defaults.
5.9.8.1 Introducing Smart Defaults
• The OneOS device has something called Smart Defaults. This means that a factory-default router has
a default IKEv2 Policy and a default IKEv2 Proposal, each with its own default settings.
• Note that the default policy and proposal are not shown when running the show running-config
command.
• The factory default settings of the IKEv2 policy and IKEv2 proposal, on a factory-default device, are:
crypto ikev2 proposal default
encryption aes-cbc-256 aes-cbc-192 aes-cbc-128
integrity sha512 sha384 sha256 sha1 md5
group 5 2
crypto ikev2 policy default

match fvrf any
proposal default
Thanks to these default settings, valid configurations can be created without explicitly configuring
them.
• The factory-default settings of a Smart Default can be changed by the user.
• Smart Defaults can also be disabled or removed by the user. This is persistent after reboot, given that
the configuration was saved.
• The actual factory-default settings for a Smart Default are never lost: a Smart Default can be set back
to its factory-default settings with the procedures described next.

5.9.8.2 Changing the Settings of a Smart Default
• It is possible to override the factory-default settings of the Smart Default, to non-default.

• The following is an example for the IKEv2 proposal:
o With the following commands, the setting of the default IKEv2 proposal is changed: the
encryption has been changed to 3des:
CLI> conf t
CLI(configure)>
CLI(configure)> crypto ikev2 proposal default
CLI(config-ikev2-proposal)> encryption 3des
CLI(configure)> exit
CLI>
Note that, when entering the crypto ikev2 proposal default command, the following
warning will be shown:
Warning: This will overwrite the smart default! Type exit to abort
IKEv2 proposal MUST have at least an encryption algorithm, an integrity
algorithm and a dh group configured
o The Smart Default is now shown when running the show running-config command, with
the user-updated settings:
CLI> show running-config
…
encryption 3des
group 5 2
…
Note that it will also be shown with the factory-default settings for the unchanged nodes.
5.9.8.3 Removing a Smart Default
• It is possible to remove a Smart Default. This applies to a Smart Default that still had factory-default
settings, as well as to a Smart Default that was updated by the user.
o With the following commands, the default IKEv2 proposal is removed:
CLI> conf t
CLI(configure)>
CLI(configure)> no crypto ikev2 proposal default
CLI>
o The fact that the default IKEv2 proposal has been removed, will show up when running the
show running-config command:
…
no crypto ikev2 proposal default
…

5.9.8.4 Re-enabling a Smart Default
• If a Smart Default has been removed, it can simply be re-enabled by entering the matching CLI
command with an empty configuration.
o To re-enable the default IKEv2 proposal after it had been removed, use the following
commands:
CLI> conf t
CLI>
Note that, when entering the crypto ikev2 proposal default command, the following warning
will be shown:
Recreated the smart default
Warning: This will overwrite the smart default! Type exit to abort
IKEv2 proposal MUST have at least an encryption algorithm, an integrity
algorithm and a dh group configured
The re-enabled default IKEv2 proposal does not show up in the show running-config, since it is
back to full factory default.
5.9.8.5 Reverting from a User Updated Smart Default to the Factory-Default Setting
• To revert back from a user-updated Smart Default to a factory default, proceed as follows:
o First remove the user-updated Smart Default,
o then recreate it, so that the default settings come back.
o Starting from a user-updated Smart Default, it will be shown when running the
show running-config command:
…
encryption 3des
group 5 2
…
o To remove the non-default IKEv2 proposal and re-enable the default one, use the following
commands:
CLI> conf t
CLI(configure)> no crypto ikev2 proposal default !removes the non-default
CLI(configure)> crypto ikev2 proposal default !reenables the factory
default
CLI>

5.9.9 IKEv2 NAT Traversal
• IKEv2 NAT Traversal functions as described in RFC5996 - Internet Key Exchange Protocol Version 2
(IKEv2).
5.9.10 IKEv2 Show Commands
• The following command shows the configured IKEv2 SA’s:

CLI> show crypto ikev2 sa [detailed]
Adding the detailed option provides extra information; the following is an example:
CLI> show crypto ikev2 sa detailed
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status

9801 9.1.1.9/4500 168.136.2.1/4500 (none)/(none) READY
Encr: AES-CBC, keysize: 256, Hash: sha512, DH Grp: 5, Auth sign: pre-share, Auth verify:
pre-share
Life/Active Time: 14700/127 sec
CE id: 0
Status Description: Negotiation done
Local spi: 56187467882C8D2C Remote spi: 84F9031B92964B24
Local id: oneaccess.com
Remote id: technet.com
Local req msg id: 1 Remote reg msg id: 0
Local next msg id: 2 Remote next msg id: 1
Local req queued: 0 Remote req queued: 0
Local window: 1 Remote window: 1
DPD configured for 60 seconds, retry 15
NAT-T is detected inside
Cisco Trust Security SGT is disabled
Initiator of SA : No
DNS Primary: 2.2.2.4
DNS Secondary: 6.6.6.8
Remote subnets:
16.16.16.15 255.255.255.255
IPv6 Crypto IKEv2 SA

• The following command shows the active IKEv2sessions:

CLI> show crypto ikev2 session [detailed]
Adding the detailed option provides extra information; the following is an example:
CLI> show crypto ikev2 session detailed
IPv4 Crypto IKEv2 Session
Status: UP-ACTIVE, IKE count: 1, CHILD count: 1
Tunnel-id Local Remote fvrf/ivrf Status

9801 4.0.0.1/4500 192.168.1.1/4500 (none)/(none) READY
Encr: AES-CBC, keysize: 256, Hash: sha512, DH Grp: 5, Auth sign: pre-share, Auth verify:
pre-share
Life/Remaining/Active Time: 14700/14557/143 sec
CE id: 0, MIB-id: 0
Status Description: Negotiation done
Local spi: 56187467882C8D2C Remote spi: 84F9031B92964B24
Local id: oneaccess.com
Remote id: cisco.com
Local req msg id: 1 Remote reg msg id: 0
Local next msg id: 2 Remote next msg id: 1
Local req queued: 0 Remote req queued: 0
Local window: 1 Remote window: 1
DPD configured for 60 seconds, retry 15
NAT-T is detected inside
Cisco Trust Security SGT is disabled
DNS Primary: 3.3.3.1
DNS Secondary: 4.4.4.2
Remote subnets:
11.11.11.10 255.255.255.255
Child sa: local selector 4.0.0.1/0 - 4.0.0.1/65535
remote selector 192.168.1.1/0 - 192.168.1.1/65535
ESP spi in/out: 0x6F298869/0xF9077A0A
CPI in/out: 0x0/0x0
AH spi in/out: 0x0/0x0
Encr: AES-CBC, keysize: 256, esp_hmac: SHA96
ah_hmac: None, comp: IPCOMP_NONE, mode transport
IPv6 Crypto IKEv2 Session
• The following command shows IKEv2 statistics:

CLI> show crypto ikev2 stats
Example:
--------------------------------------------------------------------------------
Crypto IKEv2 SA Statistics
--------------------------------------------------------------------------------
System Resource Limit: 0 Max IKEv2 SAs: 0 Max in nego: 1000
Total IKEv2 SA Count: 1 active: 1 negotiating: 0
Incoming IKEv2 Requests: 1384 accepted: 1384 rejected: 0
Outgoing IKEv2 Requests: 2764 accepted: 2764 rejected: 0
Rejected IKEv2 Requests: 0 rsrc low: 0 SA limit: 0
Incoming IKEV2 Cookie Challenged Requests: 0
accepted: 0 rejected: 0 rejected no cookie: 0
IKEv2 Rekeyed SAs: 646
local rekey requests: 0 remote rekey requests: 646 rekeyed SAs active: 0
IKEv2 Child SAs: 1
local setup requests: 47 remote setup requests: 0 successful setups: 0
local delete requests: 0 remote delete requests: 46
local rekey requests: 0
IKEv2 Discards: 0

5.10 CALL ADMISSION CONTROL FOR IPSEC SA’S
Configuration
• Call Admission Control or CAC allows limiting the number of simultaneous IPsec SAs that are
established at a time.
Before the initiation of a new SA request, the CAC checks whether the number of active SA’s plus the
number of SA’s that need to be negotiated exceeds the configured limit.
• Only new SA requests can be denied; i.e. if a SA already exists between two peers, it is not impacted
by the CAC.
• To configure the limit, use the following command:
CLI(configure)> crypto call admission limit ipsec sa <salimit>
o <salimit> varies between 20 and 450, depending on the device.

• When a new SA request is rejected by the CAC, a syslog message can be generated with the source
and destination IP address of the SA request; use the following command:
CLI(configure)> event filter add ipsec cac all syslog
• Take into account that each IPsec tunnel has two IPsec SAs.
Statistics
• Use the following command to display CAC related statistics:

CLI> show crypto call admission statistics
This command shows:

o Maximum SA’s supported on the product
o Limit set by the CAC
o SA count (Total/Active/negotiating)
o Incoming IPSec Requests (Total/Accepted/Rejected by SA limit)
o Outgoing IPSec Requests (Total/Accepted/Rejected by SA limit)
The following is an example output:

CLI> show crypto call admission statistics
---------------------------------------------------------------------
Crypto Call Admission Control Statistics
---------------------------------------------------------------------
Max IPSEC SAs supported by product: 20
Max IPSEC SAs limit set by CAC : 0 (unlimited)
Total IPSEC SA count : 0 active: 0 negotiating:0
Outgoing IPSEC Requests : 0 accepted by CAC: 0 rejected by CAC:0
Incoming IPSEC Requests : 0 accepted by CAC: 0 rejected by CAC:0
• To clear the statistics, use the following command:

CLI> clear crypto call admission statistics

5.11 FRAGMENTATION AND IPSEC - RECOMMENDED SETTINGS
• When used in conjunction with IPsec, a number of configuration parameters influence the
fragmentation behavior.
• Also refer to 5.1 Fragmentation and tunnels for some general remarks about tunnels and
fragmentation.
5.11.1 Pre-Fragmentation
• Related commands:
o tunnel path-mtu-discovery;
 refer to section 3.2.5 Setting Path MTU Discovery of the Basic IP User Guide.
o crypto ipsec df-bit;
 refer to 5.11.3 Configuration Commands.
o crypto ipsec fragmentation before-encryption;
• Depending on the topology and configuration, the IPsec encapsulation overhead may vary.
One approach is to configure a tunnel MTU that is able to handle all scenarios, but alternatively, it is
possible to dynamically detect MTU issues and adapt the tunnel MTU to these values.
This requires the DF-bit to be set on the outer IP header – if somewhere downstream an MTU issue is
discovered, an ICMP error message will be sent back to the tunnel source.
In case path MTU discovery is enabled, the OneOS6 router will dynamically lower the tunnel MTU.
• This solution works with both crypto ipsec df-bit clear and crypto ipsec df-bit copy.
5.11.2 Post-Fragmentation
• Related commands:
o crypto ipsec df-bit;
o crypto ipsec fragmentation after-encryption;
• When choosing post-fragmentation behavior, it is important that the DF-bits are not copied from the
original packet to the outer IP header, so use the crypto ipsec df-bit clear command to
ensure that fragmentation is allowed after a packet has been encapsulated (and encrypted).
• OneOS currently does not take path MTU discovery information into account when configured for
post-fragmentation.

5.11.3 Configuration Commands
• The crypto ipsec fragmentation command allows the router to predetermine the encapsulated
packet size from information available in transform sets, which are configured as part of the IPsec SA.
• To configure the fragmentation of near-MTU sized packets , use the following command in global
configuration mode:
CLI(configure)> crypto ipsec fragmentation { before-encryption |
after-encryption }
o before-encryption. In this case, fragmentation of large packets is done before the IPsec
encapsulation; this is the default setting.
o after-encryption. In this case, fragmentation of large packets is done after the IPsec
encapsulation.
• To disable a manually configured command, use the no form of the command:
CLI(configure)> no crypto ipsec fragmentation {before-encryption |
after-encryption}
• IP fragmentation may be prevented due to the DF bit in the IP header. To modify the DF bit in the
encapsulating IP header for a specific interface, use the following command in interface configuration
mode:
CLI(config-if)> crypto ipsec df-bit { clear | set | copy }
o clear. In this case, the DF bit of the outer IP header is cleared.

o set. In this case, the DF bit of the outer IP header is set.
o copy. In this case, the DF bit is taken from the inner IP header and copied into the outer IP
header; this is the default setting.
Note that:
o This command is not applicable for IPsec tunnels in transport mode, in case of crypto maps on
a physical interface.
o This command is not taken into account when tunnel path-mtu-discovery is enabled.
o When fragmentation after-encryption is configured, explicitly clearing the DF-bit is
recommended.

5.12 CONFIGURING CERTIFICATES
Also refer to section 2.27 Certificates Management of the Admin User Guide for further details about
certificates.
Configuring a Trustpoint
• A trustpoint can be a self-signed root certificate authority (CA) or a subordinate CA, and encapsulates
the certificate revocation check rules used to verify the validity of the certificate used to set up a
secure connection.
• To configure a PKI trustpoint, and enter in trust point configuration mode, use the following command:
CLI(configure)> crypto pki trustpoint <newtrustpoint>
CLI(trustpoint)>
o <newtrustpoint> is the name of the trust point.
To remove a trustpoint and delete all identity information and certificates associated with the trust-
point, use the no form of the command:
CLI(configure)> no crypto pki trustpoint <newtrustpoint>
Certificate chain
• To enter the certificate chain configuration mode, use the following command in global configuration
mode:
CLI(configure)> crypto pki certificate chain <trustpoint>
CLI(cert-chain)>
o <trustpoint> is the name of the certificate authority (CA). The name must match the one
that was declared for the CA using the crypto pki trustpoint command.
• Use the following command to manually add one or more certificates:

CLI(cert-chain)> certificate <serialnum>
o <serialnum> is the serial number of the certificate.
Use the no form of the command to delete a certificate:

CLI(cert-chain)> no certificate <serialnum>

5.13 IPSEC SNMP TRAPS
• In order to send SNMP traps for every IPsec log message, use the following command:
CLI(configure)> [no] snmp traps ipsec
• In order to send SNMP traps related to the IKE protocol, use the following command:
CLI(configure)> [no] snmp traps isakmp
5.14 IPSEC STATISTICS
• At any stage of the configuration, information about IPsec can be displayed with the following
command:
CLI> show crypto config
• To display the list of configured crypto maps and their configuration, or display the configuration of a
specific crypto map, or the configuration of a crypto map attached to an interface, use the following
command:
CLI> show crypto map [name <name> | interface <type> <unit>]
• To display the statistics on the IPsec related counters, use the following command line:
CLI> show crypto [ah | esp | ipcomp | ipip]
• To display the IPsec SAs currently configured, use the following command:
CLI> show crypto ipsec sa [detail]
• To display the IPSEC SADB identity tree, use the following command:
CLI> show crypto ipsec sa identity [detail]
• To display the IPsec SAs currently configured on a specific interface, use the following command:
CLI> show crypto ipsec sa [interface <type> <unit>]
• To display the IPsec SA table for a specific crypto map, use the following command:
CLI> show crypto ipsec sa map <mapName>
• To display the list of configured transform-sets, use the following command:

CLI> show crypto ipsec transform-set

• To display ISAKMP preshared keys, use the following command:

CLI> show crypto isakmp key
• To display the ISAKMP policies, use the following command:

CLI> show crypto isakmp policy
• To display the ISAKMP profiles, use the following command:

CLI> show crypto isakmp profile
• To display ISAKMP profiles by name, use the following command:

CLI> show crypto isakmp profile tag <name>
• To display ISAKMP profiles by VRF name , use the following command:

CLI> show crypto isakmp profile vrf <name>
• To display ISAKMP security associations, use the following command:

CLI> show crypto isakmp sa [vrf <vrf-name>]
• To display ISAKMP counters, use the following command:

CLI> show crypto isakmp sa count
• To display ISAKMP SA details, use the following command:

CLI> show crypto isakmp sa detail [vrf <vrf-name>]
• To display ISAKMP statistics, use the following command:

CLI> show crypto isakmp statistics

• To clear all crypto counters, use the following command:

CLI> clear crypto counters
• To clear IKEv1 commands, use the following command:

CLI> clear crypto isakmp
• To clear IKEv1 commands related to a specific destination, use the following command:
CLI> clear crypto isakmp destination <IPv4 address>
• To clear IKEv1 commands related to a specific tunnel interface, use the following command:
CLI> clear crypto isakmp interface tunnel <0-65535>
• To clear all ISAKMP statistics, use the following command:

CLI> clear crypto isakmp statistics
• To clear the IPsec SAs, use the following command:

CLI> clear crypto sa
• To clear the IPsec SA counters, use the following command:

CLI> clear crypto sa counters
• To clear encapsulation-related counters, use the following command:

CLI> clear crypto { ah | ipip | esp | ipcomp }
• To clear the configured IKEv2 SA’s, use the following command:

CLI> clear crypto ikev2 sa
• To clear the IKEv2 statistics, use the following command:

CLI> clear crypto ikev2 stats

5.15 IPSEC DEBUG COMMANDS
• To debug payload packet processing, use the following command:

CLI> [no] debug crypto ipsec [core | crypto | data | sa | spd]
• To debug ISAKMP issues, use the following command:

CLI> [no] debug crypto isakmp [config | crypto | exchange | keepalive
| message | misc | nat-t | negotiation | policy | sa | timer | transport]
• To specify the amount of ISAKMP debug information available (default 20) , use the following
command:
CLI> debug crypto isakmp level <10-90>
• To debug IKEv2 issues, use the following command:

CLI> debug crypto ikev2 [level] [emergency | alert | error |
warning | notice | informational | debug]
To stop the debugging, use the following command:

CLI> no debug crypto ikev2
• To debug crypto pki issues, use the following command:

CLI> debug crypto pki [1 | 2 | 3 | 4]
To stop the debugging, use the following command:

CLI> no debug crypto pki

5.16 IPSEC CONFIGURATION EXAMPLES
5.16.1 Configuration Example - IKEv1 Manual Crypto Entries
• The following example illustrates how to configure an IPsec tunnel with IKEv1 crypto maps and
manually configured keys.
Router A Router B
10.1.1.0/24 10.1.2.0/24
212.199.8.1 212.199.8.2
Router A Configuration:
configure terminal
ip access-list extended sub1
permit ip 10.1.1.0 0.0.0.255 10.1.0.0 0.0.255.255
exit
crypto ipsec transform-set esp-3des-sha
esp-3des esp-sha-hmac
exit
crypto map ipsec-manual client 1

! Defines a SA with manually configured keys for traffic that matches
! the ACL sub1
match address sub1
set transform-set esp-3des-sha
! Warning: next 2 times 3 lines are 2 times one instruction!
set security-association inbound esp 0x195831
89ef6ee47969b514d0bbc77d99d3f69089a0fc3778474310
61ac3e5e8a60bec99f54769b36264d0a7970124f
set security-association outbound esp 0x195832
fea63c1bae038fa13a931507a293128ea86f03ebfc43faab
181a435f80900737b964ad64814fab7f69ccaa69
exit
interface ethernet 0
ip address 10.1.1.1 255.255.255.0
exit
interface tunnel 1
! Apply the crypto map to the tunnel interface
ip unnumbered atm 0.1
tunnel source atm 0.1
tunnel destination 212.199.8.2
crypto map client
exit
interface atm 0.1
ip address 212.199.8.1 255.255.255.0
exit
ip route 10.1.0.0 255.255.0.0 tunnel 1

Router B Configuration:
configure terminal
permit ip 10.1.2.0 0.0.0.255 10.1.0.0 0.0.255.255
exit
exit
crypto map ipsec-manual client 1
match address sub1
set security-association inbound esp 0x195832
fea63c1bae038fa13a931507a293128ea86f03ebfc43faab
181a435f80900737b964ad64814fab7f69ccaa69
set security-association outbound esp 0x195831
89ef6ee47969b514d0bbc77d99d3f69089a0fc3778474310
61ac3e5e8a60bec99f54769b36264d0a7970124f
exit
ip address 10.1.2.1 255.255.255.0
exit
interface tunnel 1
ip unnumbered atm 0.1
tunnel source atm 0.1
crypto map client
exit
interface atm 0.1
ip address 212.199.8.2 255.255.255.0
exit
ip route 10.1.0.0 255.255.0.0 tunnel 1

5.16.2 C o n fi g u r a ti o n Ex a m p l e - I KE v 1 w i th a s ta n d a r d I S AKM P Cr yp t o M a p
Router A Router B
10.1.1.0/24 10.1.2.0/24
212.199.8.1 212.199.8.2
• Both routers use hardware encryption.

• Router A is the client, using a static CMAP.
• Router B is the server, using a dynamic CMAP.
• Authentication is done with pre-shared-keys.
• IKEv1 SA is rekeyed within 1000 seconds.
• IPSEC SA is rekeyed within 500 seconds.
• Keepalive is periodically sent every 30 seconds.
Router A Configuration
configure terminal
hostname Client
ip access-list extended acl_cmap
permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
exit
crypto engine enable
crypto isakmp keepalive 30 3 periodic
crypto isakmp policy 1
encryption 3des
hash sha256
group 5
lifetime 1000
exit
crypto isakmp peer address 212.199.8.2
set aggressive-mode password oneaccess
exit
esp-aes-256 esp-sha-hmac
exit
crypto map ipsec-isakmp cmap_isakmp 1
match address acl_cmap
set peer 212.199.8.2
set pfs group2
set security-association lifetime kilobytes 5000000
set security-association lifetime seconds 500
exit
interface gigabitethernet 0/0
crypto map cmap_isakmp
ip address 212.199.8.1 255.255.255.0
exit
ip address 10.1.1.1 255.255.255.0
exit
ip route 10.1.2.0 255.255.255.0 212.199.8.2
end

Router B Configuration
configure terminal
hostname server
ip access-list extended acl_cmap
permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
exit
encryption 3des
hash sha256
group 5
exit
crypto isakmp peer address 0.0.0.0 0.0.0.0
set aggressive-mode password oneaccess
exit
esp-aes-256 esp-sha-hmac
exit
crypto dynamic temp_dyn
match address acl_cmap
set pfs group2
exit
crypto map dynamic cmap_dyn 1 temp_dyn
crypto map cmap_dyn
ip address 212.199.8.2 255.255.255.0
exit
ip address 10.1.2.2 255.255.255.0
exit
ip route 10.1.1.0 255.255.255.0 212.199.8.1
end

5.16.3 Configuration Example - Client-Server case
• The following example illustrates how to configure a client –server IPsec tunnel with IKEv1 crypto
maps and preshared keys.
Client Server
10.1.3.0/24 10.1.1.0/24
212.199.8.2 212.199.8.1
Client Configuration:
configure terminal
permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255
exit
exit
crypto isakmp key secretpassword address 212.199.8.1
encryption 3des
hash md5
lifetime 20000
group 5
exit
crypto map ipsec-isakmp isakmp_client 1
match address sub1
set peer 212.199.8.1
set pfs group2
exit
ip address 10.1.2.1 255.255.255.0
exit
interface atm 0.1
ip address 212.199.8.2 255.255.255.0
crypto map isakmp_client
exit
ip route 10.1.2.0 255.255.0.0 212.199.8.1

Server Configuration:
configure terminal
ip access-list standard sub1
! only match what comes from/goes to the LAN
permit 10.1.1.0 0.0.0.255
exit
exit
crypto isakmp key secretpassword address 0.0.0.0 0.0.0.0
encryption 3des-cbc
hash md5
lifetime 20000
group 5
exit
crypto dynamic dyn
! Crypto map template
match address sub1
set pfs group2
exit
! Creation of a policy entry
crypto map dynamic isakmp_server 1 dyn
ip address 10.1.1.1 255.255.255.0
exit
interface atm 0.1
ip address 212.199.8.1 255.255.255.0
crypto map isakmp_server
exit
ip route 0.0.0.0 255.255.255.255 atm 0.1

5.16.4 Configuration Example1 - IKEv1 IPsec profile
• The following example illustrates how to configure a client –server IPsec tunnel with an IKEv1 IPsec
profile and certificates.
ip access-list standard pc
permit 172.31.100.0 0.0.0.255
exit

exit
crypto isakmp keepalive

crypto isakmp identity hostname

authentication rsa-sig
encryption 3des-cbc
exit
crypto isakmp profile myProfile

self-identity hostname
match certificate myCertmap
exit
crypto pki certificate map myCertmap 1

subject-name co O=OneAccess
subject-name co C=BE
exit
crypto dynamic mydyn

match address pc
set isakmp-profile myProfile
exit
crypto map dynamic mymap 10 mydyn

ip address 172.31.100.1 255.255.255.0
exit

ip address 192.168.1.1 255.255.255.0
crypto map mymap
exit

5.16.5 Configuration Example2 - IKEv1 IPsec profile
Router A Router B
10.1.1.0/24 10.1.2.0/24
212.199.8.1 212.199.8.2

• IPSEC SA is rekeyed within 500 seconds.
• Keepalive is periodically sent every 30 seconds.
• IKEv1 uses tunnel mode ipsec ipv4.
configure terminal
hostname Client
crypto keyring ikev1keyring
pre-shared-key address 212.199.8.2 key presharedkey
exit
encryption 3des
hash sha256
group 5
lifetime 1000
exit
crypto isakmp profile isakmpprofile
initiate mode aggressive
keepalive 30 retry 3
keyring ikev1keyring
exit
exit
crypto ipsec profile ipsecprofile
set security-association lifetime kilobytes disable
set isakmp-profile isakmpprofile
exit
ip address 212.199.8.1 255.255.255.0
exit
ip address 10.1.1.1 255.255.255.0
exit
interface Tunnel 1
ip address 5.0.0.1 255.255.255.0
tunnel mode ipsec ipv4
tunnel source 212.199.8.1
tunnel protection ipsec profile ipsecprofile
exit
ip route 10.1.2.0 255.255.255.0 Tunnel 1
end

configure terminal
hostname server
crypto keyring ikev1keyring
pre-shared-key address 212.199.8.1 key presharedkey
exit
encryption 3des
hash sha256
group 5
exit
crypto isakmp profile isakmpprofile
keyring ikev1keyring
exit
exit
set isakmp-profile isakmpprofile
responder-only
exit
ip address 212.199.8.2 255.255.255.0
exit
ip address 10.1.2.2 255.255.255.0
exit
interface Tunnel 1
ip address 5.0.0.2 255.255.255.0
tunnel mode ipsec ipv4
exit
ip route 10.1.1.0 255.255.255.0 Tunnel 1
end

5.16.6 Configuration Example - Easy VPN Client

encryption 3des-cbc
exit
crypto isakmp keepalive 60 20
crypto ipsec client ezvpn TEST

peer 172.31.124.229
group cisco key ciscopassword
username Brian password Adams
connect auto
exit

ip address 172.31.124.233 255.255.255.248
crypto ipsec client ezvpn TEST outside
exit

ip address 172.31.124.249 255.255.255.248
crypto ipsec client ezvpn TEST inside
exit

exit

exit

ip address 172.31.96.98 255.255.255.192
exit
ip address 4.4.4.4 255.255.255.255
exit
ip route 0.0.0.0 0.0.0.0 172.31.124.235

5.16.7 Configuration Example - Easy VPN Server
DHCP pool
FE. 1/0 192.168.21.1/24
Easy VPN tunnel 192.168.16.2/24
FE. 0/0: 192.168.20.1 /24
FE. 0/3: 10.0.28.13/21
Network
Easy VPN 192.168.16.100 Easy VPN
Client Server
RADIUS
DNS WINS Server
Servers Servers 10.0.26.40
• Easy VPN clients get their IP address from the pool in the range 192.168.21.1/24. They also get the
MyACL Access Control List that says that all traffic destined to 192.168.20.0/24 must go to the tunnel
(and all other traffics not). All this is added to the clients' routing table.
license activate ezvpnserver

!
!list of Easy VPN client users
username user1 password pwd1 0
!DHCP addresses pool for Easy VPN client users

ip local pool MyPool 192.168.21.1 192.168.21.254
!access list on Easy VPN client group

ip access-list extended MyACL
permit ip 0.0.0.0 0.0.0.0 192.168.20.0 0.0.0.255
exit
!IPsec material configuration

crypto ipsec transform-set MyTrans
exit
encryption 3des-cbc
exit
!Easy VPN client group MODE-CFG configuration

crypto isakmp client configuration group MYGROUP
pool MyPool
key MyPSK
netmask 255.255.255.0
dns 8.8.8.8 8.8.8.9
wins 10.0.24.33 10.0.24.34
domain mydomain.net
split-dns mycompany.com
acl MyACL
save-password
exit
!crypto map configuration using template and profile

crypto isakmp profile MyProf
self-identity address
client authentication list MyList
exit
crypto dynamic MyDyn
set transform-set MyTrans
set isakmp-profile MyProf

exit
crypto map dynamic EZVPNSERVER 10 MyDyn

ip address 192.168.20.1 255.255.255.0
exit
ip address 10.0.28.13 255.255.248.0
exit
!attaching crypto map to uplink interface

ip address 192.168.16.2 255.255.255.0
crypto map EZVPNSERVER
exit
ip address 192.168.20.5 255.255.255.255
exit
ip route 0.0.0.0 0.0.0.0 192.168.16.100
!Easy VPN client users authentication configuration

radius-server 10.0.26.40 Hello clear-text 1812
aaa authentication login MyList radius
aaa authentication login MyList local

5.16.8 Configuration Example - IKEv2
Router A Router B
10.1.1.0/24 10.1.2.0/24
212.199.8.1 212.199.8.2

• Both routers use the Smart Defaults (IKEv2 Proposal & IKEv2 Policy).
• IPSEC SA’s are rekeyed within 500 seconds.
• DPD is periodically sent every 30 seconds.
• IKEv2 over a GRE tunnel in transport mode.
configure terminal
hostname Client
crypto ikev2 dpd 30 10 periodic
crypto ikev2 keyring ikev2keyring
peer peername
pre-shared-key local client
pre-shared-key remote server
address 212.199.8.2
exit
exit
crypto ikev2 profile ikev2profile
match identity remote fqdn fqdn.server.com
identity local fqdn fqdn.client.com
authentication local pre-share
authentication remote pre-share
keyring local ikev2keyring
lifetime 1000
exit
mode transport
exit
set ikev2-profile ikev2profile
exit
ip address 212.199.8.1 255.255.255.0
exit
ip address 10.1.1.1 255.255.255.0
exit
interface Tunnel 1
ip address 5.0.0.1 255.255.255.0
tunnel mode gre


exit
ip route 10.1.2.0 255.255.255.0 Tunnel 1
end
configure terminal
hostname Server
peer peername
pre-shared-key local server
pre-shared-key remote client
address 212.199.8.1
exit
exit
match identity remote fqdn fqdn.client.com
identity local fqdn fqdn.server.com
exit
mode transport
exit
responder-only
exit
ip address 212.199.8.2 255.255.255.0
exit
ip address 10.1.2.2 255.255.255.0
exit
interface Tunnel 1
ip address 5.0.0.2 255.255.255.0
tunnel mode gre
exit
ip route 10.1.1.0 255.255.255.0 Tunnel 1
end

5.16.9 C o n fi g u r a ti o n Ex a m p l e - I KE v 2 u s i n g P re -S h a re d K e ys a n d a T u n n e l
Interface
• In this example, a OneOS device is connected to a Cisco IOS15 like device:
• The tunnel is protected by means of an IPsec profile, which refers to an IKEv2 profile and a transform
set.
In the IKEv2 profile, the local and remote fqdn are set, and it refers to the pre-shared keys via the
IKEv2 keyring.
• The IP address of the tunnel on the OneOS device is received from the Cisco device via the
ip address negotiated command.
OneOS device configuration
no reboot recovery-on-error
logging buffered size 16364
hostname R0
peer R1
pre-shared-key local abcdefg
pre-shared-key remote abcdefg
address 1.1.1.2
exit
exit
!
match identity remote fqdn a12
match identity remote fqdn test-pki2.lab.com
identity local fqdn test-pki1.oneaccess-net.com
authentication remote rsa-sig
lifetime 14700
no config-exchange set send
exit
!
crypto ipsec transform-set AB
esp-aes esp-sha-hmac
mode transport
exit
!
crypto ipsec profile ipsecprofileab
set pfs group16
set transform-set AB
exit
!
ip address 1.1.1.1 255.255.255.255
exit
ip address 2.2.2.1 255.255.255.255
exit


ip address 192.168.10.1 255.255.255.0
exit
exit
exit
ip address 172.31.54.50 255.255.255.0
exit
exit
!
interface Tunnel 1
ip address negotiated
tunnel mode gre
tunnel protection ipsec profile ipsecprofileab
exit
!
ip route 1.1.1.2 255.255.255.255 192.168.10.2
ip route 2.2.2.2 255.255.255.255 Tunnel 1
no snmp set-write-community private
no snmp set-read-community public
voice-default
end
Cisco device configuration
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
aaa new-model
!
aaa authorization network testList local
!
aaa attribute list attribList
attribute type addr 11.11.11.11
!
aaa session-id common
!
!
crypto ikev2 authorization policy authPolicy
dns 3.3.3.1 4.4.4.2
netmask 255.255.255.0
aaa attribute list attribList
route set access-list aclStd
!
crypto ikev2 proposal ikev2proposal
encryption aes-cbc-256 aes-cbc-192
integrity sha512 sha384 sha256
group 16 14 5 2
!
crypto ikev2 policy ikev2policy
proposal ikev2proposal
!
peer R0
address 1.1.1.1
!

!
match identity remote fqdn test-pki1.oneaccess-net.com
identity local fqdn test-pki2.lab.com
lifetime 14700
aaa authorization group psk list testList authPolicy
!
mode transport
!
set pfs group16
!
!
interface Loopback1
ip address 1.1.1.2 255.255.255.255
!
interface Loopback2
ip address 2.2.2.2 255.255.255.255
!
interface Tunnel1
ip address 10.0.1.2 255.255.255.0
!
interface Ethernet0/0
ip address 192.168.10.2 255.255.255.0
!
no ip address
shutdown
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
ip route 1.1.1.1 255.255.255.255 192.168.10.1
ip route 2.2.2.1 255.255.255.255 Tunnel1
ip route 11.11.11.11 255.255.255.255 Tunnel1
!
ip access-list standard aclStd
permit 9.97.7.0 0.0.0.255
permit 1.1.1.0 0.0.0.255
!
line con 0
logging synchronous
line aux 0
line vty 0 4
transport input all
!
!
end

5.16.10 Configuration example - IKEv2 with Certificate Authentication and a

Tunnel Interface
• In this example, a OneOS device is connected to a Cisco IOS15 like device:
• The tunnel is protected by means of an IPsec profile, which refers to an IKEv2 profile and a transform
set.
In the IKEv2 profile, the local and remote fqdn are set, and it refers to the certificates via the
authentication local, authentication remote and pki trustpoint commands.
• Note that in the configurations below, the certificates themselves, under the crypto pki
certificate chain pki-test command, are not shown completely.
OneOS device configuration
• The local fqdn must match with what is set in the certificate itself as subject; in this case:
test-pki1.oneaccess-net.com.
This is a small extract of the certificate itself:
Subject: C=FR, ST=PACA, …, CN= test-pki1.oneaccess-net.com
• Device configuration:
no reboot recovery-on-error
logging buffered size 16364
hostname R0
crypto pki trustpoint pki-test
revocation-check none
rsakeypair pki-test
exit
!
crypto pki certificate chain pki-test
certificate ca F24ACF1297D66399
3082040F 308202F7 A0030201 02020900 F24ACF12 97D66399 300D0609
.!.certificate is not shown completely
531C53E4 A618BC8A 59509AB6 CA337948 C7BCD8
quit
certificate 04
30820404 308202EC A0030201 02020104 300D0609 2A864886 F70D0101
0B012EBF 3680DFA8
quit
exit
!
peer R1
address 1.1.1.2
exit
exit
!
match identity remote fqdn test-pki2.lab.com
! matches certificate sent by remote
identity local fqdn test-pki1.oneaccess-net.com
! matches device certificate (=without ca) subject CN

authentication local rsa-sig

pki trustpoint pki-test
lifetime 14700
no config-exchange set send
exit
!

mode transport
exit
!
set pfs group16
exit
!
ip address 1.1.1.1 255.255.255.255
exit
ip address 2.2.2.1 255.255.255.255
exit
ip address 192.168.10.1 255.255.255.0
exit
exit
exit
ip address 172.31.54.50 255.255.255.0
exit
exit
!
interface Tunnel 1
ip address 10.0.1.1 255.255.255.0
tunnel mode gre
exit
!
ip route 1.1.1.2 255.255.255.255 192.168.10.2
ip route 2.2.2.2 255.255.255.255 Tunnel 1
no snmp set-write-community private
no snmp set-read-community public
voice-default
end

Cisco device configuration
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
clock timezone CET 1 0
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
ip auth-proxy max-login-attempts 5
ip admission max-login-attempts 5
!
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
crypto pki trustpoint pki-test
revocation-check none
rsakeypair pki-test
!
crypto pki certificate chain pki-test
certificate 03
30820408 308202F0 A0030201 02020103 300D0609 2A864886 F70D0101 0B050030
4888288D B093A967 B0336445
quit
certificate ca 00F24ACF1297D66399
3082040F 308202F7 A0030201 02020900 F24ACF12 97D66399 300D0609 2A864886
531C53E4 A618BC8A 59509AB6 CA337948 C7BCD8
quit
!
redundancy
!
crypto ikev2 proposal ikev2proposal
encryption aes-cbc-256 aes-cbc-192
integrity sha512 sha384 sha256
group 16 14 5 2
!
crypto ikev2 policy ikev2policy
proposal ikev2proposal
!
peer R0
address 1.1.1.1
!
match identity remote fqdn test-pki1.oneaccess-net.com
identity local fqdn test-pki2.lab.com
authentication local rsa-sig
pki trustpoint pki-test
lifetime 14700

!
mode transport
!
set pfs group16
!
!
interface Loopback1
ip address 1.1.1.2 255.255.255.255
!
interface Loopback2
ip address 2.2.2.2 255.255.255.255
!
interface Tunnel1
ip address 10.0.1.2 255.255.255.0
!
ip address 192.168.10.2 255.255.255.0
!
no ip address
shutdown
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 1.1.1.1 255.255.255.255 192.168.10.1
ip route 2.2.2.1 255.255.255.255 Tunnel1
!
control-plane
!
line con 0
logging synchronous
line aux 0
line vty 0 4
login
transport input all
!
!
end

6 G R O U P E N C R Y P T E D T R A N S P O R T V P N ( G E T V P N )
6.1 INTRODUCTION TO GET VPN
Warning: As of OneOSv5.2R2, GET VPN tunnels cannot run concurrently with standard IPsec tunnels on
the same interface.
• GET VPN is a tunnel-less encryption mode developed by Cisco. It is suitable to build any-to-any IP
VPNs over any kind of network topology including fully meshed networks. Because it preserves the
original IP addresses, it has a number of advantages over other IP VPN technologies: no overlay
routing, instantaneous any-to-any connectivity and efficient multicast replication. By using a single SA
and common key pair for the entire secure network, GET VPN is highly scalable. Because it is tunnel-
less, one drawback of GET VPN is that within IP networks with private networks it must go over a
MPLS or Ethernet enabled network; it cannot go over the Internet.
• OneOS GET VPN implementation complies with:
o RFC 3547 Group Domain of Interpretation (GDOI).
o RFC 3740 Multicast Group Security Architecture.
o RFC 4046 Multicast Security (MSEC) Group Key Management Architecture.
• It is interoperable with Cisco ISR routers running GET VPN and with a Cisco router as Key Server.
The Group Member part of the MIB GDOI has been implemented to remotely operate the GET VPN
service enabled on OneOS-based routers.
• Before the Group Member (GM) receives the policy from the Key Server (KS), it forwards all traffic
unencrypted by default (fail-open mode). In order to make this fail-close, the user must define an ACL
on the interface to drop packets to be sent over the tunnel. This ACL is normally the opposite from the
policy received from the KS.
• A crypto map can be attached to a loopback interface to use the same IP address when possibly
connected over different interfaces to the key server.
• The GET VPN works with private IP addresses. There is no need to support NAT-T over the VPNs.
However NAT-T is mandatorily supported between the GMs and the KS for the GDOI exchange. UDP
port 4500 is used for this communication.

6.2 GET VPN CONFIGURATION
In this section only CLI commands specific to GET VPN are mentioned. Other existing related commands
are re-used.
6.2.1 GET VPN Server license activation
• GET VPN server functionalities are only available when the GET VPN software license, which is part
of the ASIP license, is activated. The related commands are rejected if the license is not activated on
the router. License activation is possible if the product has sufficiently hardware resources and is pre-
loaded with the rights to use the license.
• The GET VPN software license is part of the ASIP license; use the following command in global
configuration mode to activate the ASIP license:
--------------------------------------------------------------
--------------------------------------------------------------
--------------------------------------------------------------
--------------------------------------------------------------
CLI(configure)>
• Note that the GET VPN software license is also activated with
the license activate getvpn command.
6.2.2 Configuring the GDOI Group on the Group Member (GM)
The GM is configured using the same group identity defined on the Key Server (KS) and the address of the
KS.
To create a GDOI group and enter in GDOI Group configuration mode, use the following command in
CLI(configure)> crypto gdoi group <group-name: 1-20 char>
CLI(config-gdoi)>
To remove a GDOI group, use the no form of the command in global configuration mode:
CLI(configure)> no crypto gdoi group <group-name: 1-20 char>
Note: a Group can be configured with only one identity (either a number or an IPv4 address). When an
already configured identity is modified, the downloaded SAs, flows and Key Encryption Key (KEK) SA are
deleted and re-registration is attempted.
To set the identity of the group as a number, use the following command in GDOI group configuration
mode:
CLI(config-gdoi)> identity number <0-2147483647>

To set the identity of the group as an IPv4 address, use the following command in GDOI group
configuration mode:
CLI(config-gdoi)> identity address ipv4 <ipv4-address>
To clear/remove the identity of the group, use the no form of the command in GDOI group configuration
mode (the downloaded SAs, flows and Key Encryption Key (KEK) SA are deleted):
CLI(config-gdoi)> no identity
A maximum of 5 Key Servers can be configured per Group. Registration to Key Servers will be attempted
in the order of configuration.
To define the IPv4 address of the Key Server, use the following command in GDOI group configuration
mode:
CLI(config-gdoi)> server address ipv4 <KS-ipv4-address>
To remove the IPv4 address of the Key Server, use the no form of the command in GDOI group
configuration mode (any existing downloaded SAs, flows and KEK SA are deleted; the Group will be
inactive and cannot start re-registration unless a valid key server address is configured):
CLI(config-gdoi)> no server address ipv4 <KS-ipv4-address>
To define the interface to use to register the group with configured Key Servers, use the following
command in GDOI group configuration mode. The future registration and rekey will happen through this
interface. If this interface cannot reach any of the configured Key Servers, registration of the group will fail.
If not specified, by default, the registration would happen through the interface where the crypto map is
applied.
CLI(config-gdoi)> client registration interface <type> <number>
To return to the default interface, use the no form of the command in GDOI group configuration mode:
CLI(config-gdoi)> no client registration interface
Use the following command to terminate GDOI group configuration and return to global configuration
mode:
CLI(config-gdoi)> exit
CLI(configure)>
6.2.3 C o n fi g u r i n g t h e Cr yp t o M a p o n t h e G ro u p M e m b e r ( GM )
The crypto map has a new type gdoi. It is linked to the GDOI Group created above.
To create a GDOI crypto map and enter in GDOI crypto map configuration, use the following command in
CLI(configure)> crypto map gdoi <map-name: 1-20 char> <number: 1-10000>
CLI(config-gdoi)>
To remove a GDOI crypto map, use the no form of the command in global configuration mode:
CLI(configure)> no crypto map <map-name> [<number>]
To associate the GDOI crypto map to a GDOI group, use the following command in GDOI crypto map
configuration mode:
CLI(config-gdoi)> set group <group-name>

To remove the association to the GDOI group, use the no form of the command in GDOI crypto map
configuration mode:
CLI(config-gdoi)> no set group <group-name>
To associate an access-list for the GDOI crypto map work in fail-close mode (see 6.1), use the following
command in GDOI crypto map configuration mode:
CLI(config-gdoi)> match address <acl-name>
To remove the association to the access-list, use the no form of the command in GDOI crypto map
configuration mode:
CLI(config-gdoi)> no match address <acl-name>
To add an informational comment to the GDOI crypto map, use the following command in GDOI crypto
map configuration mode:
CLI(config-gdoi)> description <1-100 characters>
To remove the informational comment, use the no form of the command in GDOI crypto map configuration
mode:
CLI(config-gdoi)> no description
Use the following command to terminate GDOI crypto map configuration and return to global configuration
mode:
CLI(config-gdoi)> exit
CLI(configure)>
6.2.4 Ap p l yi n g th e G D OI C ryp t o M a p to a n I n te rfa c e
To apply the GDOI crypto map on an interface and then start the SA establishment with the key server
(KS), use the following command in interface configuration mode:
CLI(config-if)> crypto map <map-name>
To remove the GDOI crypto map from the interface, use the no form of the command in interface
configuration mode:
CLI(config-if)> no crypto map [<map-name>]
When a GM can connect via multiple interfaces, it should always use the same IP address for
communications. A dedicated interface can be used for that purpose (e.g. Loopback interface).
To define a defined local address as the IP address to use for exchanges, use the following command in
CLI(configure)> crypto map local-address <map-name>
{ loopback <1-65535>
| fastethernet <slot/port>
| gigabitethernet <slot/port> }
Example:
crypto map GETVPN
exit
crypto map GETVPN
exit

interface loopback 1
ip address 10.10.10.1
exit
crypto map local-address GETVPN loopback 1
To remove the local address, use the no form of the command in global configuration mode:
CLI(configure)> no crypto map local-address <map-name>
6.2.5 Configuring the Re-Registration behavior
Existing Key Servers expect Rekey-ACK message in response to UNICAST REKEY message received.
This acknowledgement message cannot be sent by OneOS as it contains a HASH Payload, which uses a
proprietary method to calculate the HASH.
The Key server in turn deletes the group membership if it did not receive the Rekey-ACK message for 3
consecutive rekeys. So to sustain the membership with existing key servers, OneOS GET VPN
implements several types of Re-Registration mechanism as depicted below.
6.2.5.1 Re-Registration on Timeout
This method is recommended to be used with CISCO Key Server running Cisco IOS 15.0 (1).
In this method of re-registration, the GM re-registers on a fixed timeout value, i.e. the GM will re-register
only on timeout (when an expected rekey message is not received). This method is enabled by default.
To select this mode of re-registration, use the following command in global configuration mode:
CLI(configure)> crypto gdoi registration-trigger timeout
In this case the time at which the GM re-registers if no rekey message was received is:
Re-Registration Timer (seconds) = Traffic Encryption Key (TEK) life Time
– (10% of TEK Life time) + [ jitter = 2% of TEK Life Time or 6 seconds ]
When the GM does not get a rekey from the Key Server in expected time, the following log messages
indicate that the GM has triggered and successfully re-registered with the Key Server.
00:22:53.660 IKE: No rekey is received from KS. Starting Re-registration to KS
00:22:56.215 IKE: Start registration to KS 10.0.0.1 for group group1 using address 10.2.0.1
00:22:56.384 IKE: Registration to KS 10.0.0.1 complete for group group1 using address 10.2.0.1
If the rekey message is received from server, re-registration is not triggered.

00:22:59.322 IKE: GDOI rekey message received from KS 10.0.0.1 for group group1
If multiple Key Servers are configured, the GM re-registers to the last successfully registered Key Server in
case of Re-register on Timeout.
6.2.5.2 Re-Registration on Rekey
This method is recommended to be used with CISCO Key Server running Cisco IOS 12.4T (24).
Each time a rekey message is received from the CISCO key server, One Access GM will re-register to the
key server. To select this mode of re-registration, use the following command in global configuration mode:
CLI(configure)> crypto gdoi registration-trigger rekey
To reset back to the default re-registration mode (timeout), use the no form of the command in global
configuration mode:
CLI(configure)> no crypto gdoi registration-trigger
In this case the time at which the GM re-registers is:

Re-Registration Timer (seconds) = Time instant of Received Rekey
+ [ jitter = 2% TEK lifetime or 6 seconds ]

When the GM reregisters with the Key Server on the receipt of a rekey message from the Key Server, the
following log messages indicate that the GM has re-registered successfully with the Key Server.
If multiple Key Servers are configured, the GM re-registers to the last successfully registered Key Server in
case of Re-register on Rekey.
6.2.5.3 Re-Registration None
This method is recommended for non-Cisco key servers.

In this method One Access GM will re-register some time before Traffic Encryption Key (TEK) SA expiry if
the expected rekey message is not received from the Key Server.
This method differs from the timeout method only for the timing at which re-registration is triggered (at
95% of TEK lifetime instead of at 90% of TEK life time for the timeout method).
To select this mode of re-registration, use the following command in global configuration mode:
CLI(configure)> crypto gdoi registration-trigger none
To reset back to the default re-registration mode (timeout), use the no form of the command in global
configuration mode:
CLI(configure)> no crypto gdoi registration-trigger
In this case the time at which the GM re-registers:

Re-Registration Timer (seconds) = TEK Life Time
– ([5% of TEK LifeTime] or [60 sec]) + [ jitter = 2% TEK or 6 seconds ]
When the GM does not get a rekey from the Key Server, the following log messages indicate that the GM
has triggered and successfully re-registered with the Key Server.
00:11:54.480 IKE: No rekey is received from KS or registration didn't go through. Starting Re-
registration to KS
If the rekey messages are received from server, re-registration is not triggered.
If multiple Key Servers are configured, the GM re-registers to the first configured Key Server in case of Re-
register None.
Note: KEK SA Re-registration:

For all above cases the GM, whenever the Rekey transport mode is Unicast the GM reregisters at the KEK
lifetime expiry with a jitter introduced as follows:
Re-Registration for KEK Timer (seconds) =
KEK lifetime + [ jitter = 2% KEK lifetime or 6 seconds ]

6.3 GET VPN STATISTICS AND DEBUG
6.3.1 Show and clear commands
To display the complete GDOI configuration and the downloaded KEK, TEK and ACL information, use the
following command in global mode:
CLI> show crypto gdoi
GDOI GROUP INFORMATION
Group Name : group1
Group Identity Type : KEY-ID
Group Identity : 12345
Group Server(Active) : 10.0.0.1
Group Server(List) : 10.0.0.1
Re-Registration Mode : Timeout
Rekeys received : 0
Rekeys success : 0
Rekeys Failed : 0
Pull exchange Failed : 0
IPSec SA Direction : Both
Cmap Association Status : Associated
Associated cmap list(seq num) : gdoi_map(1)
Group Member information for the Group : group1
Group member : 10.2.0.1

Registration status : Registered
Registered with : 10.0.0.1
Re-registers in : 5066 sec
Succeeded registration : 1
Attempted registration : 1
Last rekey from : 0.0.0.0
Last rekey seq num : 0
Unicast rekey received : 0
Rekeys cumulative
Total received : 0
After latest register : 0
Rekey Received(hh:mm:ss) : 0:0:0
Re-Register on Rekey : 0
Re-Register on Timeout : 0
Policies downloaded from KS 10.0.0.1:

Crypto-map : gdoi_map(1)
deny udp any eq 848 any eq 848
permit 10.4.0.0 0.0.0.255 10.1.0.0 0.0.0.255
permit 10.1.0.0 0.0.0.255 10.4.0.0 0.0.0.255
KEK POLICY:
KEK Name : REKEY_isakmp-10.2.0.1-10.0.0.1
Destination Addr : 10.2.0.1
Source Addr : 10.0.0.1
State : READY
Rekey Type : Unicast
Current Sequence No : 0
Life Time : 6195
Remaining Life Time : 5356
Group Name : group1
SPI : 0e66852b217245ac62453e3a2a90741c
Encryption Algorithm : 3DES-CBC
Encryption KeyLength : 192
Hash Algorithm : SHA1
Signature Algorithm : RSA
Signature KeyLength : 1024
TEK POLICY:
IPsec SA:
spi : 0xa8d36646
transform : esp-3des esp-sha-hmac
sa Remaining life time : 5355
Anti-Replay : Disabled

The above command displays the GDOI re-registration mode selected for the Rekey-ACK. In the example
the selected mode is "Re-Register on Timeout", the Re-Key transport selected by the Key Server is
Unicast, the current sequence number is 0; the TEK and KEK information is displayed.
To clear all GDOI negotiated SAs, policies, and statistics, use the following command in global mode:
CLI> clear crypto gdoi
To clear negotiated SAs, policies, and statistics for a given GDOI group, use the following command in
global mode:
CLI> clear crypto gdoi group <group-name>
To clear the crypto GDOI statistics, use the following command in global mode:
CLI> clear crypto gdoi statistics
To display the GDOI registration status, use the following command in global mode:
CLI> show crypto gdoi gm
Group Member information for the Group: group1
Group member : 10.2.0.1

Registration status : Registered
Registered with : 10.0.0.1
Re-registers in : 5060 sec
Succeeded registration : 1
Attempted registration : 1
Rekey Transport : Unicast
Last rekey from : 0.0.0.0
Last rekey seq num : 0
Unicast rekey received : 0
Rekeys cumulative
Total received : 0
Rekey Received(hh:mm:ss) : 0:0:0
Re-Register on Rekey : 0
Re-Register on Timeout : 0
When the GDOI registration is successful, registration status is displayed as “Registered” and the statistics
and other information are updated.
To display the downloaded RE-KEY SA (KEK SA) information, use the following command in global mode:
CLI> show crypto gdoi gm rekey
Group: group1
Rekeys cumulative
Total received : 0
Rekey SA information:
dst src my-cookie his-cookie
Current: 10.2.0.1 10.0.0.1 0x62453E3A 0x0E66852B
Previous: --- --- --- ---
To display the downloaded ACL policy information, use the following command in global mode:
CLI> show crypto gdoi gm acl
Group: group1
Crypto-map: gdoi_map(1)
permit 10.4.0.0 0.0.0.255 10.1.0.0 0.0.0.255
permit 10.1.0.0 0.0.0.255 10.4.0.0 0.0.0.255
To display the complete downloaded KEK SA information, use the following command in global mode:
CLI> show crypto gdoi kek sa

KEK Name : REKEY_isakmp-10.2.0.1-10.0.0.1

Destination Addr : 10.2.0.1
Source Addr : 10.0.0.1
State : READY
Current Sequence No : 0
Life Time : 6195
Remaining Life Time : 5338
Group Name : group1
SPI : 0e66852b217245ac62453e3a2a90741c
Encryption Algorithm : 3DES-CBC
Encryption KeyLength : 192
Hash Algorithm : SHA1
Signature Algorithm : RSA
Signature KeyLength : 1024
To display the downloaded TEK SA information, use the following command in global mode:
CLI> show crypto gdoi ipsec sa [vrf <vrf-name>]
SA created for group group1:
FastEthernet 1/0
Crypto map tag: gdoi_map
policy:
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/17/848)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/17/848)
direction: direction: Both, replay: Disabled
policy:
policy:
CLI> show crypto gdoi ipsec sa summary

Total Number of In GDOI SA : 0
Total Number of Out GDOI SA : 0
Total Number of In Permit Policies : 0
Total Number of Out Permit Policies : 0
Total Number of In Deny Policies : 0
Total Number of Out Deny Policies : 0
To display crypto GDOI IPsec statistics, use the following command in global mode:
CLI> show crypto gdoi ipsec statistics
GDOI Input Stats:
Inbound Total pkt : 33493
Inbound Non ipsec if : 22271
Inbound Process ipsec : 0
Inbound Pkt protected : 0
Inbound No gdoi SA : 0
Inbound Local pkt : 0
Inbound Ike pkt : 0
Inbound Tunnel IpIp : 0
Inbound Tunnel No IpIp : 0
Inbound PlainLocal pkt : 0
Inbound Non Gdoi If : 0
Inbound Non Esp fwd pkt: : 11222
Inbound Fragmented : 0
Inbound First Fragment : 0
Inbound ReAsmbl Buffered : 0
Inbound No hdr preserved : 0
Inbound SA Inbound-only : 0
Inbound First sa active : 0
Inbound No active sa : 0
Inbound New active sa : 0
Inbound Fwd esp no sa : 0
Inbound local esp no sa : 0
Inbound post-decrypt no sa : 0
Inbound Pkt re-entry : 0
Inbound Inbound-optional : 0
Inbound Bypassed : 0
GDOI Output Stats:

Outbound Total pkt : 146
Outbound Non ipsec if : 0

Outbound Process ipsec : 0

Outbound Pkt protected : 0
Outbound No gdoi SA : 0
Outbound process error : 0
Outbound Ike pkt : 146
Outbound Tunnel post-encap : 0
Outbound Tunnel pre-encap : 0
Outbound Qos If Drop : 0
Outbound SA Inbound-only : 0
Outbound First sa active : 0
Outbound No sa active : 0
Outbound New sa active : 0
Outbound hdr preserved : 0
Outbound Bypassed pkt : 0
To clear crypto GDOI IPsec statistics, use the following command in global mode:
CLI> clear crypto gdoi ipsec statistics
To display the IPsec SAs currently configured, use the following command in global mode:
CLI> show crypto ipsec sa
Outbound esp SA
SPI: 0xA8D36646(2832426566)
Source->Destination: 10.2.0.1->10.0.0.1
DOI: 2 (0/1/2 manual/ipsec/gdoi)
MTU: 1444
Remaining hard lifetime : 5336s
Packets/Bytes: 0/0
local ident (addr/mask/prot/port): 10.4.0.0/255.255.255.0/0/0
remote ident (addr/mask/prot/port): 10.1.0.0/255.255.255.0/0/0
Inbound esp SA
SPI: 0xA8D36646(2832426566)
Packets/Bytes: 0/0
Outbound esp SA
SPI: 0xA8D36646(2832426566)
MTU: 1444
Packets/Bytes: 52/6240
Inbound esp SA
SPI: 0xA8D36646(2832426566)
Packets/Bytes: 53/4952
To display ESP statistics, use the following command in global mode:

CLI> show crypto esp
ESP statistics:
IN: 5 total, 640 bytes
0 bad policy, 0 no SA found, 0 counter wrapping
0 anti-replay, 0 verifications failures, 0 authentication failures
0 total udp encaps, 0 invalid
OUT: 5 total, 600 bytes
0 queue drops
0 encryption/decryption failures, 0 error
0 total udp encaps
To clear ESP statistics, use the following command in global mode:

CLI> clear crypto esp

6.3.2 Commands to temporaril y change the direction of IPsec SAs
For test purpose, it is possible to temporarily change the direction of IPsec SAs for all GDOI groups or for a
defined GDOI group. Use the following command in global mode:
CLI> crypto gdoi gm ipsec direction [groupname <group-name>]
{ both | inbound-only | inbound-optional }
both: IPsec SA will only accept cipher text and will encrypt the packet before forwarding it out.
inbound-only: IPsec SA will accept both cipher and plain text and will forward the packet in clear text.
inbound-optional: IPsec SA will accept both cipher and plain text and will encrypt the packet before
forwarding it out.
6.3.3 Debug commands
To debug GDOI configuration, use the following command in global mode:

CLI> [no] debug crypto gdoi config
To debug GDOI exchanges, use the following command in global mode:

CLI> [no] debug crypto gdoi exchange
To debug GDOI negotiations, use the following command in global mode:

CLI> [no] debug crypto gdoi negotiation
To debug Key download, use the following command in global mode:

CLI> [no] debug crypto gdoi sysdep
To debug GDOI re-registrations, use the following command in global mode:

CLI> [no] debug crypto gdoi misc
To get detailed IPsec GDOI information, use the following command in global mode:
CLI> [no] debug crypto ipsec gdoi details
To debug IPsec GDOI data, use the following command in global mode:
CLI> [no] debug crypto ipsec gdoi data
To debug IPsec GDOI SA, use the following command in global mode:
CLI> [no] debug crypto ipsec gdoi sa
To debug IPsec GDOI Security Policy Database (SPD), use the following command in global mode:
CLI> [no] debug crypto ipsec gdoi spd

6.4 GET VPN EXAMPLE
The scenario described below involves two OneAccess GET VPN Group Members communicating with
one other after registration with a Cisco Key Server. All the three devices can be communicated to each
other via an intermediate router or a cloud. Hosts in LAN 1 can communicate transparently with Hosts in
LAN2 once the Group Member GM1 and GM2 have successfully registered with the Key Server and
downloaded the appropriately configured policies.
Key Server (KS)
10.0.0.1
Key Distribution
10.0.0.2
Group Member GM1 Group Member GM2
10.2.0.1 10.2.0.2 10.3.0.2 10.3.0.1

10.1.0.1 10.4.0.1
Router
LAN 1 LAN 2
Hosts 10.1.0.X/24 Hosts 10.4.0.X/24
6.4.1 Group Member GM1 configuration
hostname GM1
crypto engine enable ! enable Crypto Engine on GM
! configure isakmp policy and pre-shared key matching with cisco key
server
group 1
exit
crypto isakmp key tempkey1 address 10.0.0.1
! configure gdoi group with group-id same as with server and ip of the
server
crypto gdoi group group1
identity number 12345
server address ipv4 10.0.0.1
exit
! set group in a gdoi crypto map
crypto map gdoi gdoi_map 1
set group group1
exit

! apply cryptomap on the interface

ip address 10.2.0.1 255.255.255.0
description Group Member interface
crypto map gdoi_map
exit
! gateway for the 10.1.0.0/24 network
ip address 10.1.0.1 255.255.255.0
description LAN1 interface
exit
! ip route to reach the KS
! ip route to reach other GMs private network
ip route 10.0.0.1 255.255.255.0 10.2.0.2
ip route 10.4.0.0 255.255.255.0 10.2.0.2
6.4.2 Group Member GM2 configuration
hostname GM2
crypto engine enable ! enable Crypto Engine on GM
! configure isakmp policy and pre-shared key matching with cisco server
group 1
exit
! configure gdoi group with group-id same as with server and ip of the
server
crypto gdoi group group1
server address ipv4 10.0.0.1
exit
! set group in a gdoi crypto map
crypto map gdoi gdoi_map 1
set group group1
exit
! apply cryptomap on the interface
ip address 10.3.0.1 255.255.255.0
description Group Member interface
crypto map gdoi_map
exit
! gateway for the 10.4.0.0/24 network
ip address 10.4.0.1 255.255.255.0
description LAN2 interface
exit
! ip route to reach the KS
! ip route to reach other GMs private network
ip route 10.0.0.1 255.255.255.0 10.3.0.2
ip route 10.1.0.0 255.255.255.0 10.3.0.2
6.4.3 For information: CISCO Key Server configuration
hostname cisco_ks
! configure the isakmp policy and pre-shared keys
authentication pre-share
exit
! configure ipsec transform-set
crypto ipsec transform-set trans_3des esp-3des esp-sha-hmac
! configure ipsec profile
crypto ipsec profile profile1
set transform-set trans_3des
exit

! configure gdoi group with identity number and server as local

crypto gdoi group GRP_1
server local
! configure rekey time in the server retransimission and unicast rekey
rekey lifetime seconds 10000
rekey retransmit 10 number 2
rekey authentication mypubkey rsa rsakey
rekey transport unicast
! configure details for ipsec sa: access-lists, replay
sa ipsec 1
profile profile1
match address ipv4 getacl
no replay
! IPv4 address as the server's address for exchange
address ipv4 10.0.0.1
! Key Server Interface
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
description Key Server Interface
duplex auto
speed auto
..exit
! configure bi-directional acl, for data between LAN1 and LAN2
ip access-list extended getacl
permit ip 10.4.0.0 0.0.0.255 10.1.0.0 0.0.0.255
permit ip 10.1.0.0 0.0.0.255 10.4.0.0 0.0.0.255
exit
! configure ip route to the GMs
ip route 10.2.0.1 255.255.255.255 10.0.0.2
ip route 10.3.0.1 255.255.255.255 10.0.0.2
Note: RSA key must be generated on the Key Server. In this case we selected 1024 bit modulus:
crypto key generate rsa exportable label rsakey
Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing
a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024.
% Generating 1024 bit RSA keys, keys will be exportable...[OK]

7 R O U T I N G I N F O R M A T I O N P R O T O C O L ( R I P V 1 A N D R I P V 2 )
This section describes the main features of the Routing Information Protocol (RIPv1 and RIPv2), and its
configuration.
7.1 RIP FEATURES
The Routing Information Protocol is a mature but still commonly used Interior Gateway Protocol (IGP)
defined for use in small, homogeneous networks, it is a classical distance-vector routing protocol. RIP
(version 1) was first documented in RFC 1058; version 2 extensions are in RFC 2453.
RIP uses broadcast (version 1) or multicast (version 2) User Datagram Protocol (UDP) data packets to
exchange routing information. By default, RIP sends routing information updates every 30 seconds. This
process is termed advertising. If a router does not receive an update from another router for 180 seconds
or more, it marks the routes served by the non-updating router as being unusable. If the router has not
been updated after 300 seconds, the router removes all routing table entries for the non-updating router.
The metric that RIP uses to rate the value of different routes is a hop count. The hop count is the number
of routers that a packet must traverse to reach the destination using a given route. A directly connected
network has a metric of one; an unreachable network has a metric of 16. This very limited range of metrics
makes RIP unsuitable for large networks.
If the router has a default network path, RIP advertises a route that links the router to the pseudo network
0.0.0.0. The network 0.0.0.0 does not exist; RIP treats 0.0.0.0 as a network to implement the default
routing feature. The default network will be advertised if it was learned by RIP, or if the router has been
configured to generate a default route.
By default, RIP sends routing updates to the interfaces directly connected to the specified networks. No
routing updates will be advertised to, or received from the interfaces that do not belong to the specified
networks in RIP. This checking can be deactivated.
Route auto-summarization is not used and cannot be activated.
The implementation of RIP Version 2 supports plain text and MD5 authentication.

7.2 RIP CONFIGURATION COMMANDS
To configure RIP, the user should complete the tasks in the following sections. First enable RIP; the
remaining tasks are optional.
7.2.1 Enabling RIP
Note: as of V4.3R2E2 software release, RIP is only supported on the default VRF.
RIP can be enabled or disabled on a network, in other words, interface(s). To do so, one must specify the
network address by using the following commands in global configuration mode:
CLI(configure)> router rip
CLI(router-rip) network <ip-address>
The first command places the user in router configuration mode. The second command enables the RIP
routing process on the interfaces which belong to the given network address.
The parameter <ip-address> must be the network address of a directly connected network. The
network number specified should not contain any subnet information. There is no limit to the number of
network commands that can be entered on the router.
Once RIP is enabled on a network, RIP routing updates will be sent and received through the interfaces of
that network. The interfaces without network addresses will not be advertised by any RIP update.
To remove an entry, use the no form of this command.
The following command in router configuration mode allows the user to disable the sending of routing
updates on a specific interface:
CLI(router-rip)> passive-interface <type> <unit>
The default behavior is to send routing updates on an interface on the specified networks.
To return to the default behavior, use the no form of this command.
7.2.2 Adjusting Timers
RIP makes use of several timers to control the frequency of routing updates and the interval to drop
obsolete routes, for example. Users can adjust these timers to tune routing protocol performance to better
suit the needs of their own network environment. The following timers, all expressed in seconds, can be
adjusted:
• update-timer: this is the time interval with which routing updates are sent; default is 30 seconds.
• invalid-timer: this is the time after which a route is declared invalid if no routing updates are
received; default is 180 seconds.
• flush-timer: this is the time after which a route is removed from the routing table if no routing
updates are received; default is 300 seconds.
• hold-down-timer: this is the time during which no new route update is accepted following a route
change; default is 180 seconds. This timer can be disabled by setting it to 0.
The use of this timer is optional.
To adjust these timers, run the following command in router configuration mode:
CLI(router-rip)> timers basic <update-timer> <invalid-timer>
<flush-timer> [<hold-down-timer>]
Use the default timer basic command to restore the default values.

7.2.3 Setting RIP Versions
By default, the software receives and sends RIP v2 packets. The user can also configure the software to
only receive and send v1 packets.
To specify a RIP version to be used globally (for all interfaces) by the router, run the following command:
CLI(router-rip)> version <1-2>
The default form of the above referenced command restores the default value.
The user can override the value configured by specifying another version for a particular interface.
To control the version of RIP updates that are sent to an interface, run the following commands in interface
configuration mode:
CLI(config-if)> ip rip send version <1-2>
Similarly, to control the version of RIP updates that are received from an interface, the user can run the
CLI(config-if)> ip rip receive version <1-2>
Use the default form of the above referenced commands to return to the global version.

7.2.4 Configuring Authentication
• RIP v1 does not support authentication.

RIP v2 however supports authentication of packets sent and received to/from an interface.
• Several modes of authentication are available on an interface for which RIP authentication is enabled:
plain key authentication, MD5 authentication and clear text authentication.
• Before enabling RIP authentication on a specific interface, the user must define a key string in global
configuration mode:
CLI(configure)> key chain <key-chain-name>
CLI(config-keychain)> key <key-id>
CLI(config-keychain-ke)> key-string <key-string>
CLI(config-keychain-ke)> exit
CLI(config-keychain)> exit
o The first command places user in key chain configuration mode.

The second command defines a key identified by a unique key number and places the user in
key configuration mode.
By entering the key-string keyword, the user will be able to define the character string
associated with this particular key.
Restriction: only one key can be defined in a key-chain.
Plain key authentication
• To enable RIP plain key authentication on a specific interface, use the following command in interface
configuration mode:
CLI(config-if)> ip rip authentication key-chain <key-chain-name>
o When using plain text authentication, make sure the following parameters are matching on
both sides of the link:
 key-string
 Authentication mode
MD5 authentication
• To enable RIP MD5 authentication on a specific interface, use the following command in interface
configuration mode:
CLI(config-if)> ip rip authentication mode md5
o When using MD5 authentication, make sure the following parameters are matching on both
sides of the link:
 key-string
 key-id
 Authentication mode
Clear text authentication
• To enable clear text authentication on a specific interface, use the following command in interface
configuration mode:
CLI(config-if)> ip rip authentication mode text

7.2.5 Generating a Default Route into RIP
• To generate a default route into RIP, use the following commands:

CLI(router-rip)> default-information originate
• To disable this feature, use the no form of this command.
7.2.6 Redistributing Routes
• For RIP to advertise routes learnt via other techniques than RIP, run the following command starting in
router configuration mode:
CLI(router-rip)> redistribute { connected | static | bgp | ospf }
[metric <0..16>] [route-map <map-name>]
o connected. Add this keyword for routes that are directly connected, and redistributed by RIP.
o static. Add this keyword for routes configured via static routing, and redistributed by RIP.
o bgp and ospf. Add this keyword for routes learnt via BGP or OSPF, and redistributed by RIP.
Optionally, the following arguments can be added:
o metric <0-16>. With this argument, the metric associated with the injected routes can be
set; the default metric is 1.
o route-map <map-name>. Use this command to specify a route map reference.
Optionally, route maps can be used to advertise only certain routes.
Route maps are a global mechanism for routing protocols that enables the filtering of undesired
routes. Refer to 10.3.5.4.3.4 Route Maps for more information about route maps.
• Use the no form of this command to ensure that routes are not redistributed:
CLI(config-router)> no redistribute { connected | static | bgp | ospf }
7.2.7 Route Filtering
• To control and filter routes advertised via RIP, route-maps and distribute-lists can be used:
o As seen in 7.2.6, route-maps can be applied on redistributed routes. Route-maps select the
injected routes that are allowed to be advertised by RIP, and modify the route attributes.
o Distribute-lists are used to control which routes are advertised to interfaces.
• Both mechanisms require filtering that is either based on access-lists or prefix-lists.

7.2.7.1 Filtering Based on Access Lists
Such filtering is based on standard access lists. When using an access-list for route filtering, the access-
list has a special behavior:
• The default route is written as follows: 0.0.0.0 0.0.0.0
E.g. a rule to deny the default route is: deny 0.0.0.0 0.0.0.0
• All routes (=any route) is entered as follows: 0.0.0.0 255.255.255.255
• There must be an exact match for the network; sub-networks are not matched.
E.g. if you configure permit 10.0.0.0 0.255.255.255, 10.0.1.0/24 is not matched by this rule.
Example: the following access list only selects 10.1.1.0/24 and the default route, and denies all other
routes:
ip access-list standard rtfilter
permit 0.0.0.0 0.0.0.0
permit 10.1.1.0 0.0.0.255
deny 0.0.0.0 255.255.255.255
exit
7.2.7.2 Filtering Based on Prefix Lists
Prefix-lists can be used as an alternative to access-lists in many route filtering commands, e.g. BGP route
filtering. A prefix-list must be set up before using it in a command. The entries in the prefix-list are
automatically ordered according to length, with the longest entry first, so that the most specific match is
chosen. The following sections describe the different commands that are available for creating and
managing prefix-lists. Finally the section 7.2.7.2.4 How the System Filters Traffic by Prefix List will give on
overview on how the filtering is done when using prefix-lists.
7.2.7.2.1 Prefix List Creation
To create a prefix list, use the ip prefix-list command, beginning in global configuration mode:
CLI(configure)> ip prefix-list <list-name> { deny | permit }
<network>/<len> [ge <ge-value>] [le <le-value>]
This command creates a prefix list with the name list-name.

The optional keywords ge (= greater or equal) and le (= less or equal) can be used to specify the range of
the prefix length to be matched for prefixes that are more specific than network/length.
An exact match is assumed when neither ge nor le is specified. The range is assumed to be from ge-
value to 32 if only the ge attribute is specified, and from len to le-value if only the le attribute is
specified.
A specified ge-value and/or le-value must match the following condition:
len < ge-value <= le-value <= 32
To create a prefix list you must enter at least one permit or deny clause.
To remove a prefix list and all of its entries, use the following command in global configuration mode:
CLI(configure)> no ip prefix-list <list-name> [{ deny | permit }
<network>/<len> [ge <ge-value>] [le <le-value>]]
This removes the prefix list with the name list-name.

For example, to deny all prefixes matching /24 in 128.0.0.0/8, you would use:
CLI(configure)> ip prefix-list foo deny 128.0.0.0/8 ge 24 le 24

7.2.7.2.2 Showing Prefix Entries
To display information about prefix tables, prefix table entries, the policy associated with a node, or specific
information about an entry, use the following commands, beginning in global mode.
To display information about all prefix lists:
CLI> show ip prefix-list [detail | summary]
To display a table showing the entries in a prefix list:

CLI> show ip prefix-list <list-name> [detail | summary]
To display the policy associated with the node:

CLI> show ip prefix-list <list-name> [<network>/<len>]
To display all entries of a prefix list that are more specific than the given network and length:
CLI> show ip prefix-list <list-name> [<network>/<len>] longer
To display the entry of a prefix list that matches the given prefix (network and length of prefix):
CLI> show ip prefix-list <list-name> [<network>/<len>] first-match
7.2.7.2.3 Clearing the Hit Count Table of Prefix List Entries
To clear the hit count table of prefix list entries, use the next command, beginning in global mode:
CLI> clear ip prefix-list <list-name> [<network>/<len>]
It clears the hit count table of the prefix list entries.
7.2.7.2.4 How the System Filters Traffic by Prefix List
Filtering by prefix list involves matching the prefixes of routes with those listed in the prefix list. When there
is a match, the route is used. More specifically, whether a prefix is permitted or denied is based upon the
following rules:
• An empty prefix list permits all prefixes.
• An implicit-deny is assumed if a given prefix does not match any entries of a prefix list.
• When multiple entries of a prefix list match a given prefix, the longest, most specific match is chosen.
The router begins the search at the top of the prefix list. Once a match or deny occurs, the router does not
need to go through the rest of the prefix list.
Filtering can be handled on the level of routing information and from different sources. To do that, several
mechanisms are detailed in the following sections.
7.2.7.3 Distribute-Lists
A distribute-list controls the received/sent routes advertised via RIP. First, you must create an access-
list/prefix-list as defined in the previous sections. Then, you can specify the distribute-list that is applied on
all interfaces or on a specified interface. Refer to 7.2.10.

7.2.7.4 Route Maps
To define a route map, use the following command in global configuration mode:
CLI(configure)> route-map <map-name> { permit | deny } <sequence-number>
CLI(config-route-map)>
o map-name is a string identifying the route map.

o sequence-number is an integer indicating the relative position compared to other instances
that define the route-map. When RIP applies a route-map instance to routing advertisements, it
applies the lowest instance first. If the set of conditions is not met the next instance is used and
so on until either a condition is met or there is no more condition to apply. We generally use 10
as sequence number when creating the route map and use increments of 10 for the following
route map sequence, so that you can insert easily other route map instances between already
configured instances.
Conditions are expressed using the match command that is defined as follows:
CLI(config-route-map)> match ip { address | next-hop }
{ <access-list-number> | prefix-list <list-name> }
o When using the address keyword, the match clause applies the access/prefix list to the
advertised network.
o When using the next-hop keyword, the match clause applies the access/prefix list to the
next-hop of the advertised network.
The metric of matching advertisements can be modified (only supported for BGP):
CLI(config-route-map)> set metric <+-metric>
To add a specific offset value to the metrics learnt via a specified interface, use the following command in
CLI(config-if)> ip rip metric <offset>
Also refer to the "Example" of "Backup using Route Monitoring (Dialer Watch-List)" section in the "Activity
Control of Backup & Switched Interfaces" chapter of "OneOS – WAN User Guide".
Use the following command, in global mode, to display the configuration of route maps:
CLI> show route-map [<map-name>]

7.2.8 Triggered RIP
When there is a change in the route database, it can be desirable to immediately advertise the change to
the network. For example, a router with an ISDN backup can immediately announce that an ISDN backup
has been setup, so that remote routers can update their routing tables faster.
Triggered RIP enables RIP to send updates only when changes appear in the route database thus
preventing unnecessary advertisements of routing updates on links, which are charged for usage time.
The command is the following:
CLI(router-rip)> trigger-interface { bri <slot>/<port>.<id>
| dialer <id>
| dialer-mlppp <id>
| dot11radio <slot>/<port>.<id>
| isdn <slot>/<port>.<id>
| l2tunnel <id>
| serial <slot>/<port>.<id> }
Triggered RIP is available only on the listed interfaces.
7.2.9 Administrative Distance
The administrative distance defines the preference for routes that are learnt via different routing protocols.
By default, RIP has an administrative distance of 120. To modify this distance, use:
CLI(router-rip)> distance <1..255>
Use the following command to reset the default distance:

CLI(router-rip)> no distance
7.2.10 RIP Update Filtering
RIP update filtering enables the router to select route prefixes that are advertised globally and/or per
interfaces. The command is the following:
CLI(router-rip)> distribute-list { <acl-name> | prefix <list-name>
[gateway <list-name>] } { in | out } [<interface> <unit>]
If access lists are used they are standard access lists. When prefix lists are used, the optional argument
gateway gives the name of the prefix list to be applied to the gateway of the prefix being updated.
For incoming updates, the filtering is applied first per interface, then globally. For outgoing updates, the
global distribute-list is applied first, then per interface. If optional arguments are not provided, the filtering
applies to all updates (either incoming or outgoing).
• Example 1: Outgoing Update Filtering

Only networks included in 20.1.0.0/16 must be advertised on FastEthernet 0/0 interface:
ip access-list standard out_rip_acl
permit 20.1.0.0 0.0.255.255
exit
router rip
distribute-list out_rip_acl out fastethernet 0/0
exit
• Example 2: Incoming Update Filtering

All networks except 10.20.2.0/24 are accepted on the FastEthernet 0/0 interface:
ip access-list standard in_rip_acl
deny 10.20.2.0 0.0.0.255
permit any
exit

router rip
distribute-list in_rip_acl in fastethernet 0/0
exit
• Example 3: Incoming Update filtering using Prefix List

Only prefixes with lengths of /8 coming from 10.10.10.1 address are accepted:
ip prefix-list length_8_list permit 0.0.0.0/0 ge 8 le 8
ip prefix-list allow_list permit 10.10.10.1/32
router rip
distribute-list prefix length_8_list gateway allow_list in
exit
7.2.11 Disabling update source IP address validation
By default, the router checks if the IP source address of incoming updates belongs to the specified
networks in RIP. If not, routing updates will not be advertised to, nor received from the interfaces.
Use the following command in router configuration mode to disable this checking:
CLI(router-rip)> no validate-update-source
Use the following command to make the router validate source IP addresses again:
CLI(router-rip)> validate-update-source

7.3 RIP CONFIGURATION EXAMPLE
Routers "mozart" and "bach" both have an interface connected to network 20.1.1.0/24. To exchange
routing information between the two routers using RIPv2:
192.168.2.0 20.1.1.0 10.1.2.0
mozart bach
192.168.2.88 20.1.1.88 20.1.1.48 10.1.2.48
For router bach, the configuration commands are as follows:

configure terminal
router rip
network 10.0.0.0
network 20.0.0.0
exit
To display current routes:

CLI> show ip route
Codes: C connected, S static, R RIP, O OSPF, B eBGP, b iBGP, o other
C 0.0.0.1/32 is directly connected, Null 0

C 10.1.2.0/24 is directly connected, Ethernet 0/0
C 20.1.1.0/24 is directly connected, FastEthernet 0/0
C 127.0.0.1/32 is directly connected, Loopback 0
R 192.168.2.0/24 via 20.1.1.88, FastEthernet 0/0
For router mozart, the configuration commands are as follows:

configure terminal
router rip
network 192.168.2.0
network 20.0.0.0
exit
To display mozart routes:

CLI> show ip route
Codes: C connected, S static, R RIP, O OSPF, B eBGP, b iBGP, o other
C 0.0.0.1/32 is directly connected, Null 0

R 10.1.2.0/24 via 20.1.1.48, FastEthernet 0/0
C 20.1.1.0/24 is directly connected, FastEthernet 0/0
C 127.0.0.1/32 is directly connected, Loopback 0
C 192.168.2.0/24 is directly connected, Ethernet 0/0

7.4 RIP STATISTICS
• The following command displays the parameters and current state of the active routing protocol
process:
CLI> show ip protocols
This command does not have parameters or keywords. The information displayed by this command is
useful in debugging routing operations. The following is a sample output from the
show ip protocols command:
show ip protocols
Routing Protocol is RIP
Sending updates every 30 seconds, next due in 13 seconds
Invalid after 180 seconds, flushed after 300
Redistributing: RIP
Default version control: send version 2, receive version 2
Interface Send Recv Key-chain
Ethernet 0/0 2 2
FastEthernet 0/0 2 2
Routing for Networks:
20.0.0.0
10.0.0.0
• The following command displays RIP routing database entries:

CLI> show ip rip database [<destination>] [<netmask>]
Invoked without parameters, the command will display all routing entries in the database.
The following is a sample output from the show ip rip database command:
show ip rip database 192.168.2.0 255.255.255.0
192.168.2.0/24
[2] via 20.1.1.88, 00:00:16,
show ip rip database

192.168.2.0/24
[2] via 20.1.1.88, 00:00:22,
10.1.2.0/24 directly connected, Ethernet 0/0
20.1.1.0/24 directly connected, FastEthernet 0/0
• The following command displays the number of RIP messages sent and received on an interface
involved in the RIP routing process:
CLI> show ip rip interface [<type> <unit>]
Invoked without parameters, this command will display statistics for all the interfaces involved in the
RIP routing process. The following is a sample output from the show ip rip interface
command:
show ip rip interface ethernet 0/0
IN: 0 packets, 0 discards, 0 bad routes
OUT: 124 packets
show ip rip interface
Ethernet 0/0
OUT: 125 packets
FastEthernet 0/0
OUT: 124 packets

• The following command displays the total number of messages sent and received on all the interfaces
involved in the RIP routing process:
CLI> show ip rip statistics
This command does not have parameters or keywords. The following is a sample output from the
command:
show ip rip statistics
OUT: 265 packets, 1 responses to queries
3 route database changes
7.5 RIP DEBUG AND TRACE
• The following command enables the logging of RIP routing transactions:

CLI> debug ip rip events
The following is a sample of output from that command:

16:22:42.599: RIP: sending v2 RESPONSE to 224.0.0.9 via Ethernet 0/0 (10.1.2.48)
16:22:42.599: RIP: sending v2 RESPONSE to 224.0.0.9 via FastEthernet 0/0 (20.1.1.48)
16:22:42.600: RIP: received v2 RESPONSE from 10.1.2.48 on Ethernet 0/0
16:22:42.600: RIP: received v2 RESPONSE from 20.1.1.48 on FastEthernet 0/0
16:22:53.672: RIP: received v2 RESPONSE from 20.1.1.88 on FastEthernet 0/0
Use the no form of this command to disable RIP routing transaction logging:
CLI> no debug ip rip events
• The following command enables logging of RIP routing database changes.

CLI> debug ip rip database
The following is a sample of output from that command:

16:24:45.461: RIP-DB: adding route to 20.0.0.0/8 through 20.1.1.48
Use the no form of this command to disable logging of RIP routing database changes:
CLI> no debug ip rip database

8 R I P F O R I P V 6 O R R I P N G
This section describes the main features of the Routing Information Protocol for IPv6 or RIPng for IPv6,
and its configuration.
8.1 INTRODUCTION
RIPng for IPv6 or RIP next generation for IPv6, defined in RFC 2080, is an extension of RIPv2 for support
of IPv6:
• RIPng is a distance vector protocol, and is intended to allow routers to exchange information for
computing routes through an IPv6-based network.
• RIPng relies on access to certain information about the networks the router is connected to, the most
important of which is the metric.
The RIPng metric of a network is an integer between 1 and 15. This value can be set by the system
administrator, but a value of 1 is usually used. When the metric is set to 16, the route is removed from
service. In addition to the metric, each network has an IPv6 destination address prefix and prefix
length associated with it.
• RIPng is an UDP-based protocol; each router that uses RIPng has a routing process that sends and
receives datagrams on UDP port number 521.
• Every 30 seconds, the RIPng process sends an update message, containing the complete routing
table, to every neighboring router.
• A timeout is initialized when a route is established, and any time an update message is received for
the route. If 180 seconds elapse from the last time the timeout was initialized, the route is considered
to have expired.
Upon expiration of the timeout, the route is no longer valid; however, it is retained in the routing table
for a short time so that neighbors can be notified that the route has been dropped.
After another 120 seconds, the garbage-collection time, the router removes all routing table entries of
a route that is no longer valid.

8.2 CONFIGURATION
8.2.1 Global configuration mode
To enable a RIPng router instance, run the following command, starting in global configuration mode:
CLI(configure)> ipv6 router rip [vrf <vrf-name>]
CLI(router-ripng)>
This command creates a RIPng routing process and brings the CLI in router configuration mode; the
following sections describe the commands to configure the RIPng router instance.
Adding the <vrf-name> in the above command is optional; if this is not provided, the default VRF is used.
To disable a RIPng router instance, use the no form of this command:
CLI(configure)> no ipv6 router rip [vrf <vrf-name>]
8.2.2 Router configuration
To configure the RIPng router instance, use the following commands:

CLI(router-ripng)> distance <1-254>
CLI(router-ripng)> distribute-list { access-list | prefix-list }
<list-name> {in | out} [<interface-name>]
CLI(router-ripng)> maximum-paths <1-64>
CLI(router-ripng)> redistribute { connected | static | bgp | ospf }
[metric <0..16>] [route-map <map-name>]
CLI(router-ripng)> timers <update-period> <timeout-period>
<holddown-period> <garbage-collection-period>
• distance <1-254>
Use this command to set the administrative distance for routes that are learnt via RIPng. It can be set
to any value between 1 and 254; the default value is 120.
Use the no form of this command to set the administrative distance to its default value:
CLI(config-router)> no distance
• distribute-list { access-list | prefix-list } <list-name>

{in | out} [<interface-name>]
Use this command to configure a distribute-list by either using an access-list or a prefix-list. A
distribute-list controls the received or sent routes advertised via RIPng.
First, an access-list or prefix-list must be defined. For more information on how to do this, refer to
7.2.7 Route Filtering.
To filter using an access-list in the inward direction, use the command as follows:
o distribute-list access-list <list-name> in
To filter using an access-list in outward direction, use the command as follows:
o distribute-list access-list <list-name> out
To filter using a prefix-list in inward direction, use the command as follows:
o distribute-list prefix-list <list-name> in
To filter using a prefix-list in outward direction, use the command as follows:
o distribute-list prefix-list <list-name> out

Optionally, the <interface-name> can be added to which the distribute-list has to apply. When
omitted, the distribute-list applies to all interfaces.
To delete a configured distribute-list, use the no form of the above commands:
CLI (router-ripng)> no distribute-list { access-list | prefix-list }
<list-name> {in | out} [<interface-name>]
• maximum-paths <1-64>
Use this command to set the maximum number of equal-cost routes that RIPng can support. It can be
set to any value between 1 and 64.
Use the no form of this command to return to the default value:
CLI(config-router)> no maximum-paths
• redistribute { connected | static | bgp | ospf } [metric <0..16>]

[route-map <map-name>]
Use this command to redistribute information from other routing protocols:
o connected. Add this keyword for routes that are directly connected, and redistributed by
RIPng.
o static. Add this keyword for routes configured via static routing, and redistributed by RIPng.
o bgp and ospf. Add this keyword for routes, learnt via BGP or OSPF, and redistributed by
RIPng.
o metric <0-16>. With this argument, the metric associated with the injected routes can be
set; the default metric is 1.
o route-map <map-name>. Use this command to specify a route map reference. Optionally,
route maps can be used to advertise only certain routes.
Use the no form of this command to ensure that routes are not redistributed:
CLI(config-router)> no redistribute { connected | static | bgp | ospf }
• timers <update-period> <timeout-period> <holddown-period>

<garbage-collection-period>
Use this command to configure the RIPng timers. RIPng makes use of several timers to for instance
control the frequency of routing updates and the interval to drop obsolete routes. Users can adjust
these timers to tune the routing protocol performance to better suit the needs of their own network
environment. The following timers, expressed in seconds, can be adjusted:
o update-period. This is the time interval with which routing updates are sent; the default
value is 30 seconds.
o timeout-period. This is the time interval after which a route is declared invalid if no routing
updates are received; the default value is 180 seconds; use 0 to disable this timer.
o holddown-period. This is the time interval during which no new route update is accepted
following a route change; the default value is 0, which means this timer is disabled.
o garbage-collection-period. This is the time interval after which a route is removed from
the routing table if no routing updates are received; the default value is 120 seconds.
Use the no form of this command to reset the timers to their default values:
CLI(config-router)> no timers

8.2.3 Configuring Interface Parameters
The commands described in this section, are available in the configuration mode of an interface, to
configure the interface specific RIPng parameters.
First enter the interface configuration mode. As an example here, a Gigabit Ethernet interface is used:
CLI(config-if)>
To configure the interface specific RIPng parameters, use the following commands:
CLI(config-if)> ipv6 rip [vrf <vrf-name>] enable
CLI(config-if)> ipv6 rip [vrf <vrf-name>] passive-interface
CLI(config-if)> ipv6 rip [vrf <vrf-name>] default-information
{ originate | only } [metric <1-16>]
For each command, a <vrf-name> can be added, so that the command applies to that specific VRF
instance. If the VRF instance name is not specified, the default VRF instance is used.
• ipv6 rip [vrf <vrf name>] enable
Use this command to enable RIPng on the interface.
Add an optional <vrf name> to enable RIPng on the interface for that specific VRF instance.
Use the no form of this command to disable RIPng on the interface:
CLI(config-if)> no ipv6 rip [vrf <vrf name>] enable
• ipv6 rip [vrf <vrf name>] passive-interface

Use this command to configure the interface as passive.
Once RIPng is enabled on a network, RIPng routing updates will be sent and received through the
interfaces of that network.
By configuring an interface as passive, the sending of RIPng routing updates on the interface will be
disabled.
Use the no form of this command to return to the default setting, i.e. to cancel the passive
configuration of the interface:
CLI(config-if)> no ipv6 rip [vrf <vrf name>] passive-interface
• ipv6 rip [vrf <vrf name>] default-information { originate | only }

[metric <1-16>]
Use this command to configure a default route on the interface:
o originate. Add this keyword to generate a default route entry on the interface, along with the
other routing table entries (RTEs).
o only. Add this keyword to generate a default route entry on the interface only, and suppress
the sending of other RIPng routing table entries (RTEs).
o metric <1-16>. Optionally, add a metric value to assign a metric value to the default route.
Use the no form of this command to remove the default route:
CLI(config-if)> no ipv6 rip [vrf <vrf name>] default-information
{ originate | only }

8.3 RIPNG STATISTICS
8.3.1 General RIPng statistics
To display general RIPng statistics, use the following command:

CLI> show ipv6 rip [vrf <vrf name>]
If the optional VRF instance name is not specified, information for the default VRF instance will be
displayed.
The following is a sample output from the show ipv6 rip command:
CLI> show ipv6 rip
Routing Protocol is "RIPng", VRF: Default
Administrative Distance: 120 (default is 120)
Sending updates every 30 seconds with +/-50%, next due in 24 seconds
Timeout after 180 seconds, garbage collect after 120 seconds
Interfaces:
GigabitEthernet 0/0, Default Information Originate is Enabled
Default redistribution metric is 1
8.3.2 Further RIPng statistics
To display further RIPng statistics, use the following commands:

CLI> show ipv6 rip database [vrf <vrf name>]
CLI> show ipv6 rip next-hop [vrf <vrf name>]
CLI> show ipv6 rip debug
• show ipv6 rip database [vrf <vrf name>]

Use this command to display the RIPng routing database.
• show ipv6 rip next-hop [vrf <vrf name>]
Use this command to display the RIPng learnt next hops.
• show ipv6 rip debug
Use this command to display the RIPng debug settings.

8.4 RIPNG DEBUGGING
To solve configuration issues, you might have to activate trace functions. Traces are activated using the
plain form of the following commands and are deactivated using the no form of the commands.
All commands can be followed by an optional <vrf-name>, for example:
CLI> debug ipv6 rip database [vrf <vrf-name>]
By adding a <vrf-name>, only information related to the specific VRF instance is displayed.
To stop the debugging, use the no form of the commands, for example:
CLI> no debug ipv6 rip database
The following commands are available for displaying debug messages for RIPng routing transactions:
CLI> debug ipv6 rip database
CLI> debug ipv6 rip events
CLI> debug ipv6 rip packets [send | recv]
CLI> debug ipv6 rip zebra [send | receive]
• debug ipv6 rip database

Use this command to display debugging information with regard to RIPng database changes, i.e. the
addition, modification or deletion of routing table entries (RTEs).
• debug ipv6 rip events
Use this command to display debugging information with regard to RIPng events like timers,
update/triggered events, etc.
• debug ipv6 rip packets [send | recv]
Use this command to display debugging information with regard to the sending and reception of RIPng
packets.
• debug ipv6 rip zebra [send | receive]
Use this command to display debugging information with regard to sending or receiving Zebra events.

9 B O R D E R G A T E W A Y P R O T O C O L ( B G P - 4 )
9.1 INTRODUCTION TO BGP
The Border Gateway Protocol (BGP) is an intelligent IP routing protocol that dynamically learns routing
paths, builds/updates forwarding tables and selects the best path when forwarding packets between
autonomous systems that compose the Internet (an autonomous system is a collection of networks that
are managed by a single administrative authority). It has become the de-facto standard for inter domain
routing protocol and has been deployed to overcome significant scalability limitations and stability issues
experienced with former protocols. Customer networks, such as corporations, governmental agencies,
usually employ an Interior Gateway Protocol (IGP) such as RIP or OSPF for the exchange of routing
information within their networks and to connect to the Internet through ISPs. When BGP is used between
autonomous systems (AS), the protocol is referred to as External BGP (eBGP) where the use of BGP to
exchange routes within an AS is referred to as Interior BGP (iBGP; iBGP is also an IGP).
To achieve a high level of robustness and scalability, BGP uses several routing update attributes, to select
the best path(s) and maintain a stable routing environment.
Classless inter domain routing (CIDR) is used by BGP to reduce the size of the Internet routing tables.
Full routing information is exchanged between BGP neighbors only when the TCP connection is first
established between them. When changes to the routing table are detected, the BGP routers send to their
neighbors only those routes that have changed, which makes the BGP routing protocol stable and well
suited for environment when a large number of routes must be managed. Each BGP router advertises
routing updates to their neighbors, which in turn can be filtered to optimize routing information distribution
(routes are always advertised; this behavior cannot be modified).
As of V5.1R5E1 OneOS software release, BGP implementation is RFC 4760 compliant (Multiprotocol
Extensions for BGP-4). This RFC defines an AFI (Address Family Identifier) and a SAFI (Subsequent
Address family) which should allow any protocol to be adapted to BGP. Examples of currently used AFI
are IPv4, IPv6, or X.121 (X.25, Frame Relay). Examples of SAFI depend on the AFI. For IPv4 and IPv6,
examples of SAFI are unicast, multicast, unicast-multicast or mpls-vpn. As specified in RFC 4760, a
session is established between two BGP routers when they agree to exchange routing information about
the same (AFI, SAFI) pair.
As of V5.1R5E1 OneOS software release, BGP-4 implementation is restricted to IPv4 unicast and IPv6
unicast routes. The mode to be used is configurable among the three possible operating modes (IPv4
unicast only, IPv6 unicast only, IPv4 unicast and IPv6 unicast). It is also possible to configure different
operating modes for different neighbors.
Prior to V5.R5E1 software release, OneOS supports only IPv4 unicast mode. To maintain compatibility,
IPv4 unicast is the default mode in BGP-4.

9.2 BGP CONFIGURATION
• There are many options for BGP configuration. However, a few steps are mandatory; they are:
o BGP-4 mode selection (mandatory only when IPv6 routes management is required),
o BGP neighbor configuration,
o BGP routing activation.
• Each routing update contains path information as well as some additional attributes that are used
during BGP route selection process. You may want to force preference of certain paths. To achieve
this goal, the solution is to select and filter routing updates and to modify the attributes of these filtered
routing updates in order to influence the best path selection process.
• The powerful design of BGP enables a flexible filtering of inbound and outbound updates using a large
variety of criteria. The rules for filtering are known as routing policies and use several types of filtering:
o By AS path filters (all routing updates contain a string, which is an aggregate of all traversed
AS. AS path filters are filtering rules for the selection of routes traversing certain AS),
o By prefix lists (routes filtered based on the prefix list),
o By access lists.
The filtering and specific attribute modification is then handled in route maps. The so-called
"distribute-list" enables the filtering of inbound and outbound updates.
When applying a new routing policy, it becomes possible that some information stored in the BGP
router becomes deprecated. This is because the new routing policy will not allow these routing
updates to be received / emitted. Therefore, it becomes necessary to apply BGP connection resets.
• As BGP is an Exterior Gateway protocol, it is designed to scale on large networks. BGP routers may
have to process large routing tables. Some BGP optimizations (such as flap dampening and route
aggregation) can help in significantly reducing the amount of resources required by BGP.

9.2.1 Required BGP Configuration Steps
The tasks in this section are for basic BGP features configuration.
9.2.1.1 Enabling BGP Routing
To enable BGP routing, use the following command in global configuration mode:
CLI(configure)> router bgp <autonomous-system> [vrf <vrf-name>]
CLI(config-router)>
The autonomous-system is an integer value, uniquely designating the AS. The vrf-name is optional. If
not provided the default VRF is used.
The above command creates a BGP routing process. The CLI enters in router configuration mode.
To allow Multiprotocol Extensions, which is the preferred mode as of V5.1R5E1 OneOS software release
(even when IPv6 is not needed), use the following command in router configuration mode:
CLI(config-router)> no bgp default ipv4-unicast
To return to the default mode IPv4-unicast only, use the plain form of the command:
CLI(config-router)> bgp default ipv4-unicast
To select the AFI when Multiprotocol Extensions are activated and enter in address-family configuration
mode, use the following command in router configuration mode.
CLI(config-router)> address-family { ipv4 | ipv6 }
CLI(config-router-af)>
To remove an address-family, use the no form of the command:

CLI(config-router)> no address-family { ipv4 | ipv6 }
The following command in address-family configuration mode (or in router configuration mode without
Multiprotocol Extensions) sets a network as local to this autonomous system. In other words, this network
is de-facto entered into the BGP database. A route-map is applied when you need to apply some filtering
(see 9.2.3.3.3 for route-maps).
CLI(config-router-af)> network <network>/<len> [route-map <map-name>]
CLI(config-router)> network <network>/<len> [route-map <map-name>]
The network will be advertised only if a route exists in the IP routing table matching exactly the network.
To remove the network, use the no form of the command:
CLI(config-router-af)> no network <network>/<len>
CLI(config-router)> no network <network>/<len>

9.2.1.2 BGP Neighbor Configuration
As in any EGP protocol, a BGP router must have its neighbors declared. This task is required.
BGP neighbors are either internal or external.
If a neighbor is internal, the router uses the Interior BGP protocol and the neighbor is in the same AS.
Otherwise, the router is external and managed in a different AS.
To configure BGP neighbors, use the following command in router configuration mode:
CLI(config-router)> neighbor <ip-address>
CLI(config-router-neighbor)>
The above command selects the neighbor for which the configuration is to be entered. The CLI enters in
neighbor configuration mode. Refer to 9.2.1.5 Assignment of Routing Policies and Attributes for the
neighbor configuration commands.
To remove a BGP neighbor, use the no form of the command:
CLI(config-router)> no neighbor <ip-address>
9.2.1.3 BGP Peer Group Creation
A BGP router is usually connected to multiple neighbor routers. In most cases, you may want to apply a
common set of routing policies to these BGP peers. For that purpose, OneOS supports the creation of
peer groups. Peer groups collect routing policies for a set of BGP peers. So, whenever you need to
change a policy for each peers of the BGP router, you only need to do it once, in peer-group configuration.
It is comparable with the concept of PPP virtual template.
The only difference is that you can override parameters defined in peer-group configuration in neighbor
configuration. By default, neighbors member of the peer-group inherit the peer-group parameters unless
re-configured in neighbor configuration.
The configuration of peer groups is achieved in three steps:
1. Peer Group Creation
2. Assignment of routing policy options
3. Definition of neighbors, which are member of the peer group
A BGP peer group is created as follows in router configuration mode:

CLI(config-router)> peer-group <peer-group-name>
CLI(config-router-group)>
The above command selects the peer group for which the configuration is to be entered. The CLI enters in
peer group configuration mode. Refer to 9.2.1.5 Assignment of Routing Policies and Attributes for the peer
group configuration commands.
To remove a BGP peer group, use the no form of the command:
CLI(config-router)> no peer-group <peer-group-name>
9.2.1.4 Neighbor Membership Configuration in a Peer Group
Once you have created the peer group and some associated parameters, return to the router configuration
mode, select a neighbor and enter the peer group name, which the neighbor belongs to:
CLI(config-router-group)> exit
CLI(config-router-neighbor)> peer-group <peer-group-name>
To remove the peer group membership, use the no form of the command:
CLI(config-router-neighbor)> no peer-group <peer-group-name>

9.2.1.5 Assignment of Routing Policies and Attributes
The same routing attributes and filters are provided in neighbor configuration mode and in peer group
configuration mode. The first command is mandatory (others are not, default values can apply).
To specify a BGP neighbor, use the following command in neighbor / peer-group configuration mode:
CLI(config-router-neighbor)> remote-as <number>
CLI(config-router-group)> remote-as <number>
To remove the BGP neighbor, use the no form of the command:

CLI(config-router-neighbor)> no remote-as <number>
CLI(config-router-group)> no remote-as <number>
To associate a description with a neighbor / peer-group, use the following command in neighbor / peer-
group configuration mode:
CLI(config-router-neighbor)> description <text>
CLI(config-router-group)> description <text>
To remove the description, use the no form of the command:

CLI(config-router-neighbor)> no description
CLI(config-router-group)> no description
To allow internal BGP sessions to source BGP TCP connections with the IP address of a specified
operational interface, use the following command:
CLI(config-router-neighbor)> update-source <interface-type/unit>
CLI(config-router-group)> update-source <interface-type/unit>
To come back to the best local address (the closest), use the no form of the command:
CLI(config-router-neighbor)> no update-source
CLI(config-router-group)> no update-source
To allow BGP sessions, even when the neighbor / peer group is not on a directly connected segment, use
the following command. Use the optional parameter to limit the maximum hop count to be taken into
account (default value is 1):
CLI(config-router-neighbor)> ebgp-multihop [<max-hop-count:1-255>]
CLI(config-router-group)> ebgp-multihop [<max-hop-count:1-255>]
To come back to the default behavior (1 hop), use the no form of the command command:
CLI(config-router-neighbor)> no ebgp-multihop
CLI(config-router-group)> no ebgp-multihop

Warning: the next required steps commands must be entered in neighbor configuration mode
under address-family configuration mode when Multiprotocol Extensions are activated. Otherwise,
they can be entered directly in neighbor or peer-group configuration mode.
Note: prior using the next command, the neighbor must have been declared as described in 9.2.1.2 and
configured as described in 9.2.1.5 above.
To enter in neighbor configuration mode under address-family (see 9.2.1.1), use the following command:
CLI(config-router-af)> neighbor <ip-address> activate
CLI(config-router-af-neighbor)>
To allow a BGP speaker (the local router) to send the default route (0.0.0.0 or ::/0) to a neighbor /
peer-group for use as a default route, use the following command:
CLI(config-router-af-neighbor)> default-originate [route-map <map-name>]
CLI(config-router-neighbor)> default-originate [route-map <map-name>]
CLI(config-router-group)> default-originate [route-map <map-name>]
To remove the default route, use the no form of the command:

CLI(config-router-af-neighbor)> no default-originate [route-map]
CLI(config-router-neighbor)> no default-originate [route-map]
CLI(config-router-group)> no default-originate [route-map]
To specify that the COMMUNITIES attribute is to be sent to the neighbor / peer group at this IP address,
CLI(config-router-af-neighbor)> send-community
CLI(config-router-neighbor)> send-community
CLI(config-router-group)> send-community
To stop sending the COMMUNITIES attribute, use the no form of the command:
CLI(config-router-af-neighbor)> no send-community
CLI(config-router-neighbor)> no send-community
CLI(config-router-group)> no send-community

To limit the number of prefixes allowed from a neighbor / peer-group, use the following command.
CLI(config-router-af-neighbor)> maximum-prefix <maximum> [threshold]
[restart <restart-interval>] [warning-only]
CLI(config-router-neighbor)> maximum-prefix <maximum> [threshold]

CLI(config-router-group)> maximum-prefix <maximum> [threshold]

With:
o maximum-prefix <maximum>. This is the maximum number of prefixes allowed from the
neighbor.
If the maximum-prefix <maximum> attribute is omitted, the maximum number of received
prefixes will be limited to:
 10000 for IPv4 routes.
 2500 for IPv6 routes.
 Note that no warning messages will be generated, that these rules apply.
o threshold. This is an optional integer value that specifies at which percentage of the
configured <maximum> the OneOS device starts generating warning messages. It ranges
from 1 to 100 percent, the default is 75 percent.
For example, if the maximum-value configured is 20 and the threshold 60, the router generates
warning messages when the number of BGP learned routes from the neighbor exceeds 60
percent of 20 (i.e. 12).
o restart <restart-interval>. This is an optional time interval, expressed in minutes,
after which a peering session is re-established. It ranges from 1 to 65535 minutes; the default
value is 5 minutes. If the parameter is set to no restart, BGP is kept down and has to be re-
started manually; otherwise BGP is re-started after timeout expiration.
o warning-only. This option allows the router to generate a log message when the maximum
number of prefixes is exceeded, instead of terminating the peering session. The message is
sent once.
When this option is omitted, and the maximum number of prefixes is exceeded, the neighbor /
peer-group is disconnected and the BGP process is stopped. The optional restart parameter
can be used to automatically restart the process.
To remove the limitation, use the no form of the command:

CLI(config-router-af-neighbor)> no maximum-prefix <maximum> [threshold]
CLI(config-router-neighbor)> no maximum-prefix <maximum> [threshold]

CLI(config-router-group)> no maximum-prefix <maximum> [threshold]

BGP uses the AS path to discover routing loops. In some network topologies, access routers exchange
routing information via iBGP (in the same AS), but communicate through a backbone routing domain with a
different AS number. Routing updates coming from the remote access routers have AS paths formed as
follows: AS(customer),AS(backbone). Such received update is normally dropped, because an update
for an intra-AS route is learnt via another AS. By default, no loop is permitted. The following command
permits loops by providing the number of times the router’s own AS number can appear in the AS path of
received updates (value is between 1 and 10; default value is 3).
CLI(config-router-af-neighbor)> allowas-in [<nb-of-loops>]
CLI(config-router-neighbor)> allowas-in [<nb-of-loops>]
CLI(config-router-group)> allowas-in [<nb-of-loops>]

To come back to default behavior (no loop allowed), use the no form of the command:
CLI(config-router-af-neighbor)> no allowas-in
CLI(config-router-neighbor)> no allowas-in
CLI(config-router-group)> no allowas-in
To apply a route map to incoming or outgoing routes:

CLI(config-router-af-neighbor)> route-map <map-name> { in | out }
CLI(config-router-neighbor)> route-map <map-name> { in | out }
CLI(config-router-group)> route-map <map-name> { in | out }
To remove the route-map, use the no form of the command:

CLI(config-router-af-neighbor)> no route-map <map-name> { in | out }
CLI(config-router-neighbor)> no route-map <map-name> { in | out }
CLI(config-router-group)> no route-map <map-name> { in | out }
To finalize the neighbor / peer-group configuration and return in address-family configuration mode or in
BGP router configuration mode, use the following command:
CLI(config-router-af-neighbor)> exit
CLI(config-router-af)>
CLI(config-router-neighbor)> exit
CLI(config-router)>
CLI(config-router-group)> exit
CLI(config-router)>
Note: there are additional parameters available. Refer to following sections for their configuration.
9.2.1.6 Disabling a Peer or Peer Group
To disable an existing BGP neighbor or a peer group, use the shutdown command in neighbor or peer
CLI(config-router-neighbor)> shutdown
CLI(config-router-group)> shutdown
To re-enable the neighbor or peer-group, use the no form of the command:

CLI(config-router-neighbor)> no shutdown
CLI(config-router-group)> no shutdown

9.2.2 Additional BGP Configuration Steps
9.2.2.1 Configuring TCP MD5 signature option for BGP sessions
This TCP extension described in RFC 2385 allows protecting BGP sessions against spoofing attacks by
including an MD5 digest acting as a signature in every TCP segment of a session.
To enable this option for a BGP neighbor, use the following command in neighbor configuration mode or in
peer-group configuration mode:
CLI(config-router-neighbor)> password <password> [<0-1>]
CLI(config-router-group)> password <password> [<0-1>]
Where password is a character string representing the clear text or encrypted password. The optional
parameter specifies if the clear text password should be encrypted (0) or if the password string represents
the encrypted password (1). If the optional argument is not provided, the password remains stored in the
configuration in clear text.
To disable this option use the no form of the command:
CLI(config-router-neighbor)> no password
CLI(config-router-group)> no password
Use the following command to see if this option is enabled for a given neighbor:
CLI> show ip bgp neighbors 192.168.2.2
BGP neighbor is 192.168.2.2, remote AS 200, local AS 1, external link
Member of peer-group bulls for session parameters
BGP version 4, remote router ID 98.0.0.1
TCP MD5 signature option is set for this neighbor
BGP state = Established, up for 03:00:01
Last read 00:00:01, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received (old and new)
Address family IPv4 Unicast: advertised and received
Received 184 messages, 0 notifications, 0 in queue
Sent 184 messages, 0 notifications, 0 in queue
Route refresh request: received 0, sent 0
Minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast

bulls peer-group member
1 accepted prefixes
Connections established 1; dropped 0

Local host: 192.168.2.1, Local port: 1026
Foreign host: 192.168.2.2, Foreign port: 179
Nexthop: 192.168.2.1
Read thread: on Write thread: off
The following command provides information about the number of TCP segments sent and received with
the TCP MD5 signature option set.
CLI> show tcp statistics
TCP statistics:
IN: 4679 total
0 checksum error, 0 bad offset, 0 too short
3147 packets (37045 bytes) in sequence
0 dup packets (0 bytes)
0 partially dup packets (0 bytes)
0 out-of-order packets (0 bytes)
0 packets (0 bytes) with data after window
0 packets after close
0 dup ack packets, 0 ack packets with unsend data
3164 ack packets (39070 bytes)
194 md5 packets, 0 invalid md5
OUT: 4857 total, 0 urgent packets
3 control packets
3162 data packets (39068 bytes)
0 data packets (0 bytes) retransmitted
1692 ack only packets (915 delayed)
373 md5 packets
6 connections established (including 3 initiated, 3 accepted)
8 connections closed (including 0 dropped, 0 embryonic dropped)

0 total rxmt timeout, 0 connections dropped in rxmt timeout

291 keepalive timeout, 0 keepalive probe, 0 connections dropped in keepalive
9.2.2.2 Load Sharing
By default, BGP tries to select the best path for a route to a network by using several selection criteria.
They are, in order of priority:
1. Prefer the highest weight
2. Prefer the highest local preference
3. Prefer the shortest AS path
4. Prefer routes whose origin is IGP over EGP. Prefer EGP over Incomplete origin
5. Prefer the lowest MED
6. Routes learnt via BGP are indicated via a next-hop. The metric of the routes to the different
next hop are compared; the lowest metric is preferred.
If at this stage of the path selection algorithm, some routes are considered equal, they can be all installed
in the routing table, only if load sharing is enabled. To activate load sharing with BGP, the maximum
number of equal routes must be entered; default: 1, maximum: 6.
CLI(config-router-af)> maximum-paths <nb-of-routes>
CLI(config-router)> maximum-paths <nb-of-routes>
nb-of-routes designates the maximum number of equal routes that are allowed to be transmitted to the
routing table. Load sharing is managed with BGP routes like static routes (see "Static Routes" section in
"IPv4 Features" chapter of "OneOS – Basic IP User Guide" document).
It is also possible to set the same priority to eBGP and iBGP routes so as to apply the load sharing among
the various routes in the BGP router. To activate load sharing with eBGP and iBGP, the maximum number
of equal routes must be entered; default: 1, maximum: 6.
CLI(config-router-af)> maximum-paths eibgp <nb-of-routes>
CLI(config-router)> maximum-paths eibgp <nb-of-routes>
To deactivate load sharing with BGP, use the no form of the command:
CLI(config-router-af)> no maximum-paths
CLI(config-router)> no maximum-paths
9.2.2.3 Backdoor Routes
A backdoor route is a special network that the BGP router should use for routing, but the router should not
advertise the route. A backdoor route is entered as follows in address-family or router configuration mode:
CLI(config-router-af)> network <network>/<len> backdoor
CLI(config-router)> network <network>/<len> backdoor
9.2.2.4 Administrative Distance
The administrative distance defines the preference for routes that are learnt via different routing protocols.
To modify the distance values, use the following command in router configuration mode:
CLI(config-router)> distance bgp <ebgp> <ibgp> <local>
Where:
ebgp is the administrative distance for routes learnt via eBGP. Default: 20.
ibgp is the administrative distance for routes learnt via iBGP. Default: 200.

local is the distance for routes advertised using the network command. Default: 200.
To come back to default distance values, use the no form of the command:
CLI(config-router)> no distance bgp
9.2.2.5 Route Redistribution
Route redistribution is an alternative to the network command to advertise networks using BGP. It
consists in injecting connected, static or IGP routes into BGP database. The injected routes are advertised
whenever BGP scans its database (periodical process).
To advertise directly connected network routes via BGP, use the following command in address-family or
CLI(config-router-af)> [no] redistribute connected [metric <metric>]
CLI(config-router)> [no] redistribute connected [metric <metric>]

To advertise static routes via BGP, use the command:

CLI(config-router-af)> [no] redistribute static [metric <metric>]
CLI(config-router)> [no] redistribute static [metric <metric>]

To advertise routes learned through an external protocol via BGP, use the command:
CLI(config-router-af)> [no] redistribute { rip | ospf } [metric <metric>]
CLI(config-router)> [no] redistribute { rip | ospf } [metric <metric>]

metric argument is the metric used to advertise the redistributed routes. name permits the filtering of
certain routes. See 9.2.3.3.3 for details on route maps.
Use the no form of the commands to remove route redistribution.
9.2.2.6 Modification of BGP Routing
9.2.2.6.1 Disabling AS Path Comparison
RFC 1771 (the IETF document defining BGP) recommends the use of the "tie-breaker" decision algorithm,
which does not include AS-path as part of the decision process. By default, OneOS software considers the
AS-path as a part of the decision algorithm.
The following command makes it possible to modify the decision algorithm, so that the router does not
consider AS-path during the decision process, thus making the router compliant with the IETF
recommendation. To prevent the router from considering the AS-path length when selecting a route, use
the following command in router configuration mode:
CLI(config-router)> [no] bgp bestpath as-path ignore
Use the no form of the command to include again AS-path as part of the decision process.

9.2.2.6.2 Enabling Router ID Comparison
By default, to minimize route-flap OneOS software selects the path that was received first (the oldest one)
when receiving routes with identical attributes.
The following command makes it possible to modify the decision algorithm, so that the router does not
select the oldest route but selects the route with the lowest router ID when receiving routes with identical
attributes:
CLI(config-router)> [no] bgp bestpath compare-routerid
Use the no form of the command to return to the oldest route choice.
9.2.2.6.3 Configuration of Router ID
By default, the address of the first operational interface is taken as BGP router IP address. This might be
inconvenient, as you are not able to predict the IP address of the router.
To force the IP address of the BGP router, use the following command in router configuration mode:
CLI(config-router)> router-id <A.B.C.D>
Note: the router ID is also important to select the routes. When all routes have the same attributes and
router ID comparison is enabled, the route with the lowest router ID is elected.
9.2.2.6.4 Configuration of Default Local Preference
The local preference is an attribute part of the BGP routing decision process. By default, the local
preference is 100. To set a different default local preference, use the following command in router
configuration mode:
CLI(config-router)> [no] bgp default local-preference <value>
The lower value is, the lower the preference is.

Use the no form of the commands to come back to the default local preference.
You can also use route maps to change the default local preference for specific paths in route map
configuration mode:
CLI(config-route-map)> set local-preference
9.2.2.6.5 Disabling Default Next-Hop Processing
Routers can receive routing updates, for which the next-hop router to be used is unknown. This happens
when the network is not fully meshed (FR, ATM networks). The solution is to substitute the next-hop router
address by a router that can be directly reached by the router (an adjacent router). There are two ways to
manage this next-hop processing:
• Provide a specific address to be used instead of the next-hop address (manually configuring each
address).
• Use a route map to specify that the address of the remote peer for matching inbound routes, or the
local router for matching outbound routes (automatic method).
9.2.2.6.5.1 Next-Hop Setting Using Self Address
To disable next-hop processing and provide a specific address to be used instead of the next-hop address,
use the following commands in neighbor or peer-group configuration mode:
CLI(config-router-af-neighbor)> [no] next-hop-self
CLI(config-router-neighbor)> [no] next-hop-self
CLI(config-router-group)> [no] next-hop-self

Using this command disables next-hop processing on BGP updates to a neighbor; the router is forced to
advertise updates with its peering address instead of the router address specified in its database. In other
words, routers receiving this route update use the current router as next hop for that received route.
Use the no form of the command to re-enable next-hop processing.
9.2.2.6.5.2 Next-Hop Setting Using a Route Map
To configure the neighbor peering address to be used for the next hop address, use the following
command in route map configuration mode:
CLI(config-route-map)> set ip next-hop <ip-address>
Note: for further information about route maps, refer to 9.2.3.3.3.

With an inbound route map of a BGP peer, it sets the next hop of the matching routes to be the neighbor
peering address, overriding any third-party next hops and allowing the same route map to be applied to
multiple BGP peers to override third-party next hops.
With an outbound route map of a BGP peer, it sets the next hop of the received address to the peering
address of the local router, disabling the next hop calculation.
The next hop must be an adjacent router.
9.2.2.6.6 Multi Exit Discriminator Metric (MED) Configuration
BGP uses the Multi Exit Discriminator (MED) metric as a criterion to external neighbors about preferred
paths. Use the following command in route map configuration mode:
CLI(config-route-map)> set metric <number>
The command sets the metric to the specified number for matching routes.
9.2.2.6.6.1 Configuring the Router to Consider a Missing MED as Worst Path
To configure the router to consider a path with a missing MED attribute as the worst path, use the following
command in router configuration mode:
CLI(config-router)> [no] bgp bestpath med missing-as-worst
The command configures the router to consider a missing MED as having a value of infinity, making the
path without a MED-value the least desirable path.
The no form of the command re-enables the default behavior, i.e. the MED is considered as 0 (best path).
9.2.2.6.6.2 Path Selection Based on MED from Other AS
The route selection process compares (among other criteria) the MED of all different paths from the same
AS. If you wish to enable MED comparison of paths received from any AS, use the following command in
CLI(config-router)> [no] bgp always-compare-med
Use the no form of the command to come back to default behavior (compare from the same AS).
9.2.2.6.6.3 MED-Based Routing in Confederations
The concept of AS confederation is later described in this document in section 9.2.4.2. To configure the
router to consider the MED value when choosing a path in confederations, use the following command in
CLI(config-router)> [no] bgp bestpath med confed
The above command configures the router to consider the MED in choosing a path from among those
advertised by different sub-AS within a confederation.
Use the no form of the command to come back to default behavior.

The comparison between MED is only made if there are no external AS in the path (an external AS is an
AS that is not within the confederation). If there is an external AS in the path, then the external MED is
passed transparently through the confederation, and the comparison is not made.
To configure the router to use the MED to select the best path among paths advertised by a single sub-AS
within a confederation, use the following command in router configuration mode:
CLI(config-router)> [no] bgp deterministic-med
The above command configures the router to compare the MED variable when choosing among routes
advertised by different peers in the same autonomous system.
Note that if bgp always-compare-med is enabled, all paths are fully comparable, including those from
other AS's in the confederation, even if bgp deterministic-med is also enabled.
Use the no form of the command to come back to default behavior.
9.2.2.6.7 Administrative Weight
A weight is a number from 0 to 65535 used as a criterion for the route selection process. The path with the
highest weight is preferred. This attribute is local to the router. By default, any path originated by the router
has a weight of 32768 (routes manually configured in neighbor or peer-group configuration mode), while
others have a weight worth 0.
To prefer certain routes learned from a neighbor or a peer-group and assign weights on a per-neighbor or
per-peer-group basis, use the following command in neighbor or peer-group configuration mode:
CLI(config-router-neighbor)> weight <weight>
CLI(config-router-group)> weight <weight>
To restore default weight values:

CLI(config-router-neighbor)> no weight
CLI(config-router-group)> no weight
Alternatively, you can selectively set the weight attribute for updates matching a route map, beginning in
route-map configuration mode:
CLI(config-route-map)> set weight <weight>
If weight is configured for both route maps and neighbors or peer-group, then the weight set in route map
prevails over the weight defined in neighbor or peer-group configuration mode.
9.2.2.7 BGP Timer Configuration
BGP does not broadcast message to exchange routing information, instead BGP uses a connection-
oriented communication protocol, based on TCP. Keepalive messages are sent on a periodical basis
(keepalive period, default 60 sec) to test neighbor presence. If the peer does not respond after hold-
time (default 180 sec), the peer is considered as unavailable.
It should be noted that the hold-time value is negotiated between BGP peers, by taking the smallest of
both peer hold-time values. To change keepalive and hold-time values globally to the router, use the
following command in BGP router configuration mode:
CLI(config-router)> timers bgp <keepalive> <hold-time>
To restore default timers' values, use the following command:

CLI(config-router)> no timers bgp
If you wish to adjust timers only for a specific neighbor (resp. peer group), enter in neighbor (resp. peer
group) configuration mode and enter:
CLI(config-router-neighbor)> timers <keepalive> <hold-time>
CLI(config-router-group)> timers <keepalive> <hold-time>
All values above are provided in seconds.

Timers configured for a specific neighbor or peer group override timers configured for all BGP neighbors.
To restore the default timers' values for a BGP neighbor or a peer group, use the following commands:
CLI(config-router-neighbor)> no timers
CLI(config-router-group)> no timers
9.2.3 Routing Policies
In BGP, routing policies are implemented by using filters to control the level of routing information that is
exchanged by an autonomous system with its neighbors. Filtering is handled by:
• Route identification based on criteria settings to differentiate routes from each other. Such criteria can
be based on the route IP prefix, the autonomous system from which the route was originated, an AS
path or an attribute value inside a route.
• Permitting or denying routes depends on the filtering rules that have been setup for that juncture. A
permitted route is accepted without change or can be submitted for attributes modification to change
its behavior. A denied route is simply discarded.
• Attribute modification for a permitted route can be done if it is necessary to change the decision
process.
The route filtering process will use the list of all defined criteria and will stop the process when a route
matches filtering criteria. The order in which the criteria in the list are defined becomes very important.
BGP inbound or outbound advertisements filtering can be handled in two ways:
• AS-path filters can be used, by means of the ip as-path access-list command in global
configuration mode and the neighbor filter-list command
• Use access or prefix lists, by means of the distribute-list command in neighbor configuration
mode.
9.2.3.1 AS Path Filter Definition
In addition to filtering routing updates based on network addresses, you can specify an access list filter on
both incoming and outbound updates based on the BGP AS paths. Each filter is an access list based on
regular expressions.
Regular expressions (regexp) are based on “POSIX 1003.2” and enable you to search and filter strings
within AS paths. To achieve such filtering, the regular expression matches the input string against a
pattern. The pattern is composed of a combination of:
• Characters: they must be matched exactly in the string.
• Symbols (called atoms or pieces): they are not matched themselves. They provide a parameter to
regexp for string search.
Atoms:
• "." Matches any character
• "^" The match must be done at the beginning of the string
• "$" The match must be done at the end of the string
• "\" Matches the character following '\' (useful to match characters normally used as atoms or pieces)
• "_" Matches a punctuation symbol ("," or "{" or "}"). When applied to AS path filtering, this means
somewhere in the middle, the beginning or the end of the input string. ("_100_" matches a string
where AS 100 is included as a transit AS)
Pieces:
• "*" Matches any following string, regardless of the preceding character ("^100.*" means the route is
originated by AS 100)
• "+" Matches string if there is at least one occurrence of the preceding character

• "?" Matches if the preceding character is present in the string or no character is present at all.
Example: "xy?z" matches "xyz" or "xz" but not "xaz"
To do such filters, define an AS path access list and apply it to updates to and from particular neighbors.
9.2.3.2 Community List
In the context of BGP a community is a group of destinations that share some common attributes. A
community is not restricted to a network neither to an autonomous system. Communities are used to
simplify routing policies by identifying routes based on a logical property instead of an IP prefix or an
autonomous number.
To manage communities BGP uses the COMMUNITIES attribute that can take a numeric value from 1 to
4294967295 (or the same in the AA:NN format). A few community values have pre-defined names; they
are described below (pre-defined names are case sensitive):
o internet (0:0): advertise this route to Internet community. Note that all routers belong to it
o no-export (65535:65281): no route advertising to eBGP peers
o no-advertise (65535:65282): no route advertising to any peer
o local-AS (65535:65283): no route advertising outside the local autonomous system
Communities are a handy way to control how routing information is carried from peer to peer. To use
communities you will need to define community lists using the following command:
CLI(configure)> ip community-list <commun-list-number> { permit | deny }
{ <1-4294967295> | <high-community-number>:<low-community-number>
| local-AS | internet | no-advertise | no-export }
Where community-list-number is a number ranging from 1 to 99 that identifies one or more

permit/deny groups of communities (up to 4 community numbers can be entered in one command).
9.2.3.3 Routing Policies Applied to Neighbors
9.2.3.3.1 Route Filtering
As we are dealing with network addresses this can be done by using distribute list filters based either on
an access list or a prefix list and apply it to the updates received from a specific neighbor.
To filter BGP routing updates, use the following command in neighbor / peer-group configuration mode:
CLI(config-router-af-neighbor)> distribute-list <acl-name> { in | out }
CLI(config-router-neighbor)> distribute-list <acl-name> { in | out }
CLI(config-router-group)> distribute-list <acl-name> { in | out }
To stop filtering BGP routing updates, use the no form of the command:
CLI(config-router-af-neighbor)> no distribute-list <acl-name> { in | out}
CLI(config-router-neighbor)> no distribute-list <acl-name> { in | out }
CLI(config-router-group)> no distribute-list <acl-name> { in | out }
The neighbor prefix-list router configuration command can be used as an alternative to the neighbor
distribute-list router configuration command, but you cannot use both commands to configure the same
BGP peer in any specific direction. These two commands are mutually exclusive, and only one command
(neighbor prefix-list or neighbor distribute-list) can be applied for each inbound or outbound direction.
Prefix-list use is defined in 7.2.7.2 and access-lists use for route filtering in 7.2.7.1.

9.2.3.3.2 AS Path Filtering
Filtering routes based on AS path information becomes very handy when filtering is needed for all routes
for the same or multiple AS’s. Defining access lists based on patterns as described in 9.2.3.1 instead of
using a long list of routes defined on a prefix basis is much more efficient.
Path filtering configuration is done by submitting the following commands.
Step 1: In global configuration mode, define a BGP-related access list.
CLI(configure)> ip as-path access-list <acl-name> { permit | deny }
<as-regular-expression>
Step 2: In global configuration mode, enter in BGP router configuration mode.

CLI(configure)> router bgp <autonomous-system>
Step 3: In router configuration mode, enter in neighbor or peer group configuration mode.
CLI(config-router)> address-family <af>
CLI(config-router-af)> neighbor <ip-address>
CLI(config-router-af-neighbor)>

CLI(config-router-neighbor)>
CLI(config-router)> peer-group <name>

CLI(config-router-group)>
Step 4: In neighbor or peer group configuration mode, establish the BGP filter.
CLI(config-router-af-neighbor)> [no] filter-list <acl-name> { in | out }
CLI(config-router-neighbor)> [no] filter-list <acl-name> { in | out }
CLI(config-router-group)> [no] filter-list <acl-name> { in | out }
To stop filtering BGP routes, use the no form of the command.
9.2.3.3.3 Route Map
With BGP, route maps are used to control and modify routing information. They can also be used to filter
specific routes and to define criteria by which routes are distributed between domains.
To define a route map and enter in route map configuration mode, use the following command in global
configuration mode:
CLI(config-route-map)>
map-name is a string identifying the route map.

sequence-number is an integer indicating the relative position compared to other instances that define
the route-map.
When BGP applies a route-map instance to routing updates, it applies the lowest instance first. If the set of
conditions is not met, the next instance is used and so on until either a condition is met or there are no
more conditions to apply. Conditions are expressed using the match command that is defined as follows:
CLI(config-route-map)> match as-path <as-path-access-list-name>
CLI(config-route-map)> match community <community-list-number>
[exact-match]
{ <access-list-number>
| prefix-list <list-name> }
CLI(config-route-map)> match metric <0-4294967295>

Filtering updates as well as modifying attributes can be done on a per-neighbor basis by using route maps.
AS path, network numbers and community matching can be used but in order to be effective, each
requires a corresponding as-path access-list, access-list and community-list command.
Route maps can be applied to both inbound (to accept route) or outbound updates.
Once filtering criteria are defined, you may wish to modify routing attributes.
To select specific community to add or replace in routing updates, use the following command:
CLI(config-route-map)> set community { add | replace } { <1-4294967295>
| <high-community-number>:<low-community-number>
| local-AS | internet | no-advertise | no-export }
To suppress the community attribute, use the following command:

CLI(config-route-map)> set community none
To delete a community list, use the following command:

CLI(config-route-map)> set comm-list <1-99> delete
To force the next hop IP address, use the following command:

CLI(config-route-map)> set ip next-hop <ip-address>
To change the default local preference, use the following command:

CLI(config-route-map)> set local-preference <0-4294967295>
To set or increment/decrement the route metric, use the following command:

CLI(config-route-map)> set metric [+|-]<metric>
To filter updates using a pre-defined route map use the following command when in neighbor or in peer-
CLI(configure-router-af-neighbor)> [no] route-map <map-name> { in | out }
CLI(configure-router-neighbor)> [no] route-map <map-name> { in | out }
CLI(configure-router-group)> [no] route-map <map-name> { in | out }
9.2.4 BGP Optimizations
In this section, we described features, which help a network engineer in simplifying and enhancing device
configuration and performance.
9.2.4.1 Configuration of Aggregate Address
Aggregate routes are supported to reduce the routing table size. If several routes are exchanged for nodes
in the same address range, the set of addresses is aggregated if they are in the same sub-network
(address and mask). The route to the network address is exchanged rather than each route to each node
in order to reduce the number of exchanged routes.
You can configure aggregate routes in BGP either by redistributing an aggregate route into BGP or by
using the conditional aggregation feature described below. An aggregate address will be added to the
BGP table if there is at least one more specific entry in the BGP table.
To allow the creation of address aggregates, use one or more of the following commands in address-family
or router configuration mode.
To create an aggregate entry in the BGP routing table, use the following command. The router will
advertise the prefix, which summarizes a number of more specific routes. The path information is lost and
is the same as if the route was originated from the router AS.
CLI(config-router-af)> [no] aggregate-address <network>/<len>
CLI(config-router)> [no] aggregate-address <network>/<len>

To avoid loosing the path information, use the following command. The router will generate the
autonomous system set path information and will advertise the prefix and the more specific routes and
include as-set information in the path information of updates.
CLI(config-router-af)> aggregate-address <network>/<len> as-set
CLI(config-router)> aggregate-address <network>/<len> as-set
To advertise summary addresses only, use the following command. The router will advertise only the
prefix, which summarizes a number of more specific routes and will suppress these more specific routes
from updates.
CLI(config-router-af)> aggregate-address <network>/<len> summary-only
CLI(config-router)> aggregate-address <network>/<len> summary-only
To avoid loosing the path information and to advertise summary addresses only, use the following
command:
CLI(config-router-af)> aggregate-address <network>/<len> as-set
summary-only
CLI(config-router)> aggregate-address <network>/<len> as-set summary-only
9.2.4.2 AS Confederation
Routers in a carrier network can often be managed in a single AS. However, BGP requires that all of the
iBGP speakers (routers inside an AS) be fully meshed. This mesh may cause scalability issues, extra
complexity and unnecessarily large routing tables.
This problem can be circumvented using AS confederations. To reduce the mesh a large autonomous
system (AS) is split in several sub-AS. All sub-AS are grouped into an AS confederation and the AS
confederation is seen as a conventional AS by outside neighbor routers.
Instead of a full mesh in AS confederation, routers inside the sub-AS are only connected with their eBGP
neighbors and with all routers inside the sub-AS. The objective of reducing mesh complexity and routing
table size is thus achieved. Even though routers inside an AS confederation use eBGP, routing information
is exchanged as if they were iBGP neighbors, thus protecting routing attributes such as next-hop, MED
and local preference.
To configure a BGP confederation, you must specify a confederation identifier. External routers to the
confederation interpret the group of autonomous systems as a single autonomous system with the
confederation identifier representing the autonomous system number.
To configure a BGP confederation identifier, use the following command in router configuration mode. To
remove the BGP confederation identifier, use the no form of the command.
CLI(config-router)> bgp confederation identifier <as-number>
CLI(config-router)> no bgp confederation identifier [<as-number>]
In order to handle neighbors from other autonomous systems (within the confederation; up to 4) as eBGP
peers (instead of iBGP neighbors), use the following command in router configuration mode to specify the
autonomous systems that belong to the confederation:
CLI(config-router)> bgp confederation peers <AS1> [<AS2> [<AS3> [<AS4>]]]
Use the no form of the above command to remove peers from the confederation.

9.2.4.3 Route Reflector Configuration
Route reflectors are an alternative solution to the use of AS confederations. The objective remains
identical, i.e. a reduction of the iBGP mesh.
A reflector is a BGP router that redistributes between non-meshed routers, routes that should be learned
via iBGP.
The internal peers of the route reflector are divided into two groups: client peers and all the other routers in
the autonomous system (non-client peers). A route reflector reflects routes between these two groups.
The route reflector and its client peers form a cluster. The non-client peers must be fully meshed with each
other, but the client peers need not be fully meshed. The clients in the cluster do not communicate with
iBGP speakers outside their cluster.
When the route reflector receives an advertised route, the route advertisement is as follows:
• A route from an external BGP speaker is advertised to all clients and non-client peers.
• A route from a non-client peer is advertised to all clients.
• A route from a client is advertised to all clients and non-client peers.
To configure a route reflector and its clients, use the following command in neighbor configuration mode or
in peer-group configuration mode:
CLI(config-router-af-neighbor)> [no] route-reflector-client
CLI(config-router-neighbor)> [no] route-reflector-client
CLI(config-router-group)> [no] route-reflector-client
To remove the route reflector, use the no form of the above command.
The above commands configure the local router as a BGP route reflector and the specified neighbor /
peer-group as a client. For failure resilience, several route reflectors can be declared to avoid the reflector
being the most probable point of failure. If there are several route reflectors, they all have the same set of
clients.
To distinguish updates coming from several reflectors, use the following command in router configuration
mode to assign a cluster ID for that router (you do not need to set this cluster ID when there is a single
reflector). Cluster ID is entered as an IP address string.
CLI(config-router)> bgp cluster-id <IP-address>
To remove the cluster ID, use the no form of the following command:
CLI(config-router)> no bgp cluster-id [<IP-address>]
When using route reflectors, clients are only required to be connected to the reflector(s). Clients do not
need to be meshed. If they are, clients can exchange routes using iBGP, which are later advertised by the
reflector(s). To avoid this unnecessary behavior, you can disable client-to-client reflection using the
following command:
CLI(config-router)> no bgp client-to-client reflection
To re-enable client-to-client reflection, use the plain form of the following command:
CLI(config-router)> bgp client-to-client reflection
9.2.4.4 Route Flap Dampening
When using dynamic routing protocols, it becomes possible to advertise routes availability and
unavailability, which enhances the robustness of routing. However, this also opens the door to undesirable
effects, i.e. flapping routing. Flapping routes are unstable routes, which become up and down at an
unacceptable pace. Therefore, the BGP protocol advertises the presence and disappearance of a route
with poor quality. It yields to:
• Packet loss and unnecessary routing: packets are routed to that path and get either lost or re-routed
to an available path if the route turns out unavailable during packet transit.

• Unnecessary overhead in managing routes: the route ups and downs generate BGP add/withdraw
messages, which require bandwidth.
BGP flap dampening is an optional algorithm within BGP that evaluates the route quality (by accounting
route up and downs) and discards poor quality routes. This makes sure that this route is not further
propagated by BGP.
The route quality is evaluated as follows: a router with the "flap dampening" feature enabled notices that a
route is flapping. The route is recorded in "history state" by the router as having a default penalty of 1,000.
Whenever the route flaps again, a new penalty is added cumulatively. If the penalty reaches a threshold
(suppress limit), the router stops advertising/redistributing this route.
When not flapping during a half-life period (15 minutes by default), the penalty decreases by half. The
penalty evaluation process takes place every 5 sec. The route can be re-used when the penalty is under
the reuse limit. The max-suppress limit is the maximum time during which a route can be suppressed
(default = 4 times half life).
9.2.4.4.1 Enabling Route Dampening
To enable BGP route dampening, use the following command in router configuration mode:
CLI(config-router)> [no] bgp dampening
To disable BGP route dampening, use the no form of the command.

To change the default values of various dampening factors, use the following command in router
configuration mode:
CLI(config-router)> [no] bgp dampening <half-life> [<reuse> <suppress>
<max-suppress>]
To come back to the default values, use the no form of the command.
9.2.4.4.2 BGP Flap Dampening Statistics
The following commands only apply to IPv4 / IPv6 routes in the history state (i.e. flapping routes).
BGP flap statistics for IPv4 paths matching the regular expression:
CLI> show ip bgp flap-statistics regexp <regexp> [vrf <vrf-name>]
BGP flap statistics for IPv6 paths matching the regular expression:
CLI> show ipv6 bgp flap-statistics regexp <regexp> [vrf <vrf-name>]
BGP flap statistics for IPv4 paths matching the filter list:
CLI> show ip bgp flap-statistics filter-list <list> [vrf <vrf-name>]
BGP flap statistics for IPv6 paths matching the filter list:
CLI> show ipv6 bgp flap-statistics filter-list <list> [vrf <vrf-name>]
BGP flap statistics for IPv4 routes matching exactly a network:

CLI> show ip bgp flap-statistics prefix <network>/<len> [vrf <vrf-name>]
BGP flap statistics for IPv4 routes matching a network and associated sub-networks:
CLI> show ip bgp flap-statistics prefix <network>/<len> longer-prefixes
[vrf <vrf-name>]
BGP flap statistics for IPv6 routes matching a network and associated sub-networks:
CLI> show ipv6 bgp flap-statistics prefix <network>/<len> longer-prefixes
[vrf <vrf-name>]
BGP flap statistics for IPv4 routes matching the prefix list:
CLI> show ip bgp flap-statistics prefix-list <list-name>

BGP flap statistics for IPv6 routes matching the prefix list:
CLI> show ipv6 bgp flap-statistics prefix-list <list-name>
BGP flap statistics for a given IPv4 route:

CLI> show ip bgp flap-statistics route <ip-address> [vrf <vrf-name>]
BGP flap statistics for a given IPv6 route:

CLI> show ipv6 bgp flap-statistics route <ipv6-address> [vrf <vrf-name>]
BGP flap statistics for IPv4 routes matching the route-map:

CLI> show ip bgp flap-statistics route-map <list> [vrf <vrf-name>]
BGP flap statistics for IPv6 routes matching the route-map:

CLI> show ipv6 bgp flap-statistics route-map <list> [vrf <vrf-name>]
BGP flap statistics for IPv4 routes with Classless Inter-domain routing (CIDR):
CLI> show ip bgp flap-statistics cidr-only [vrf <vrf-name>]
BGP flap statistics for IPv6 routes with Classless Inter-domain routing (CIDR):
CLI> show ipv6 bgp flap-statistics cidr-only [vrf <vrf-name>]
Display all dampened IPv4 routes:

CLI> show ip bgp dampened-paths [vrf <vrf-name>]
Display all dampened IPv6 routes:

CLI> show ipv6 bgp dampened-paths [vrf <vrf-name>]
You can reset BGP route dampening statistics and restore any suppressed routes by using the following
command in global mode:
CLI> clear ip bgp-dampening [<network>/<len>] [vrf <vrf-name>]
9.2.4.5 Route summarization
• Route summarization is used to reduce the amount of routing information in routing tables. Automatic
summarization is always active and cannot be de-activated..

9.2.4.6 BGP Fall-over
• By default, BGP is quite slow in detecting the unreachability of a BGP neighbor.

• When BGP Fall-over is enabled, BGP will monitor the peering session with a specified neighbor.
Adjacency changes will be detected and terminated peering sessions are deactivated in between the
default or configured BGP scanning interval; i.e. BGP sessions are deactivated faster.
• Enabling this feature improves overall BGP convergence: BGP convergence times are optimized by
tearing down sessions faster than simple hold-timer expiration.
• 2 mechanisms can be used to enable BGP Fall-over: by means of a route map, or by means of BFP.
9.2.4.6.1 Tracking a peer by means of a route map
• If the route used to reach a neighbor disappears from the routing table, BGP peering is reset: the BGP
session is brought down as soon as there is no route to the BGP neighbor.
• Use the following command to enable fast peering session deactivation:
CLI(config-router-neighbor)> fall-over route-map <route-map>
o <route-map> is the name of the route map used to reach the BGP peer.
To disable, use the no form of the command:

CLI(config-router-neighbor)> no fall-over route-map <route-map>
Example
ip prefix-list PE permit 81.52.27.8/32
route-map TRACK-WAN-PE
match ip address prefix-list PE
exit
router bgp AS-WAN

neighbor 81.52.27.8
fall-over route-map TRACK-WAN-PE
exit
exit
o If the route used to reach the BGP peer does not match the route-map, the BGP session is
brought down:
 If 81.52.27.0/24 is a connected network, the corresponding connected route
(81.52.27.0/24) in the routing table matches the route-map, therefore the session is
not brought down.
 If the BGP peer is reached via the default-route, this route (0.0.0.0/0) does not match
the route-map, therefore the session is brought down.

9.2.4.6.2 Tracking a peer by means of BFD
• BGP can make advantageous use of BFD to facilitate faster network convergence; BFD focuses
exclusively on path-failure detection.
• When a BGP neighbor is seen as down by BFD, the BGP session is brought down.
• Use the following command to enable the BFD tracking of a peer:
CLI(config-router-neighbor)> fall-over bfd
To disable the BFD tracking, use the no form of the command:

CLI(config-router-neighbor)> no fall-over bfd
Example

ip address 10.10.10.2 255.255.255.252
bfd interval 500 min_rx 400 multiplier 4
exit
ip route static bfd GigabitEthernet 1/0 10.10.10.1
router bgp AS-WAN

neighbor 10.10.10.1
fall-over bfd
exit
exit
o BFD is enabled on Gigabit Ethernet interface 1/0.

o The BFD neighbor has IP address 10.10.10.1.
o BFD control packets are sent every 500 milliseconds.
o The minimum expected interval between two received BFD control packets is 400 milliseconds.
o After 4 consecutive missed BFD control packets, the BFD neighbor is declared unavailable.
o The OneOS device will receive BFD notifications indicating that the peer is down and this will
bring down the session.

9.3 BGP MANAGEMENT
9.3.1 BGP SNMP Traps
When a BGP neighbor connection is lost or goes up, a trap can be sent if an event manager is configured
and if the following command is entered:
CLI(configure)> [no] snmp traps bgp
9.3.2 Connection Resets
When a new policy takes effect, it is possible that the stored information has been depleted, as the new
policy does allow different attributes and routes. To re-synchronize BGP peers, it becomes necessary to
refresh the BGP routers. To do so, a connection reset forces BGP to retrieve/send all routing updates and
apply the new policy.
One could use hard reset, but this method has the disadvantage of losing all information from neighbors,
therefore, it is recommended to use a soft reset instead. Soft reset may be applied for inbound updates
coming from a neighbor and subsequent route re-advertisements. Soft reset is also applicable to outbound
updates.
9.3.2.1 Dynamic Inbound Soft Reset
The route refresh capability must be supported by both peers. A dynamic inbound soft reset makes a soft
reset of the inbound routing table. The command is as follows in global configuration mode:
CLI> clear ip bgp { * | <as-number> | <ip-address> | external } soft in
[vrf <vrf-name>]
ip-address argument specifies the connection to be reset. as-number argument allows resetting
connections for all the neighbors in a given autonomous system. Use the * keyword to specify that all
connections be reset or the keyword external designating all external BGP peers to specify only eBGP
connections.
For a peer-group, use instead:
CLI> clear ip bgp-peer-group <peer-group-name> soft in [vrf <vrf-name>]
For the IPv6 inbound routing table, use:

CLI> clear ipv6 bgp { * | <as-number> | <ipv6-address> | external }
soft in [vrf <vrf-name>]
9.3.2.2 Outbound Soft Reset
To perform an outbound soft reset, use the next command in global configuration mode:
CLI> clear ip bgp { * | <as-number> | <ip-address> | external } soft out
[vrf <vrf-name>]
For a peer-group use instead:

CLI> clear ip bgp-peer-group <peer-group-name> soft out [vrf <vrf-name>]
For the IPv6 outbound routing table, use:

CLI> clear ipv6 bgp { * | <as-number> | <ipv6-address> | external }
soft out [vrf <vrf-name>]
The command arguments are the same as those for the Inbound Soft Reset.

9.3.2.3 Soft Reset Configuration Using Stored Routing Policy Information
If all of the BGP routers in the connection do not support the route refresh capability, use the soft reset
method that generates a new set of inbound routing table updates from previously-stored information. To
initiate storage of inbound routing table updates, you must first pre-configure the router using the neighbor
/ peer-group soft-reconfiguration command. The clear ip bgp command initiates the soft reset, which
generates a new set of inbound routing table updates using the stored information.
Keep in mind that the memory requirements for storing the inbound update information can become quite
large. To configure BGP soft reset using stored routing policy information, use the following command in
neighbor / peer-group configuration mode:
CLI(config-router-af-neighbor)> [no] soft-reconfiguration inbound
CLI(config-router-neighbor)> [no] soft-reconfiguration inbound
CLI(config-router-group)> [no] soft-reconfiguration inbound
This command resets the BGP session and initiates storage of inbound routing table updates from the
specified neighbor / peer-group. From now on, a copy of the BGP routing table for the specified neighbor /
peer-group is maintained on the router.
Note: all members of the peer group will inherit the characteristic configured with this command.
To stop storing received updates, use the no form of the command.
9.3.2.4 eBGP Connection Reset after Link Failure
Normally, when a link between external neighbors goes down, the BGP session will not be reset
immediately. If the eBGP session needs to be reset as soon as an interface goes down, use the following
command in router configuration mode:
CLI(config-router)> [no] bgp fast-external-failover
To not reset eBGP connections after link failure, use the no form of the command.

9.4 BGP CONFIGURATION EXAMPLE
Following example uses the Multiprotocol Extensions for BGP-4 (RFC 4760). Two neighbors are
configured one over IPv4 network, the other over IPv6 network.

ip address 192.168.1.81 255.255.255.0
ipv6 address 2000::1/64
exit
ip address 6.0.0.1 255.255.255.255
ipv6 address 3000::80/64
exit
router bgp 1
no bgp default ipv4-unicast
neighbor 5.0.0.1
remote-as 3
exit
neighbor 2000::2
remote-as 2
exit
address-family ipv4
neighbor 5.0.0.1 activate
exit
redistribute connected
exit
address-family ipv6
neighbor 2000::2 activate
exit
redistribute connected
exit
exit

9.5 BGP STATISTICS
IPv4 BGP routes matching the specified prefix are provided with the following command:
CLI> show ip bgp prefix <network>/<len> [longer-prefixes]
[vrf <vrf-name>]
IPv6 BGP routes matching the specified prefix are provided with the following command:
CLI> show ipv6 bgp prefix <network>/<len> [longer-prefixes]
[vrf <vrf-name>]
IPv4 BGP routes matching the specified prefix-list are provided with the following command:
CLI> show ip bgp prefix-list <list-name>
IPv6 BGP routes matching the specified prefix-list are provided with the following command:
CLI> show ipv6 bgp prefix-list <list-name>
IPv4 BGP routes that make use of CIDR routing are provided with the following command:
CLI> show ip bgp cidr-only [vrf <vrf-name>]
IPv6 BGP routes that make use of CIDR routing are provided with the following command:
CLI> show ipv6 bgp cidr-only [vrf <vrf-name>]
IPv4 BGP routes permitted by the specified community are provided with the following command. exact
keyword displays only the route with exactly the given community attribute. include keyword displays
only the routes whose community includes the given community attribute.
CLI> show ip bgp community { exact | include } <community-number>
[vrf <vrf-name>]
IPv6 BGP routes permitted by the specified community are provided with the following command:
CLI> show ipv6 bgp community { exact | include } <community-number>
[vrf <vrf-name>]
IPv4 BGP routes permitted by the specified community list are provided with the following command.
exact-match keyword displays the route that have exactly the same community list attribute only (and no
other communities).
CLI> show ip bgp community-list <community-list-name> [exact-match]
[vrf <vrf-name>]
IPv6 BGP routes permitted by the specified community list are provided with the following command:
CLI> show ipv6 bgp community-list <community-list-name> [exact-match]
[vrf <vrf-name>]
IPv4 BGP routes permitted by the specified access list are provided with the following command:
CLI> show ip bgp filter-list <acl-name> [vrf <vrf-name>]
IPv6 BGP routes permitted by the specified access list are provided with the following command:
CLI> show ipv6 bgp filter-list <acl-name> [vrf <vrf-name>]

IPv4 BGP routes permitted by the specified regular expression are provided with the following command:
CLI> show ip bgp regexp <regexp> [vrf <vrf-name>]
IPv6 BGP routes permitted by the specified regular expression are provided with the following command:
CLI> show ipv6 bgp regexp <regexp> [vrf <vrf-name>]
IPv4 BGP routes permitted by the specified route map are provided with the following command:
CLI> show ip bgp route-map <map-name> [vrf <vrf-name>]
IPv6 BGP routes permitted by the specified route map are provided with the following command:
CLI> show ipv6 bgp route-map <map-name> [vrf <vrf-name>]
The whole IPv4 BGP routing table is displayed with the following command:
CLI> show ip bgp [vrf <vrf-name>]
The whole IPv6 BGP routing table is displayed with the following command:
CLI> show ipv6 bgp [vrf <vrf-name>]
The specified IPv4 route entry is displayed with the following command:
CLI> show ip bgp route <ip-address> [vrf <vrf-name>]
The specified IPv6 route entry is displayed with the following command:
CLI> show ipv6 bgp route <ipv6-address> [vrf <vrf-name>]
To provide information related to IPv4 neighbors (or to the specified neighbor):

CLI> show ip bgp neighbors [<ip-address>] [vrf <vrf-name>]
To provide information related to IPv6 neighbors (or to the specified neighbor):

CLI> show ipv6 bgp neighbors [<ipv6-address>] [vrf <vrf-name>]
show ipv6 bgp neighbors

BGP neighbor is 2000::2, remote AS 2, local AS 1, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Connect
Last read 03:09:19, hold time is 180, keepalive interval is 60 seconds
Received 0 messages, 0 notifications, 0 in queue
Sent 0 messages, 0 notifications, 0 in queue
Route refresh request: received 0, sent 0
Minimum time between advertisement runs is 30 seconds
For address family: IPv6 Unicast

0 accepted prefixes
Connections established 0; dropped 0

Next connect timer due in 54 seconds
Read thread: on Write thread: on
To provide details for IPv4 BGP routes exchanged with neighbors:

CLI> show ip bgp neighbors <ip-address> [ advertised-routes
| dampened-routes]
| received-routes
| received prefix-filter
| flap-statistics
[vrf <vrf-name>]
To provide details for IPv6 BGP routes exchanged with neighbors:

CLI> show ipv6 bgp neighbors <ipv6-address> [advertised-routes

| dampened-routes]
| received-routes
| received prefix-filter
| flap-statistics
[vrf <vrf-name>]
To display all IPv4 BGP paths in the database, use the following command:
CLI> show ip bgp paths [vrf <vrf-name>]
To display all IPv6 BGP paths in the database, use the following command:
CLI> show ipv6 bgp paths [vrf <vrf-name>]
To display summarized information about IPv4 BGP status, use the following command:
CLI> show ip bgp summary [vrf <vrf-name>]
To display summarized information about IPv6 BGP status, use the following command:
CLI> show ipv6 bgp summary [vrf <vrf-name>]

9.6 BGP DEBUG
plain form of the following commands and is deactivated using the no form of the commands.
To debug BGP general behavior issues, use the following command:

CLI> debug bgp
BGP debugging is on
00:00:52.678 BGP: 2000::2 went from Idle to Connect
00:00:55.678 BGP: 2000::2 went from Connect to OpenSent
00:00:55.678 BGP: 2000::2 sending OPEN, version 4, my as 1, holdtime 180, id 6.0.0.1
00:00:55.678 BGP: 2000::2 send message type 1, length (incl. header) 45
00:01:07.338 BGP: Performing BGP general scanning vrf (null)
00:02:13.538 BGP: 5.0.0.1 went from Active to Connect
00:02:13.538 BGP: 5.0.0.1 went from Connect to Active
CLI> no debug bgp

BGP debugging is off
To debug BGP events issues, use the following command:

CLI> debug bgp events
BGP events debugging is on
00:20:13.718 RTD: can't connect to 5.0.0.1 fd 15 : S_errno_EHOSTUNREACH
00:20:21.318 RTD: 2000::2 [Event] Connect start to 2000::2 fd 14
00:22:13.738 RTD: 5.0.0.1 [Event] Connect start to 5.0.0.1 fd 15
00:22:13.738 RTD: can't connect to 5.0.0.1 fd 15 : S_errno_EHOSTUNREACH
CLI> no debug bgp events

BGP events debugging is off
To debug BGP filters issues, use the following command:

CLI> debug bgp filters
BGP filters debugging is on
CLI> no debug bgp filters

BGP filters debugging is off
To debug BGP finite state machine issues, use the following command:
CLI> debug bgp fsm
00:27:55.859 RTD: 2000::2 [FSM] Non blocking connect waiting result
00:27:58.858 RTD: 2000::2 (0x3ba0e70 - 2) [FSM] TCP_connection_open (Connect->OpenSent)
00:28:07.858 BGP: 2000::2 [FSM] Timer (start timer expire).
00:28:07.858 RTD: 2000::2 (0x3ba0e70 - 1) [FSM] BGP_Start (Idle->Connect)
00:28:13.798 BGP: 5.0.0.1 [FSM] Timer (connect timer expire)
00:28:13.798 RTD: 5.0.0.1 (0x3b970b0 - 3) [FSM] ConnectRetry_timer_expired (Active->Connect)
00:28:13.798 RTD: 5.0.0.1 [FSM] Connect error
00:28:13.798 RTD: 5.0.0.1 (0x3b970b0 - 2) [FSM] TCP_connection_open_failed (Connect->Active)
00:28:21.878 BGP: 2000::2 [FSM] Timer (start timer expire).
00:28:21.878 RTD: 2000::2 (0x3ba0e70 - 1) [FSM] BGP_Start (Idle->Connect)

CLI> no debug bgp fsm

BGP fsm debugging is off
To debug BGP keepalive issues, use the following command:

CLI> debug bgp keepalives
BGP keepalives debugging is on
CLI> no debug bgp keepalives

BGP keepalives debugging is off
To debug BGP updates issues, use the following command:

CLI> debug bgp updates
BGP updates debugging is on
CLI> no debug bgp updates

BGP updates debugging is off

1 0 O P E N S H O R T E S T P A T H F I R S T P R O T O C O L ( O S P F )
10.1 OSPF INTRODUCTION AND FEATURES
Like RIP, OSPF is an Interior Gateway Protocol in that it was specified to permit route exchange in a
private network, typically a corporate network. The main difference with RIP is that routers running OSPF
do not exchange routes but inform the other OSPF routers about the state of their interfaces and each
OSPF router builds a topological database based on the information received from the other OSPF
routers. Information about interface states is called LSA (Link State Advertisements). Using this
information processed by the Dijkstra algorithm, a router will be able to build a shortest path tree to all
destinations in the topological database. Based on this database, the router builds its routing table. When
two neighboring routers have built their database and both databases are synchronized, they are called
adjacent routers.
OSPF was built with a two-level hierarchical design, dividing the whole network into areas. Area Border
Routers are routers which own interfaces to two or more areas (ABR). An area topology is not visible from
routers, which are not part of this area. This reduces the amount of information to send and store, thus
enabling increased scalability compared with RIP. Area 0 is the top-level area and any other area must be
connected to area 0 via at least one border router (ABR). All areas form what is called an Autonomous
System (AS). Border Routers that are connected with networks using other routing protocols (BGP, RIP)
are called Autonomous System Border Router (ASBR). Below is a typical architecture of a network.
BGP AS
ASBR
ABR
Area 1 Area 2
Area 0
OSPF Autonomous System
'Hello' messages are sent by an OSPF router to signal its availability to other routers. In a reverse way, the
non-reception of 'hello' results in considering the router as unavailable. The 'hello' message is also used to
elect the Designated Router (DR). The DR generates the LSA for the entire area, thus reducing the
number of information to exchange. Also, a Backup DR (BDR) can be elected.

10.1.1 Advantages of OSPF
• Changes in the network are propagated quickly.

• OSPF is more scalable than RIP for private networks.
• OSPF supports VLSM (Variable Length Subnet Mask), RIP does not.
• After router initialization, OSPF only sends updates when changes in the network occur. If there is no
link state change, the OSPF protocol is almost silent (only few 'hello' messages = keep alive).
• The hierarchical design of OSPF enables to reduce the size of routing tables.
10.1.2 Disadvantages of OSPF
• OSPF is processor-intensive as each router computes its own SPF tree and requires a lot of memory
because multiple copies of the same information are kept in every OSPF router. This complexity
increases exponentially with the size of the areas.
• When a link "flaps" (i.e. it goes up and down every few seconds), the network is flooded by updates
(LSA) to advertise the new state of the flapping link. This is the trade-off with the fast OSPF
convergence that requires any change be quickly advertised to the many area routers. (Note: BGP
embeds a flap-dampening feature that assesses link quality and avoids such unnecessary
advertisement.)

10.2 OSPF FEATURES
The implementation complies with RFC 2328 (OSPF v2), allows the router to behave as Designated
Router (DR) or Backup DR (BDR) on multi-access networks and supports the following options:
• Optional encrypted authentication: when an OSPF router communicates with neighbors, it can
authenticate its message using a pre-defined password (transported in clear text). To enhance
security, a digital signature may be included in the packet transporting the password to guarantee a
keyed message authentication. The MD5 standard is used to generate the signature.
• Virtual Links: the concept of virtual link enables two OSPF routers to traverse an area. There are two
scenarios requiring virtual links:
o When two networks are merged, at least the area 0 must be merged as one. The routers of
area 0 may not be directly connected. A virtual link enables the connection of the two parts of
area 0.
o When an area cannot be directly connected to area 0, a border router of the remote area is
connected to a border router of area 0 through transit OSPF areas.
• Stub area: external routes are normally injected in OSPF areas by the ASBR as LSA type 5. Some
areas can be flagged as a stub, when external routes must not be injected in the area by the area.
This is often the case when an area only has one single point of exit and a default route is sufficient.
This avoids the useless advertisement of routes in and outside the area, because IP packets should
anyway be routed through the exit border router. All routers inside a stub area must be configured with
the 'stub area' option to allow adjacency of the routers.
• Not So Stubby Area (NSSA): stub areas are proven sometimes too restrictive. It is sometimes
required to ignore advertisements from BGP but authorize those from RIP. In NSSA, OSPF routers
filter out LSA of type 5 (in this example: those coming from BGP) but inject external routes as LSA
type 7.
• Route summarization: this feature allows the aggregation of addresses, which is advertised in one
route. This prevents the advertisement of multiple routes for the address aggregate. This feature
should be activated in border routers to reduce the routing table sizes.
• RIP/BGP/Static/Default route redistribution: the routes learned by external mechanisms can be
exported in OSPF advertisements. The cost equivalence is defined when activating such feature.
• Opaque LSA (RFC 2370): this feature provides a generalized mechanism to allow for the future
extensibility of OSPF. Opaque LSA consist of a standard LSA header followed by application-specific
information. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque
LSA to all or some limited portion of the OSPF topology.

10.3 OSPF CONFIGURATION
Note: as of V4.3R2E2 software release, OSPF is only supported on the default VRF.
For basic OSPF configuration, you only need to enable OSPF and declare the networks managed by this
protocol (presented in the following section). Further parameters are all optional.
10.3.1 Enabling OSPF
10.3.1.1 On a Broadcast & Point-To-Point Network
To enable OSPF process run the following command, starting in global configuration mode:
CLI(configure)> router ospf
CLI(config-router)>
This brings the CLI in router configuration mode.

To form adjacencies with other OSPF routers on a network, run the following command, starting in router
configuration mode:
CLI(config-router)> network <network>/<length> area <area-id>
Where network is a network IP address, length is the length in bits of the network mask and area-id
is either a decimal value or an IP address.
This will enable the sending of periodic 'hello' messages on all the interfaces of the router connected to the
specified network. It is important that length matches exactly the mask length of the interface IP address.
For instance, it should be 32 for a point-to-point interface. For such interface, the network must match the
next-hop address (not the local one).
The purpose of the 'hello' message is to establish and maintain neighbor relationships. It ensures that
communication between neighbors is bi-directional. On broadcast and Non-Broadcast Multi-Access
(NBMA) networks, it is also responsible for the election of the designated router.
Example:
interface Ethernet 0/0
ip address 10.1.2.48 255.255.255.0
exit
interface atm 0
driver ident 0
max vp 3
max vc 8
range vp min 0 max 5
range vc min 32 max 64
execute
exit
gshdsl
execute
exit
exit
interface atm 0.1
pvc pppoa vpi 1 vci 49
ip address 53.0.0.4
ipcp static
authentication pap
username user9_0
password oneaccess
priority 7
execute

exit
exit
router ospf
network 10.1.2.0/24 area 1
network 53.0.0.4/32 area 1
exit
10.3.1.2 Non-Broadcast Networks
For non-broadcast networks, neighbors can be specified. This is done using the neighbor command, in
CLI(config-router)> neighbor <neighbor-ip-address>
The above method is not recommended as it offers a poor flexibility. Alternatively, you can configure the
type of network under interface configuration mode as follows:
CLI(config-if)> ip ospf network { point-to-point | broadcast
| point-to-multi-point }
For example:
interface serial 0/0.21
! Enter in a FR sub-interface
ip ospf network point-to-point
10.3.2 Router Priority
Networks are often hierarchical and it is recommended to elect as DR the router which stands at the head
of the tree. You can set the OSPF priority to enable a router to become the default DR:
CLI(config-if)> ip ospf priority <0-255>
With a priority of 0, the router is not eligible. 255 is the highest priority, 1 the lowest.
10.3.3 Router ID
By default, the OSPF protocol takes the address of the first operational interface as OSPF router IP
address. This might be inconvenient, as you are not able to predict the IP address of the OSPF router.
To force the IP address of the OSPF router, use the following command, beginning in router configuration
mode:
CLI(config-router)> router-id <A.B.C.D>
Note: the router ID is also important to elect the DR. When all routers have the same priority and no DR
exists, the biggest router-ID gets elected as DR.

10.3.4 Area Settings
To enter in area configuration mode, begin from the global configuration mode and enter:
CLI(config-router)> area <area-id>
CLI(config-area)>
10.3.4.1 Route Summarization
To reduce routing table size, route summarization allows the aggregation of several routes into a reduced
number of routes. This applies at the ABR to inter-area route exchange for routes that are within the area.
You need to define the network and network mask to define how the routes are aggregated. The command
is the following:
CLI(config-area)> range <A.B.C.D>/<length>
A.B.C.D is the network and length is the number of bits to match on the network. It is therefore
recommended that inter-area route addresses are contiguous for efficient summarization.
10.3.4.2 Stub Areas
External routes injected in the OSPF AS are transmitted as LSA of type 5. When the 'stub area' option is
activated, all LSA of type 5 are discarded thus preventing external routes to be propagated by OSPF. All
routers of the area must be configured with this attribute to allow router adjacency. To activate the stub
area option, enter the following command:
CLI(config-area)> [no] stub [no-summary]
When the attribute no-summary is provided, the area is configured as "totally stubby area". In such area
type, not only external routes are not injected in the AS, but also summarized routes coming from the other
areas. Only intra-area LSA and default route (0.0.0.0) are exchanged.
10.3.4.3 Not So Stubby Areas (NSSA)
Stub areas are sometimes too restrictive. In NSSA, OSPF routers filter out LSA of type 5 but inject external
routes as LSA type 7. By default, the ABR will translate received LSA of type 7 in LSA type 5 when
sending them to another area. It is configured so:
CLI(config-area)> [no] nssa [dont-translate] [no-summary]
The dont-translate optional attribute indicates that an ABR does not translate LSA type 7 to type 5.
The LSA are thus discarded. The no-summary optional attribute tells the ABR not to inject inter-area
routes into the NSSA.
10.3.4.4 Virtual Links
Virtual link enable two OSPF routers to traverse an area. A typical case is: when an area cannot be directly
connected to area 0, a border router of the remote area is connected to a border router of area 0 through
transit OSPF areas.
CLI(config-area)> [no] virtual-link <A.B.C.D>
A.B.C.D is the IP address of the remote ABR. It is presumed that the router knows a route to reach this IP
address.

10.3.4.5 Authentication
OSPF messages can be authenticated via a MD5-hashed signature. You can activate this authentication
for a given area. In area configuration mode, the command is the following for activation of MD5:
CLI(config-area)> authentication message-digest
To disable MD5, use the following command:

CLI(config-area)> no authentication
10.3.5.1 Interface Passivation
It can be useful to make an OSPF interface silent: it can receive OSPF LSA but cannot send any LSA.
Making such interface silent is called interface passivation. To passivate an interface, use the following
command beginning in global configuration mode:
CLI(config-router)> passive-interface <type> <unit>
10.3.5.2 Authentication
Several commands exist in interface configuration mode that enables to modify some OSPF specific
parameters for a given interface.
To specify the authentication type for an interface, use the following command:
CLI(config-if)> ip ospf authentication { message-digest | null }
Authentication type configured for an interface overrides type that might be configured for the area to
which it belongs. That is why 'null' authentication type is provided. If no type is specified, simple password
authentication is used.
Before using this command, configure a password with:
CLI(config-if)> ip ospf authentication-key <password>
password is an alphanumeric password.

If you rather want to use message digest authentication, use first:
CLI(config-if)> ip ospf message-digest-key <keyid> md5 <key>
Where keyid is an identifier in the range 1 to 255 and key is an alphanumeric password (maximum
length: 16).
To remove authentication type for an interface, use the no form of this command:
CLI(config-if)> no ip ospf authentication

10.3.5.3 Interface Cost
Definitions:
• An interface cost reflects the throughput of a link. The lower the cost, the more the interface is
preferred for routing. The cost is a specific OSPF term.
• A metric defines the overall cost of a route. To reach a destination, the router must take into account
not only the output interface, but the efficiency of the whole path. Therefore, the OSPF algorithm
computes the metric based on the cost of all interfaces, which are traversed along this route. A metric
is not a term specific to OSPF; this is the value installed in the routing table.
The default value of the cost depends on the bandwidth of the interface; it is calculated with the following
formula:
Cost = Ref-Val in bps / bandwidth-in-bps
Ref-Val is 108. This will give for instance a default cost of 1 for a FastEthernet (100Mbps) interface, 10
for an Ethernet (10Mbps) interface or 50 for an ATM PVC (2Mbps). Therefore, the higher the cost, the less
the interface is likely to be used.
To specify the cost of sending a packet on an interface, use:
CLI(config-if)> ip ospf cost <cost>
cost is an unsigned integer value in the range 1 to 65535. This value will be taken by the link cost in the
Router LSA (Link State Advertisement). To return to the default cost, use the no form of this command:
CLI(config-if)> no ip ospf cost
Instead of 108, you can set another reference value for cost computation. The command is the following,
beginning in router configuration mode:
CLI(config-router)> auto-cost reference-bandwidth <1-4294967>
The reference value is provided in Mbps. (Using 100 sets the default value).
10.3.5.4 Route Redistribution and Interworking with Other Routing Protocols
10.3.5.4.1 Administrative Distance
For the same destination, it might be possible that several routes exist in BGP, RIP or OSPF databases.
The router installs the route in its routing table based on the 'administrative distance' value. The distance is
a parameter that you can set for each routing protocols and that reflects the level of confidence in a routing
protocol. For example, you may want to always select the BGP route if it exists. Since the lower the
distance, the higher the confidence, BGP must have the lowest administrative distance.
The OSPF administrative distance is set as follows, beginning in global configuration mode:
CLI(config-router)> distance <1-255>
10.3.5.4.2 Distribute List
OSPF update filtering enables the router to select route prefixes that are advertised globally and/or per
interfaces. The command is the following:
CLI(config-router)> [no] distribute-list <acl-name> out [static | rip
| bgp | connected]
If the optional arguments are not provided, the filtering applies to all redistributed routing updates. The
access lists are standard access lists. See access-lists used for route filtering in 7.2.7.1.
Incoming updates can also be filtered. The command in the following:
CLI(config-router)> [no] distribute-list <acl-name> in

10.3.5.4.3 Route Redistribution
10.3.5.4.3.1 Introduction to External Route Metric Types
When redistributing routes, you can choose whether the metric shall be of type E1 or E2.
E1 metric means the metric is the sum of all interface costs in OSPF domain for that route + external
interface cost. E2 means the route metric is equal to the cost of the external interface cost, independently
from all interface costs in the OSPF domains.
10.3.5.4.3.2 Default Route
An ASBR router can send a default route (0.0.0.0) in the OSPF domain, when it has received it from
another protocol (e.g. RIP). To do so, use the following command in router configuration mode:
CLI(config-router)> [no] default-information originate [always]
[metric <metric>] [metric-type { 1 | 2 }] [route-map <map-name>]
If the keyword always is added, it implies the router sends a default route regardless of the fact that it has
really a default route or not. You can associate a route metric for this default route (default metric: 20) and
set the metric type. You can optionally use route maps (see below).
10.3.5.4.3.3 Injection of External Routes
You can redistribute in OSPF dynamically learned or statically configured routes by means of the
redistribute command. Use the following command in router configuration mode:
CLI(config-router)> [no] redistribute { bgp | rip | static | connected }
[metric <metric>] [metric-type { 1 | 2 }] [route-map <map-name>]
10.3.5.4.3.4 Route Maps
You can optionally use route maps to advertise only certain LSA. Route maps are a global mechanism for
routing protocols that enables the filtering of undesired routes. As route-maps can be used for BGP, RIP
and OSPF, some configuration commands for route maps are only relevant for certain protocols (mostly
BGP), hence the fact that they are detailed in each section for every routing protocols.
To define a route map use the following command, beginning from the global configuration terminal:
Where
map-name is a string identifying the route map.
sequence-number is an integer indicating the relative position compared to other instances that define
the route-map. When OSPF applies a route-map instance to routing advertisements, it applies the lowest
instance first. If the set of conditions is not met the next instance is used and so on until either a condition
is met or there are no more conditions to apply. We generally use "10" as sequence-number when
creating the route map and use increments of "10" for the following route map sequence, so that you can
insert easily other route map instances between already configured instances.
Conditions are expressed using the match command that is defined as follows:
{ <access-list-number> | prefix-list <list-name> }
When using the address keyword, the match clause applies the access/prefix list to the advertised
network. When using the next-hop keyword, the match clause applies the access/prefix list to the next-
hop of the advertised network. Prefix-list use is defined in 7.2.7.2 and access-lists use for route filtering in
7.2.7.1.
You can filter LSA using tags. An OSPF tag is a special field in LSA, encoded over 32 bits that can be
used as a configuration facility to mark and to filter LSA:
CLI(config-route-map)> match tag <0..4294967295>

To set a tag, use:

CLI(config-route-map)> set tag <0..4294967295>
You can modify the route metric of matching advertisements:

CLI(config-route-map)> set metric <metric>
To set the metric type:

CLI(config-route-map)> set metric-type { type-1 | type-2 }
10.3.5.4.3.5 Distribute List
Let us imagine that you want a network using BGP to be aware of routes in an OSPF cloud and vice-versa.
You need to mutually redistribute protocols from BGP to OSPF and OSPF to BGP. Under certain
circumstances, you can create routing loops. To avoid such undesirable effects, the solution is to filter out
OSPF routes injected in other routing domain.
On an ASBR, you can filter routes that are redistributed into an external routing domain (such as RIP). The
command is the following (in router configuration mode):
CLI(config-router)> distribute-list <acl-name> out { bgp | rip | ospf
| static | connected }
acl-name is the name of the standard access list filtering the route.

10.3.6 OSPF Tuning
10.3.6.1 Timers
• Use the following command to configure two timers with regard to SPF calculations:
CLI(config-router)> timers spf <delay> <interval>
o <delay>. This is the delay, in seconds, between the moment when a topology change is
received and the SPF calculation begins; the default value is 5 seconds. It can be set to any
value between 0 and 4294967295 seconds.
o <interval>. This is the time interval between successive SPF calculations; the default value
is 10 seconds. It can be set to any value between 0 and 4294967295 seconds.
• The following parameters can be defined for an interface or virtual link.
For an interface, enter in interface configuration mode.
For a virtual link, enter in area configuration mode and substitute 'ip ospf' by 'virtual-link
<A.B.C.D>'.
• To specify the number of seconds before the router will declare its neighbors down, without getting
‘hello’ packets, use the following command:
CLI(config-if)> ip ospf dead-interval <seconds>
o The seconds parameter is a positive integer representing the time interval, and can be set to
any value between 1 and 65535.
o This value is advertised in ‘hello’ packets sent out on this interface. It must be the same for all
routers connected to the same network.
The default value is 40 seconds for a broadcast interface, and 120 for a non-broadcast
interface.
o To return to the default value of this interval, use the no form of this command:
CLI(config-if)> no ip ospf dead-interval
• To specify the time between ‘hello’ packets that the router sends on this interface, use the following
command:
CLI(config-if)> ip ospf hello-interval <seconds>
o The seconds parameter is a positive integer representing the time interval, and can be set to
any value between 1 and 65535.
o This value is advertised in ‘hello’ packets sent out on this interface. It must be the same for all
routers connected to the same network.
The default value is 10 seconds. To return to the default value of this interval, use the no form
of this command:
CLI(config-if)> no ip ospf hello-interval
• To specify the delay length before retranslating a link state advertisement for which no
acknowledgement has been received, use the following command:
CLI(config-if)> ip ospf retransmit-interval <seconds>
o Where <seconds> is a positive integer, which must be greater than the estimated round-trip
delay between two neighbors on the network. The default is 5 seconds. To return to the default
value of this interval, use the no form of this command:
CLI(config-if)> no ip ospf retransmit-interval
• On low speed interfaces, it might take a long time to transmit a LSA; therefore adjacency between
routers is not achieved properly and that routers are synchronized with a too long time offset. By
default, it is assumed that it takes 1 sec to transmit the LSA. But on low speed interfaces, the OSPF
router needs to "anticipate" coping with the slow speed of the link. The command is the following:
CLI(config-if)> transmit-delay <time-in-s>

10.3.6.2 Override MTU Check
• By default, OSPF routers dialog with each other if they have exactly the same MTU. However, it may
be possible that the MTU is not equal for both routers. For example, an OSPF router A is connected to
an Ethernet switch using conventional Ethernet. Router A must dialog with router B, connected on the
same switch, but using VLAN. The VLAN header reduces MTU. To disable MTU comparison, use the
CLI(config-if)> [no] ip ospf mtu-ignore
10.3.6.3 Opaque LSA
• By default, opaque LSA (as defined by RFC 2370) packets including a Traffic Engineering Extension
are taken into account.
• Use the following command in OSPF router configuration mode to reject opaque LSA packets:
CLI(config-router)> no capability opaque
To make sure that opaque LSA packets are taken into account again, use the following command:
CLI(config-router)> capability opaque
10.3.6.4 OSPF Behavior Tuning
You normally do not need to tune such parameters.

By default, the OneOS implementation complies with RFC 2328. You may have to connect OneOS-based
routers with older equipment using an implementation based on RFC 1583. To do so, begin in global
configuration mode and enter:
CLI(config-router)> [no] compatible rfc1583
It is also possible that the OneOS-based ABR router must inter-operate with equipment having some old,
non-RFC compliant features. In OSPF router configuration mode, it is configured as follows:
CLI(config-router)> abr-type { cisco | ibm | standard }
By default, standard is selected, which means the behavior complies with RFC 2328.
10.3.6.5 Overflow Management of External Routes
OSPF is an Interior Gateway Protocol, that is to say, it is designed to manage routing in private networks.
When external routes are advertised in the OSPF AS from an External Gateway Protocol (like BGP), it
becomes possible thousands of routes be injected in OSPF. As OSPF is very processor- and memory-
consuming, this can result in poor router performance. To avoid such situation, you can protect the router
by limiting the number of processed external routes, using the 'overflow' command beginning in router
configuration mode:
CLI(config-router)> overflow external <nb-external-routes> <silent-time>
<silent-time> is the time in seconds, ranging from 0 to 65535, during which the router ignores any
updates for injected external routes. To restore default values, use:
CLI(config-router)> no overflow external
Default values are:

• 3000 external routes (8000 external routes for the ONE400):
• 1800 seconds silent time (30 minutes)

10.4 OSPF STATISTICS
Several routines are available to display OSPF statistics. General statistics are provided with:
CLI> show ip ospf
For information about ABR, use:

CLI> show ip ospf border-routers
As the OSPF database contains a fairly high number of information, you can view a part of the OSPF
database using the following command and options
CLI> show ip ospf database [ asbr-summary
| external
| network
| router
| summary
| max-age
| self-originate ]
For information about an OSPF interface, use:

CLI> show ip ospf interface [<interface-type> <unit>]
For information about neighboring OSPF routers, use:

CLI> show ip ospf neighbor [all | <A.B.C.D> | detail]
For information about an OSPF routes, use:

CLI> show ip ospf route

10.5 OSPF DEBUG
plain form of the following commands and is deactivated using the no form of the commands.
To debug ABR-related issue, use the following command:
CLI> [no] debug ospf abr
To debug events in the neighbor state machine (NSM, i.e. the transitions between the OSPF neighbor
states), use the following command:
CLI> [no] debug ospf nsm
To debug interface state machine (ISM, i.e. the transitions between the OSPF interface states), use the
following command:
CLI> [no] debug ospf ism
To debug general OSPF protocol state transitions, use the following command:
CLI> [no] debug ospf events
To debug exchange of external routes with OSPF, use the following command:
CLI> [no] debug ospf external
To debug and decode all OSPF protocol packets, use the following command:
CLI> [no] debug ospf packet
To monitor LSA, use the following command:

CLI> [no] debug ospf lsa [generate | install | flooding | refresh]
To debug NSSA - related information, use the following command:

CLI> [no] debug ospf nssa

1 1 O S P F V 3 O R O S P F F O R I P V 6
11.1 INTRODUCTION
This chapter describes OSPF for IPv6 or OSPFv3, which is a new and improved version of OSPFv2; the
implementation complies with RFC 2740.
The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short
Path First (SPF) calculations, constants and variables such as timers and metrics, etc.) remain unchanged.
OSPFv3 uses the same five message/packet types as OSPFv2 - Hello, DBD, LS Request, LS Update, and
LS Acknowledgment:
• Hello. This is used to establish communication with directly connected neighbors. Hello messages are
sent by an OSPF router to signal its availability to other routers. In a reverse way, the non-reception of
hello messages results in considering the router as unavailable.
• Database Description (DBD). This lists router IDs from which the router has an LSA and its current
sequence number.
• Link State Request (LSR). This is a request for an LSA.
• Link State Update (LSU). This is the reply to an LSR with the requested information.
• Link State Acknowledgment (LSAck). This is used to confirm the receipt of link-state information.
However, some items have been changed, either due to changes in protocol semantics between IPv4 and
IPv6, or to handle the increased address size of IPv6.
OSPFv3 is not backward-compatible with OSPFv2, so if OSPF has to route both IPv4 and IPv6
information, both OSPFv2 and OSPFv3 must be run.
Changes between OSPF for IPv4 or OSPFv2, and OSPF for IPv6 or OSPFv3, include:
• Addressing semantics have been removed from OSPF packets and the basic Link State
Advertisements (LSAs).
• New LSAs have been created to carry IPv6 addresses and prefixes.
• OSPF now runs on a per-link basis rather than on a per-IP-subnet or network basis.
• Flooding scope for LSAs has been generalized.
• Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication
Header and Encapsulating Security Payload (ESP).
Even with larger IPv6 addresses, most packets in OSPFv3 are almost as compact as those in OSPFv2.
Most fields and packet size limitations present in OSPFv2 have been relaxed. In addition, option handling
has been made more flexible. All of OSPFv2 's optional capabilities, including demand circuit support and
Not-So-Stubby Areas (NSSAs), are also supported in OSPFv3.
In the header of an OSPFv3 packet, there is an Instance ID, which allows multiple OSPFv3 instances to
run on the same link. The Instance ID has local link significance only, because the OSPFv3 message is
not forwarded beyond the link on which it is originated.

11.2 CONFIGURATION
11.2.1 Global configuration mode
To enable an OSPFv3 router instance, run the following command, starting in global configuration mode:
CLI(configure)> ipv6 router ospf [vrf <vrf-name>]
CLI(config-router)>
This command creates an OSPFv3 routing process and brings the CLI in router configuration mode; the
following sections describe the commands to configure the OSPFv3 router instance.
Adding the <vrf-name> in the above command is optional. If this is not provided, the default VRF is used.
To disable an OSPFv3 router instance, use the no form of this command:
CLI(configure)> no ipv6 router ospf
11.2.2 Router configuration
To configure the OSPFv3 router instance, use the following commands:

CLI(config-router)> area <area-param>
CLI(config-router)> auto-cost reference-bandwidth <1-4294967>
CLI(config-router)> default-information originate [always]
[metric <metric>] [metric-type { 1 | 2 }]
CLI(config-router)> default-metric <0-16777214>
CLI(config-router)> distance <1-255>
CLI(config-router)> distribute-list <acl-name>
{ in | out [bgp |connected | rip | static] }
CLI(config-router)> passive-interface <type> <unit>
CLI(config-router)> redistribute { bgp | rip | static | connected }
[metric <0-16777214>] [metric-type { 1 | 2 }]
CLI(config-router)> router-id <ip-addr>
CLI(config-router)> exit
CLI(config-router)> no
• area <area-param>
Use this command to configure an OSPFv3 area. Refer to 11.2.3 Area configuration for more
information. <area-param> is the OSPF area ID.
• auto-cost reference-bandwidth <1-4294967>
Use this command to set the reference bandwidth to assign OSPF cost. It can be set to any value
between 1 and 4294967, and is expressed in Mbits per second; the default value is 100.
Use the no form of this command to revert to the default reference bandwidth:
CLI(config-router)> no auto-cost reference-bandwidth
• default-information originate [always] [metric <metric>]

[metric-type { 1 | 2 }] [route-map <map-name>]
Use this command to advertise a default external route, received from another protocol, e.g. RIP, into
the OSPF domain.
Optionally, the following keywords/arguments can be added:
o always. If the keyword always is added, it means that the router advertises a default route
regardless of the fact that it actually has a default route or not.

o metric <metric>. Use this argument to associate a route metric for this default route.
<metric> ranges from 0 up to 6777214; the default value is 20.
o metric-type { 1 | 2 }. Use this argument to specify an external link type associated
with the default route; it can be type 1 or type 2.
o route-map <map-name>. Use this argument to specify a route map reference. Optionally,
route maps can be used to advertise only certain routes. Route maps are a global mechanism
for routing protocols that enables the filtering of undesired routes. Refer to 10.3.5.4.3.4 Route
Maps for more information.
Use the no form of this command to disable this feature:
CLI(config-router)> no default-information originate
• default-metric <0-16777214>
Use this command to set the default metric value for routes redistributed from another protocol into
OSPFv3. It can be set to any value between 1 and 16777214. By setting this value, OSPFv3 will use
the same metric value for all redistributed routes.
Use the no form of the command to return to the default state:
CLI(config-router)> no default-metric
• distance <1-255>
Use this command to define an administrative distance for the OSPFv3 router instance. It can be set
to any value between 1 and 255. If this command is not specified, then the administrative distance is
the default, depending on the router instance.
Use the no form of this command to remove the administrative distance and restore the default
condition:
CLI(config-router)> no distance
• distribute-list <acl-name> { in | out [bgp |connected | rip | static] }

Use this command to filter networks received or transmitted in OSPFv3 routing updates. This
command allows limiting which OSPF routes are installed on the current device. It does not affect the
OSPF protocol itself.
<acl-name> is the name of the standard access list filtering the route.
To change or cancel the filter, use the no form of this command:
CLI(config-router)> no distribute-list <acl-name> in
CLI(config-router)> no distribute-list <acl-name> out
CLI(config-router)> no distribute-list <acl-name> out bgp
CLI(config-router)> no distribute-list <acl-name> out connected
CLI(config-router)> no distribute-list <acl-name> out rip
CLI(config-router)> no distribute-list <acl-name> out static
• passive-interface <type> <unit>

Use this command to make an OSPF interface silent. This means that the interface can receive LSA
but cannot send any LSA. This way, the user can suppress routing updates on an interface.
Use the no form of this command to return to the default setting, i.e. to cancel the passive
configuration of the interface:
CLI(config-router)> no passive-interface <type> <unit>
• redistribute { bgp | rip | static | connected } [metric <0-16777214>]

[metric-type { 1 | 2 }] [route-map <map-name>]
Use this command to redistribute information from other routing protocols:
o connected. Add this keyword for routes that are directly connected, and redistributed by
OSPF.
o static. Add this keyword for routes configured via static routing, and redistributed by OSPF.
o bgp and rip. Add this keyword for routes, learnt via BGP or RIP, and redistributed by OSPF.


o metric <0-16777214>. With this argument, the metric associated with the injected routes
can be set; the default metric is 1.
o metric-type { 1 | 2 }. With this argument, the metric type associated with the injected
routes can be set: it can be type 1 or type 2.
o route-map <map-name>. Use this argument to specify a route map reference. Optionally,
route maps can be used to advertise only certain routes.
Use the no form of this command to ensure that routes are not redistributed:
CLI(config-router)> no redistribute { bgp | rip | static | connected }
• router-id <ipv4-addr>
Use this command to manually configure a router ID for the OSPFv3 process.
<ipv4-addr> can be any 32-bit value. It is not restricted to the IPv4 addresses assigned to
interfaces on the router, and it does not need be a routable IPv4 address. By configuring a router ID,
OSPFv3 will be able to function regardless of any interface address configuration.
If this command is not configured, the router ID is the highest IPv4 address for an interface on the
router.
Use the no form of this command to ensure that the default method for determining the router ID is
used:
CLI(config-router)> no router-id <ip-addr>

11.2.3 Area configuration
To enter in area configuration mode, begin from the global configuration mode and enter:
CLI(configure)> ipv6 router ospf
CLI(config-router)> area <area-param>
CLI(config-router-area)>
<area-param> is the OSPF area ID. This can either be an IP address, or a decimal value.
To configure an OSPFv3 area, use the following commands:

CLI(config-router-area)> default-cost <0-16777215>
CLI(config-router-area)> export-list <exp-name>
CLI(config-router-area)> import-list <imp-name>
CLI(config-router-area)> range <ipv6-prefix> {advertise | not-advertise}
[cost <0 - 16777215>]
CLI(config-router-area)> stub [no-summary]
CLI(config-router-area)> virtual-link <ip-str>
[hello-interval <1-65535>]
[retransmit-interval <1-65535>]
[transmit-delay <1-65535>]
[dead-interval <1-65535>]
CLI(config-router-area)> exit [all]
CLI(config-router-area)> no
• default-cost <0-16777215>
Use this command to specify a cost for the default summary route sent into a NSSA or stub area. It
can be set to any value between 0 and 16777215.
Use the no form of this command to remove the assigned default route cost:
CLI(config-router-area)> no default-cost <0-16777215>
• export-list <exp-name>
Use this command to set a filter for networks announced to other areas, by making use of an access
list. <exp-name> is the name of the standard access list.
Use the no form of this command to cancel the use of the access list:
CLI(config-router-area)> no export-list <acl-name>
• import-list <imp-name>
Use this command to set a filter for networks imported from other areas, by making use of an access
list. <imp-name> is the name of the standard access list.
Use the no form of this command to cancel the use of the access list:
CLI(config-router-area)> no import-list <imp-list-name>
• range <ip-str> { advertise | not-advertise } [cost <0-16777215>]

Use this command to summarize routes at an OSPFv3 area boundary; with:
o <ip-str>. This is the IPv6 Area range prefix.
o advertise. This sets the address range status to Advertise and generates a Type 3 summary
LSA. Routing information is condensed at area boundaries. External to the area, a single route
is advertised for each address range.
o not-advertise. This sets the address range status to DoNotAdvertise, which means that the
Type 3 summary LSA is suppressed and the address range remains hidden from other
networks. Unadvertised ranges allow the existence of certain networks to be intentionally
hidden from other areas.
o cost <0-16777215>. Optionally, a cost for the address range can be added. This can be
set to any value between 1 and 16777214.

Use the no form of this command to restore the default values:

CLI(config-router-area)> no range <ip-str>
• stub [no-summary]
Use this command to define an area as a stub area; with optionally:
o no-summary. Setting this option prevents an Area Border Router (ABR) from sending
summary link advertisements into the stub area.
Note that the stub command must be set on all routers in the stub area.
Use the no form of this command to disable this function:
CLI(config-router-area)> no stub [no-summary]
• virtual-link <ip-str> [hello-interval <1-65535>]

[retransmit-interval <1-65535>] [transmit-delay <1-65535>]
[dead-interval <1-65535>]
Use this command to define an OSPFv3 virtual link; a virtual link allows connecting to the backbone
area through a non-backbone area.
All areas in an OSPF autonomous system must be physically connected to the backbone area or area
0. If this is not physically possible, a virtual link can be used to connect to the backbone through a
non-backbone area.
The area through which the virtual link is configured, or transit area, must have full routing information
and cannot be a stub area or NSSA.
<ip-str> is the router ID of the remote ABR. The router ID can be any 32-bit value specified in four-
part, dotted-decimal notation.
Optionally, the following can be configured:
o hello-interval <1-65535>. Add this command to specify the time between hello packets
that the router sends out. It is expressed in seconds; the default is 10 seconds.
o retransmit-interval <1-65535>. Add this command to specify the delay before
retransmitting a link state advertisement for which no acknowledgement has been received. It
is expressed in seconds; the default is 5 seconds.
o transmit-delay <1-65535>. Add this command in case of a slow link.
On low speed interfaces, it might take a long time to transmit a LSA; therefore adjacency
between routers is not achieved properly and routers are synchronized with a time offset that is
too long. By default, it is assumed that it takes 1 sec to transmit the LSA. But on low speed
interfaces, the OSPFv3 router needs to anticipate coping with the slow speed of the link. This
can be achieved by setting a transmit-delay manually with this command.
o dead-interval <1-65535>. Add this command to specify the number of seconds after
which the router will declare its neighbors down; a neighbor will be declared down, if no hello
packets have been received within the specified time.
Use the no form of this command to remove a virtual link:
CLI(config-router-area)> no virtual-link <ip-str>
To remove the configured time intervals and return to the default values, use the following commands:
CLI(config-router-area)> no virtual-link <ipv4-addr>
hello-interval <1-65535>
retransmit-interval <1-65535>
transmit-delay <1-65535>
dead-interval <1-65535>

The commands described in this section, are available in the configuration mode of an interface, to
configure the interface specific OSPFv3 parameters.
First enter the interface configuration mode. As an example here, a Gigabit Ethernet interface is used:
CLI(config-if)>
To configure the interface specific OSPFv3 parameters, use the following commands:
CLI(config-if)> ipv6 ospf
area <area-id or ipv4-addr>
cost <1-65535>
dead-interval <1-65535>
hello-interval <1-65535>
instance-id <0-255>
mtu-ignore
network <broadcast | non-broadcast |
point-to-multipoint | point-to-point>
CLI(config-if)> ipv6 ospf priority <0-255>
CLI(config-if)> ipv6 ospf retransmit-interval <3-65535>
CLI(config-if)> ipv6 ospf transmit-delay <1-65535>
• ipv6 ospf area <area-id or ipv4-addr>

Use this command to set the OSPFv3 area ID. This can either be an IP address, or a decimal value.
By setting the OSPFv3 area ID, the interface is assigned to this area.
Use the no form of the command to remove the interface from the OSPFv3 area:
CLI(config-if)> no ipv6 ospf area <area-id or ipv4-addr>
• ipv6 ospf cost <1-65535>

Use this command to specify the cost of sending a packet on the interface. It can be set to any value
between 1 and 65535. This value will be taken by the link cost in the Router LSA (Link State
Advertisement).
The default value is 0; note that this value as such is not configurable.
Use the no form of the command to set the cost to the default value:
CLI(config-if)> no ipv6 ospf cost
• ipv6 ospf dead-interval <1-65535>

Use this command to specify the time interval, in seconds, after which a neighbor is declared dead. It
can be set to any value between 1 and 65535 seconds; the default value is 40 seconds.
Use the no form of the command to return to the default value:
CLI(config-if)> no ipv6 ospf dead-interval
• ipv6 ospf hello-interval <1-65535>

Use this command to specify the time interval, in seconds, between hello packets sent out on the
interface. It can be set to any value between 1 and 65535 seconds; the default value is 10 seconds.
CLI(config-if)> no ipv6 ospf hello-interval

• ipv6 ospf instance-id <0-255>

Use this command to configure an OSPFv3 Instance ID for the interface. It can be set to any value
between 0 and 255; the default value is 0.
CLI(config-if)> no ipv6 ospf instance-id
• ipv6 ospf mtu-ignore

Use this command to configure the OSPFv3 interface to ignore the MTU in DBD packets.
Use the no form of the command if the MTU must not be ignored:
CLI(config-if)> no ipv6 ospf mtu-ignore
• ipv6 ospf network <broadcast | non-broadcast | point-to-multipoint | point-

to-point>
Use this command to configure a specific network type on the interface. The interface can be
configured as broadcast, non-broadcast, point-to-multipoint and point-to-point.
Use the no form of the command to cancel the configured network type:
CLI(config-if)> no ipv6 ospf network
• ipv6 ospf priority <0-255>

Use this command to configure the OSPFv3 router priority for the interface; this helps to determine the
designated router (DR) for an OSPFv3 link. It can be set to any value between 0 and 255; the default
value is 1.
Use the no form of the command to remove the OSPFv3 router priority:
CLI(config-if)> no ipv6 ospf priority
• ipv6 ospf retransmit-interval <3-65535>

Use this command to specify the delay before retransmitting a link state advertisement (LSA) for
which no acknowledgement has been received. It can be set to any value between 3 and 65535, and
is expressed in seconds; the default value is 5 seconds.
When a router sends an LSA to its neighbor, it keeps the LSA until it receives the acknowledgment
message (Link State Acknowledgment or LSAck). If the router does not receive the acknowledgment,
it resends the LSA.
Care should be taken when setting this value: if it is too low, this could lead to unnecessary
retransmissions.
CLI(config-if)> no ipv6 ospf retransmit-interval
• ipv6 ospf transmit-delay <1-65535>

Use this command to set the transmit delay for link state packets. This delay should be the estimated
time required to send a link-state update packet on the interface. It can be set to any value between 1
and 65535, and is expressed in seconds; the default value is 1 second.
CLI(config-if)> no ipv6 ospf transmit-delay

11.3 OSPFV3 STATISTICS
11.3.1 General OSPFv3 statistics
To display general OSPFv3 statistics, use the following command:

CLI> show ipv6 ospf
In the following explanation, the commands are explained for router configuration mode.
11.3.2 Further OSPFv3 statistics
To display further OSPFv3 statistics, use the following commands:

CLI> show ipv6 ospf vrf <vrf-name>
CLI> show ipv6 ospf area [<area-id>] [vrf <vrf-name>]
CLI> show ipv6 ospf border-routers [adv-router <A.B.C.D>] [detail]
[vrf <vrf-name>]
CLI> show ipv6 ospf database [<lsa-type>] [adv-router <A.B.C.D>]
[vrf <vrf-name>]
CLI> show ipv6 ospf interface <if-name>
CLI> show ipv6 ospf neighbors [vrf <vrf-name>]
CLI> show ipv6 ospf route [vrf <vrf-name>]
CLI> show ipv6 ospf virtual-links [vrf <vrf-name>]
• show ipv6 ospf vrf <vrf-name>

Use this command to display the complete router OSPFv3 configuration for the specified VRF
instance; <vrf-name> is the name of the VRF instance.
• show ipv6 ospf area [<area-id>] [vrf <vrf-name>]
Use this command to display OSPFv3 area statistics. Optionally, the following arguments can be
added:
o <area-id>. By adding this option, the statistics of a specific OSPFv3 area can be displayed.
<area-id> is the OSPF area ID; this can either be an IP address, or a decimal value.
o vrf <vrf-name>. By adding this option, the OSPFv3 area statistics of a specific VRF
instance can be displayed.
When both options are omitted, the statistics of all configured OSPFv3 areas are displayed.
• show ipv6 ospf border-routers [adv-router <A.B.C.D>] [detail]
[vrf <vrf-name>]
Use this command to display the internal OSPFv3 routing table entries to an area border router (ABR)
and autonomous system boundary router (ASBR). Optionally, the following arguments can be added:
o adv-router <A.B.C.D>. Add this command to specify an advertising router; <A.B.C.D> is
its IP address.
o detail. Adding this keyword will provide much more detailed information.
o vrf <vrf-name>. By adding this option, the statistics of a specific VRF instance can be
displayed.

• show ipv6 ospf database [<lsa-type>] [adv-router <A.B.C.D>]

[vrf <vrf-name>]
Use this command to display OSPFv3 database information.
To display specific information from the database, use the following options:
o <lsa-type>. Add this option to display specific link states; possible link states that can be
displayed are: router, link, network, intra-prefix, inter-prefix, inter-
router, as-external.
o adv-router <A.B.C.D>. Add this command to specify an advertising router; <A.B.C.D> is
its IP address. By adding this option, the database information related to the specified router
can be displayed.
o vrf <vrf-name>. By adding this option, the database information related to the specific VRF
instance can be displayed.
• show ipv6 ospf interface [<if-name>]
Use this command to display OSPFv3 interface information. By adding the name of a specific
interface, <if-name>, only the information about this interface is displayed.
• show ipv6 ospf neighbor [vrf <vrf-name>]
Use this command to display OSPFv3 neighbor information. By adding a <vrf-name>, only
information related to the specific VRF instance can be displayed.
• show ipv6 ospf route [detail] [vrf <vrf-name>]
Use this command to display routes learnt through OSPFv3. Optionally, the following arguments can
be added:
o detail. Adding this keyword will provide much more detailed information.
o vrf <vrf-name>. By adding this option, only information related to the specific VRF instance
can be displayed.
• show ipv6 ospf virtual-links [vrf <vrf-name>]
Use this command to display information about virtual links. By adding a <vrf-name>, only
information related to the specific VRF instance can be displayed.

11.4 OSPFV3 DEBUGGING
To solve configuration issues, trace functions might have to be activated. Traces are activated using the
plain form of the following commands and are deactivated using the no form of the commands.
All commands can be followed by an optional <vrf-name>, for example:
CLI> debug ipv6 ospf abr [vrf <vrf-name>]
By adding a <vrf-name>, only information related to the specific VRF instance is displayed.
To stop the debugging, use the no form of the commands, for example:
CLI> no debug ipv6 ospf abr
The following debugging commands are available:

CLI> debug ipv6 ospf abr
CLI> debug ipv6 ospf all
CLI> debug ipv6 ospf asbr
CLI> debug ipv6 ospf border-router
CLI> debug ipv6 ospf config
CLI> debug ipv6 ospf flood
CLI> debug ipv6 ospf interface
CLI> debug ipv6 ospf lsa [originate | examine | flood]
[router | network | inter-prefix | inter-router |
as-external | group-membership | type-7 | link |
intra-prefix]
CLI> debug ipv6 ospf message [hello | dbdesc | lsreq | lsupdate | lsack |
all | unknown] [send | receive]
CLI> debug ipv6 ospf neighbor {state | event | all}
CLI> debug ipv6 ospf route [table | intra | inter]
CLI> debug ipv6 ospf spf [calculation | process | database]
CLI> debug ipv6 ospf virtual-link
CLI> debug ipv6 ospf zebra [send | receive]
• debug ipv6 ospf abr

Use this command to debug ABR related issues.
• debug ipv6 ospf all
Use this command to debug general OSPFv3 issues.
• debug ipv6 ospf config
Use this command to debug OSPFv3 configuration changes.
• debug ipv6 ospf flood
Use this command to debug OSPFv3 LSA flooding.
• debug ipv6 ospf interface
Use this command to debug the OSPFv3 interface state machine or ISM (i.e. the transitions between
the OSPF interface states).
• debug ipv6 ospf lsa [originate | examine | flood] [router | network |
inter-prefix | inter-router | as-external | group-membership | type-7 |
link | intra-prefix]
Use this command to debug the origination, examination or flooding of different types of OSPFv3 LSA
or Link State Advertisements.
As a first option, originate, examine or flood can be specified.
As a second option, the LSA type can be specified.

When both options are omitted, origination, examination and flooding all types of LSA are taken into
account.
• debug ipv6 ospf message [hello | dbdesc | lsreq | lsupdate | lsack | all |
unknown] [send | receive]
Use this command to debug the sending and/or reception of OSPFv3 messages.
As a first option, a specific message type can be specified. The different message types for which
debugging can be enabled are:
o hello or Hello Messages
o dbdesc or Database Descriptor Messages
o lsreq or LSA Request Packets
o lsupdate or LSA Update Packets
o lsack or LS Acknowledge Packets
o all or All packets
o unknown or Unknown Packets
As a second option, the sending or reception can be specified, with send or receive.
When both options are omitted, all message types and both the sending and reception are taken into
account.
• debug ipv6 ospf neighbor { state | event | all }
Use this command to debug neighbor states or events or both, by adding state, event or all
respectively.
• debug ipv6 ospf route [table | intra | inter]
Use this command to debug the OSPFv3 routing table, or specifically intra-routes within the OSPFv3
area, or inter-area routes, by adding table, intra or inter respectively.
• debug ipv6 ospf spf [calculation | process | database]
Use this command to debug OSPFv3 SPF. Each router computes its own SPF tree. By adding
calculation, process or database to the command, each of these SPF modules can be looked
at separately.
• debug ipv6 ospf virtual-link
Use this command to debug OSPFv3 virtual links.
• debug ipv6 ospf zebra [send | receive]
Use this command to debug outgoing or incoming messages to and from Zebra, by adding send or
receive respectively. All messages are taken into account when the optionan commands are
omitted.

1 2 B I - D I R E C T I O N A L F O R W A R D I N G D E T E C T I O N ( B F D )
12.1 BFD FEATURES
BFD allows a quick detection of faults between two routers, which are usually directly connected. The
protocol relies on UDP so that routers can mutually detect if they can reach each other.
BFD can be used in OneOS to disable static routes towards a router when BFD peering is lost. In
asynchronous mode, BFD peers send each other "Hello" packets to verify connectivity. BFD is usually
faster than other routing protocols to detect failures.
BFD is used in OneOS to bring down some static routes when connectivity with remote routers is lost.
When such "main" routes are down, backup routes can then take over IP traffic routing.
BFD is an alternative solution to the following configuration techniques:
• It is not possible to detect all layer-1 or layer-2 faults between the ONE router and the PE router with:
o Either link-down events or layer-2 OAM (ATM or Ethernet OAM for example),
o Or IP route tracking.
• Other IP routing protocols cannot be used.
OneOS BFD implements the following draft standards:

• draft-ietf-bfd-base-10.txt
• draft-ietf-bfd-v4v6-1hop-11.txt
Full compliance with RFC 5881 is not guaranteed yet at the moment.
The following features are supported:
• Compatible with a neighbor in asynchronous mode,
• A OneOS device can reply to BFD Echo requests,
• Poll sequence,
• Active role: send BFD control packets for a session regardless of whether it has received any BFD
packets for that session,
• A system is required to maintain session state, even when a session is down, until a Detection Time
has passed without the receipt of any BFD control packets,
• If BFD is to be used in conjunction with both IPv4 and IPv6 on a particular link, a separate BFD
session must be established for each protocol over that link,
• BFD control packets must be transmitted in UDP packets with destination port 3784, within an IPv4 or
IPv6 packet. The source port is in the range 49152 through 65535,
• The same UDP source port number must be used for all BFD control packets associated with a
particular session.

12.2 BFD CONFIGURATION COMMANDS
Activating BFD on an interface
• BFD must be activated on a per-interface basis as follows:

CLI(configure)> interface <ifname> <unit>
CLI(config-if)> bfd interval <send> min_rx <receive> multiplier <value>
o send is the minimum interval in milliseconds (from 200 to 30000 ms; default value is 750 ms)
between BFD control packets that are sent.
o receive is the minimum expected interval in milliseconds (from 200 to 30000 ms; default
value is 500 ms) between two received BFD control packets.
o value is the number (from 1 to 20; default value is 3) of consecutive BFD control packets that
must be missed before the neighbor is declared unavailable.
• To disable BFD on the specified interface:
CLI(config-if)> no bfd interval
• Applying defaults on BFD will activate BFD with the default parameter set (even if the command bfd
interval was never entered). The command is:
CLI(config-if)> default bfd interval
Declaring BFD peer IP address
• Then, declare the IP addresses of BFD peers (neighbors) under global configuration terminal:
CLI(configure)> [no] ip route [tag <tag-value>] static bfd <ifname>
<neighbor> [mhop] [source <source-ip>]
CLI(configure)> [no] ipv6 route [tag <tag-value>] static bfd <ifname>
<neighbor> [mhop] [source <source-ip>]
o <tag-value> is the tag value that can be used as a match value for controlling redistribution
via route maps. It has a range of 1 – 4294967295.
o ifname. This is the interface name of any of the interfaces present on the OneOS device.
o neighbor. This is the neighbor IP address.
o mhop. Adding the mhop keyword is optional; when added to the command, this means that port
4784 is used for BFD Multihop Control (RFC5883).
o source <source-ip>. This allows using another IP address, i.e. different from the outgoing
interface, as source; adding this source-ip is optional.
Declaring a static route
• Some static routes on interfaces can be configured, whose validity depends on BFD peering for the
related (interface, neighbor) couple:
CLI(configure)> [no] ip route <network> <mask> <ifname> <unit>
<neighbor-ip-address>
CLI(configure)> [no] ipv6 route <ipv6-address-prefix> <ifname> <unit>
<neighbor-ip-address>
• Some static routes on next hop can be configured, whose validity depends of BFD peering for the
related next hop:

CLI(configure)> [no] ip route <network> <mask> <next-hop-neighbor-ip>

CLI(configure)> [no] ipv6 route <ipv6-address-prefix> <next-hop-nbor-ip>
Behavior of BFD Static route tracking
The following example illustrates the BFD behavior for static routes.
• Example configuration:
ip address 10.10.10.9 255.255.255.0
exit
!
ip route static bfd FastEthernet 0/0 10.10.10.10
• The following static route will be tracked by BFD:

ip route 1.1.1.0 255.255.255.0 FastEthernet 0/0 10.10.10.10
• However, the following static route will not be tracked by BFD:

ip route 1.1.1.0 255.255.255.0 10.10.10.10

12.3 BFD STATISTICS
To display BFD neighbor status information:

CLI> show ip bfd neighbors [details]
To debug / troubleshoot BFD (to show BFD debugging trace):

CLI> [no] debug ip bfd [fsm | packet | socket]
12.4 BFD CONFIGURATION EXAMPLE
IPv4 example:
ip directed-broadcast
ip address 220.2.2.81 255.255.255.0
! activation of BFD on FastEthernet 0/0 interface
exit
! declaration of BFD neighbor 220.2.2.2 on FastEthernet 0/0 interface
ip route static bfd FastEthernet 0/0 220.2.2.2
! classical static route on FastEthernet 0/0 interface

ip route 2.2.2.0 255.255.255.0 FastEthernet 0/0
! BFD static route on FastEthernet 0/0 interface available only when BFD
neighbor 220.2.2.2 is UP
ip route 3.3.3.0 255.255.255.0 FastEthernet 0/0 220.2.2.2
! classical static route on next hop
ip route 1.1.1.0 255.255.255.0 220.2.2.3
! BFD static route on next hop available only when BFD neighbor is UP
ip route 0.0.0.0 0.0.0.0 220.2.2.2
IPv6 example
! activation of BFD on FastEthernet 0/3 interface
exit
! declaration of BFD neighbor 2000::0002 on FastEthernet 0/3 interface
ipv6 route static bfd FastEthernet 0/3 2000::0002
! BFD static route on FastEthernet 0/3 interface available only when BFD
neighbor 2000::0002 is UP
ipv6 route 4000::/64 FastEthernet 0/3 2000::0002
! BFD static route on next hop available only when BFD neighbor is UP
ipv6 route 5000::/64 2000::0002

1 3 M U L T I C A S T R O U T I N G
13.1 PRINCIPLES OF MULTICAST ROUTING
13.1.1 Why Multicast
The IP protocol defines three types of IP packets: unicast, broadcast and multicast. Unicast packets are
destined from a source to a destination host. Unicast is intended for host-to-host communication.
Broadcast packets are emitted by a single host and destined to all hosts of the same network. The
broadcast mode is thus intended to send information to multiple hosts, which may have interest in
receiving these information pieces. However, the broadcast mode cannot scale in large networks as it
means waste of bandwidth (because all listening hosts do not have interest in receiving that packet) and
possible networking issues such as broadcast storm in case of a routing loop. That is the reason why a
third type of IP packet was introduced: multicast packet.
“Multicast” is an IP packet type designed to send data to a group of selected hosts. In other words,
multicast is intended for point-to-multipoint communication. Example of applications for multicast:
• Routing protocols (RIP, OSPF), where routing information are exchanged between routers via
multicast packets.
• Voice and video broadcasting: multiple end-users register to a server in order to receive a multimedia
stream.
IP packets are multicast packets when their IP address belongs to the range 224.0.0.0 to
239.255.255.255. Actually, the range of IP addresses was partitioned by the IANA into sub-categories.
224.0.0.0 to 224.0.0.255 is reserved for routing protocols. Only the range 224.0.1.0 to 238.255.255.255 is
allocated to user address space. A multicast address thus corresponds to a multicast application running
between a multicast source and receiving hosts.
On an Ethernet network, a multicast packet is transported in a special MAC frame. Therefore, a multicast
sender only has to forward a single MAC frame when sending multicast flows to multiple destinations on
the LAN. The last three bytes of the multicast IP address are copied into the MAC destination address as
follows: if the multicast IP address is ???.X.Y.Z, the Mac frame is 01:00:5E:X:Y:Z. Therefore, the first 5 bits
of the multicast IP is not mapped, which can seldom yield to conflicts, which can be avoided with good
network design practices.
13.1.2 Components of a Multicast Network
Let us look at an example to make things clearer. At one hand, a video streaming server is running and is
connected to a multicast network. On the other hand side, some computers connected to a same multicast
router would like to receive the video stream. The computers join and leave the multicast group to start and
stop receiving the video stream while the server continues to broadcast video.
The computers requests that the multicast flow be sent to them using the IGMP protocol. The IGMP
protocol enables them to announce that they are willing to join and leave a multicast group. The multicast
router receiving the join request will in turn try to find the multicast source. To find that source, a multicast
routing protocol is needed to inform multicast routers that the multicast flow must be forwarded to the
requiring router. The role of the multicast routing protocol is to build a multicast distribution tree. Building a
distribution tree tells where multicast packets must be replicated so that the first single multicast packet is
forwarded to all destinations. The multicast routing topology can be optimized to privilege the shortest path
from source to destination or the overall bandwidth required in the backbone.

A distribution tree can be either a source tree or a shared tree. A source tree forms a tree, which has the
shortest path (Shortest Path Tree: SPT) from the source to all destinations. A shared tree is a tree that is
not optimal in terms of distance from the source to destination but rather tries to share segments of the
tree between multiple destinations. Shared trees enable to replicate less multicast packets. As the shared
trees are less complex (because they have less segments), multicast routers have less neighbor status
information to maintain, which requires less resources than a source tree model.
Distribution
Tree
Multicast
Source
Multicast
Receivers
Multicast
Routing
IGMP Domain
Note: it is possible to traverse networks not supporting multicast routing. To do so, a common solution is
that the multicast routing protocol is encapsulated in a GRE tunnel.

13.2 PROTOCOL INDEPENDENT MULTICAST (PIM)
13.2.1 Introduction
The PIM-SM (Protocol Independent Multicast Sparse-Mode) is a protocol for routing multicast packets to
multicast groups. OneOS supports PIM-SM version 2. It is designed to create a distribution tree along the
reverse path from the receivers towards the sources. PIM is called “independent” because it uses a unicast
routing table (populated by other routing protocols such as static, connected, RIP, OSPF … routes) to build
the distribution tree. The unicast routing table is also the routing information base used to perform Reverse
Path Forwarding (RPF) check: RPF check consists of verifying that a received packet was received from
the expected interface that matches the route in the unicast routing table. With unicast packets, RPF helps
in preventing IP spoofing. With PIM-SM routing, the RPF check is intended to determine upstream
neighbors from which multicast traffic would take from the source. A router forwards multicast packets only
if it is received on the upstream interface.
PIM neighbor discovery is performed using Hello messages sent periodically to all PIM interfaces.
PIM-SM uses Shared Tree as multicast distribution tree. The Shared Tree model needs one or more
Rendezvous Point (RP) placed in the PIM-SM domain, and known by the other PIM-SM routers. The
multicast traffic generated from a source is sent to the RP, and then it is forwarded down the shared tree to
the receivers. A multicast source and receiver can communicate together if their attached routers know
how to reach a common RP router or different RP routers (reachable with each other).
Rendezvous Point can be configured statically or dynamically using Bootstrap (BSR) messages.
When a receiver joins a multicast group, it sends an IGMP report message. The multicast router directly
connected to the receiver, elected as a DR (Designated Router), sends a PIM Join message to the RP for
that multicast group. The Join message is forwarded to the RP and that creates hop-by-hop a distribution
tree.
When a source starts sending multicast traffic for that multicast group, the multicast router directly
connected to the source and elected as DR encapsulates the packets as unicast packets and sends them
to the RP with a Register message. The RP de-encapsulates the packets and forwards the data down
through the shared tree to reach the receiver(s) listening to that group.
In the shared tree model, the multicast data flows down through the RP. But a receiver could reach a
source with a shortest path other than the route via the RP. Indeed the route via the RP may involve an
important detour. To optimize use of the bandwidth on the RP path or to reduce latencies, the receiver’s
local DR router may initiate the shortest path tree (SPT) transfer or not, by sending a Join message directly
to the source. After the sender’s local DR has received the Join message, multicast traffic starts flowing
down through the SPT. At this point, data are forwarded to the receiver using two paths, the shared path
tree and the shortest path tree. When the receiver’s local router establishes it has received two copies of
the packets, it drops packets form the RP and sends a Prune message towards the RP. The Prune
message tells the RP to stop forwarding the multicast data.
13.2.2 PIM-SM Configuration Steps
Required steps:
• Enable Multicast Routing
• Enable PIM Sparse Mode on interfaces
• Configure Rendezvous Point (RP):
o Either: Configure router as static RP
o Or (and) Configure router as Candidate RP
• Configure router as Candidate BSR (optional)

Optional steps:
• Configure TTL Threshold on interfaces
• Configure SPT switching threshold
• Configure Register source address
• Configure static multicast routes
13.2.3 PIM-SM configuration commands
13.2.3.1 Enabling Multicast Routing
• Note: as of V4.3R2E2 software release, multicast routing is only supported on the default VRF.
• Multicast routing enables the router to forward multicast flows. To enable IP multicast forwarding on
the router, use the following command in global configuration mode:
CLI(configure)> ip multicast-routing
• To disable Multicast Routing, use the following command in global configuration mode:
CLI(configure)> no ip multicast-routing
13.2.3.2 Enabling PIM Sparse Mode on interfaces
• To enable PIM Sparse Mode on a router interface, first select the interface and use the following
CLI(config-if)> ip pim sparse-mode
• To disable PIM Sparse Mode, use the following command in interface configuration mode:
CLI(config-if)> no ip pim sparse-mode
• By default, PIM-SM is not activated.
13.2.3.3 Configuring Static RP
• To configure a static RP on the router, use the following command in global configuration mode:
CLI(configure)> ip pim rp-address <ip-address>
[group-list <acl-name> ] [override]
o By default, a static RP has the lowest priority. If the override keyword is entered, the static
RP is always preferred over dynamically learnt RP.
• To remove a static RP, use the following command in global configuration mode:
CLI(configure)> no ip pim rp-address <ip-address>

13.2.3.4 Configuring Candidate RP
• To configure the router to advertise itself as Candidate RP, use the following command in global
configuration mode:
CLI(configure)> ip pim rp-candidate <interface>
[group-list <acl-name>]
[interval <0-65535>]
[priority <0-255>]
o The IP address of the interface (type and unit) is the IP address that is advertised as RP
candidate IP address.
o group-list specifies the multicast group prefixes advertised by this router.
o interval is the RP advertisement interval (default 60s).
o priority is the RP priority (the lowest –priority– number has the highest priority). The default
priority is 0.
• To remove the router as Candidate RP, use the following command in global configuration mode:
CLI(configure)> no ip pim rp-candidate
13.2.3.5 Configuring Candidate BSR
• The BSR is elected according to a priority number. The BSR advertises which RP is in charge of
building the multicast distribution tree for a particular multicast group. In order to select the group
prefixes per RP, the RFC 2362 (PIM-SM) defines a hash function requiring a hash mask length. By
default, the mask is 30 bits long. To configure the router as Candidate BSR, use the following
CLI(configure)> ip pim bsr-candidate <interface>
[hash-mask-len <0-32>]
[priority <0-255>]
o The IP address of the interface (type and unit) is the IP address that is advertised as BSR
candidate IP address. The highest priority is preferred (default value is 0).
• To remove the router as Candidate BSR, use the following command in global configuration mode:
CLI(configure)> no ip pim bsr-candidate
13.2.3.6 Configuring SPT switching threshold
• The shortest path –source– tree (SPT) switching threshold enables the router to automatically switch
form the shared path tree to the shortest path tree after multicast traffic rate is greater than the
configured rate.
• To configure the SPT switching threshold, use the following command in global configuration mode:
CLI(configure)> ip pim spt-threshold <rate-in-kbps>
• To restore the default SPT switching threshold, use the following command in global configuration
mode:
CLI(configure)> no ip pim spt-threshold
• By default, the SPT switching threshold is 8 kbps.

13.2.3.7 Configuring Register source address
• To configure a source IP address for sending the register message that is different from the outgoing
interface IP address, use the following command in global configuration mode:
CLI(configure)> ip pim register-source <interface>
• To restore the default source address for register message, use the following command in global
configuration mode:
CLI(configure)> no ip pim register-source
13.2.3.8 Configuring Source Specific Multicast (SSM)
• To configure the Source Specific Multicast (SSM) range of IP multicast addresses, use the following
CLI(configure)> ip pim ssm { default | range <acl> }
o acl is the number of a standards access-list that defines the range.

o default keyword is used for the default range (232.0.0.0/8 according to RFC 4607).
• To remove the range configuration, use the following command in global configuration mode:
CLI(configure)> no ip pim ssm { default | range <acl> }
13.2.3.9 Configuring PIM logging
• To enable PIM logging of neighbor state changes, use the following in global configuration mode:
CLI(configure)> ip pim log neighbor-changes
• To disable PIM logging, use the following command in global configuration mode:
CLI(configure)> no ip pim log neighbor-changes
13.2.3.10 Configuring IP Multicast Static Route
• To configure an IP multicast static route, use the following command in global configuration mode:
CLI(configure)> ip mroute <source-address> <mask> [<rpf-address>
| <interface> <unit>]
• To remove an IP multicast static route, use the following command in global configuration mode:
CLI(configure)> no ip mroute <source-address> <mask> [<rpf-address>
| <interface> <unit>]

13.2.3.11 Configuring longest prefix match criteria
• RPF (Reverse Path Forwarding) check will be performed on the source of multicast join/prune packets
in the following order by default:
o Connected routes. Note that only PIM enabled interfaces are considered.
o IP multicast static routes. These are routes configured using the ip mroute command.
o Unicast forwarding table.
If ip multicast longest-match is enabled, the matching criteria will be changed as follows:
o Connected routes. Also in this case, only PIM enabled interfaces are considered.
o Longest prefix between IP multicast static routes and unicast forwarding table.
Note that it is important for the RPF check that there is a unicast route to the source which must be
resolved through PIM enabled interfaces.
• To configure longest prefix match, use the following command in global configuration mode:
CLI(configure)> ip multicast longest-match
• To remove longest prefix match, use the following command in global configuration mode:
CLI(configure)> no ip multicast longest-match
13.2.3.12 Configuring IP Multicast Route Limit
• To limit the number of multicast states that can be added to a multicast routing table use the following
command in global configuration mode. To disable this configuration, use the no form of this
command.
CLI(configure)> [no] ip multicast route-limit <limit> [<threshold>]
o limit is the number of multicast routes that can be added.

The range is from 1 to 2147483647, the latter being the default value.
o threshold is the number of multicast routes that cause a warning message to occur.
The threshold value must not exceed the limit value.
13.2.3.13 Configuring TTL Threshold on interfaces
• The time-to-live (TTL) threshold value controls if a multicast packet can be forwarded on the interface.
Packets are forwarded, only if the TTL value is greater than the TTL configured on the interface. The
TTL is decremented every time a multicast packet is forwarded.
To configure a TTL threshold on an interface, use the following command in interface configuration
mode:
CLI(config-if)> ip multicast ttl-threshold <ttl-value>
• To restore the default TTL threshold on an interface, use the following command in interface
configuration mode:
CLI(config-if)> no ip multicast ttl-threshold
• By default, TTL threshold value is 1.

13.2.3.14 Configuring IP Multicast Scope Group on interfaces
• To configure an administratively scoped boundary, use the following command in interface

configuration mode. To remove the boundary, use the no form of this command.
CLI(config-if)> [no] ip multicast boundary <acl-name> [in|out]
o acl-name is the number or name identifying an access list that controls the range of group
addresses affected by the boundary.
The access list must be a standard access list when no direction is given (neither in nor out).
It can be a standard or extended access list when applied to one direction (in or out) or to
both directions (two commands with in and with out).
13.2.3.15 Configuring BSR border on interfaces
• To configure a PIM domain border preventing BSR messages from being sent or received through an
interface; use the following command in interface configuration mode. To remove the BSR border, use
the no form of this command.
CLI(config-if)> [no] ip pim bsr-border
13.2.3.16 Configuring DR priority on interfaces
• By default the router does not advertise a priority value in its HELLO messages. It is then considered
as having the highest priority and is elected as the DR. In case several routers do not advertise a
priority value then the router with the highest IP address configured is elected as the DR. To configure
a priority value used to elect the DR (the router with the highest priority will be elected or the router
with the highest IP address in case several routers have the same priority), use the following
command in interface configuration mode.
CLI(config-if)> ip pim dr-priority <value>
• Note: the router becomes itself the DR when the designated DR is disconnected and does not send
HELLO messages during 105 seconds.
• To remove the DR priority on an interface, use the following command in interface configuration mode:
CLI(config-if)> no ip pim dr-priority

13.2.4 Configuration Example
• In the following example, router C is the RP for all possible group addresses, because no restricting
access-list is associated with this router. The receiver in network 192.168.2.0/24 joins any group G, by
means of an IGMP report message received by router A. Consequently, Router A sends PIM join
messages for group G to the RP, building a branch of the RP tree for group G. As soon as Source on
network 20.1.1.0 begins to send data packets destined to group G, router B sends these packets
encapsulated in register messages to the RP, which forwards them down the RP tree towards the
Receiver. As no command spt-threshold is configured on router A, the default data threshold is
8 kbps. If the data throughput exceeds this value, router A joins directly router B for building the SP
tree towards the source (because it is the shortest path): at this time, data will flow directly from router
B to router A, which causes router A to send PIM prune messages to RP to stop the data flow coming
down the RP tree. In addition, router B will continue to send the data packets in register messages to
the RP, which will respond by register-stop messages to router B because the RP has no more
receivers down the RP tree for group G.
Receiver Source
192.168.2.0 20.1.1.0
Shortest Path Tree
PPPoA 168.112.112.0
router A router B
194.1.1.0 190.1.1.0
router C
RP
Shared Path Tree
• Router A configuration:
ip multicast-routing
interface fastethernet 0/0
ip pim sparse-mode
exit
ip pim sparse-mode
exit
interface atm 0
driver ident 0
max vp 8
max vc 8
execute
exit
gshdsl
linerate adaptive 384 2304
mode 2_wire
execute
exit

exit
interface atm 0.1
ip address 168.112.112.1
ipcp static
authentication no
execute
exit
ip pim sparse-mode
exit
ip route 20.1.1.0 255.255.255.0 atm 0.1
ip route 190.1.1.0 255.255.255.0 194.1.1.8
ip pim rp-address 190.1.1.8
• Router B configuration:
ip address 20.1.1.2
ip pim sparse-mode
exit
ip pim sparse-mode
exit
interface atm 0
driver ident 0
max vp 8
max vc 8
execute
exit
gshdsl
equipment CO
linerate adaptive 384 2304
mode 2_wire
execute
exit
exit
interface atm 0.1
ip address 168.112.112.2
ipcp static
authentication no
execute
exit
ip pim sparse-mode
exit
ip route 192.168.2.0 255.255.255.0 atm 0.1
• Router C configuration:
ip pim sparse-mode
exit
ip pim sparse-mode
exit
ip route 20.1.1.0 255.255.255.0 190.1.1.2

13.2.5 Statistics
To display statistics about multicast routing:

CLI> show ip multicast statistics
The following command displays multicast cache information and multicast data traffic counters:
CLI> show ip multicast cache
To display information about PIM interface:

CLI> show ip pim interface
To display information about PIM neighbors:

CLI> show ip pim neighbors [<neighbor-address>]
To display information about PIM route:

CLI> show ip pim route [<group-address> [<source-address>]]
To display list of PIM Rendezvous Point (RP):

CLI> show ip pim rp
To display RP mapping information about a multicast group:

CLI> show ip pim rp-hash <group-address>
To display statistics about PIM:

CLI> show ip pim statistics
13.2.6 Debug and Trace
To enable multicast reverse path forwarding debugging, use the following command:
CLI> [no] debug ip multicast
To enable all PIM debugging, use the following command:

CLI> [no] debug ip pim
To enable PIM Assert packets debugging, use the following command:

CLI> [no] debug ip pim assert
To enable PIM bootstrap packets debugging, use the following command:

CLI> [no] debug ip pim bootstrap
To enable PIM RP selection debugging, use the following command:

CLI> [no] debug ip pim cand-rp
To enable PIM packet detail debugging, use the following command:

CLI> [no] debug ip pim detail
To enable PIM group specific debugging, use the following command:

CLI> [no] debug ip pim group <group>
To enable PIM hello packets debugging, use the following command:

CLI> [no] debug ip pim hello
To enable PIM join/prune packets debugging, use the following command:

CLI> [no] debug ip pim join

To enable PIM register packets debugging, use the following command:

CLI> [no] debug ip pim register [encapsulated | null]
To enable PIM route states debugging, use the following command:

CLI> [no] debug ip pim route
To enable PIM reverse path forwarding debugging, use the following command:
CLI> [no] debug ip pim rpf

13.3 IGMP
13.3.1 Features
• Internet Group Management Protocol (IGMP) is a protocol used by IPv4 systems to report IP multicast
memberships to neighboring multicast routers.
• The IGMP protocol is based on two kinds of messages: queries and reports. While routers send
queries to inform clients about their presence, clients answer and send report messages to tell which
multicast group they want to be added to.
• Further to the first released IGMP version, IGMP version 2 introduces a new kind of packet defined as
leave message, sent once an IGMPv2 application is closed.
• IGMPv3 adds support for source filtering, which enables a multicast receiver host to signal to a router
which groups it wants to receive multicast traffic from, and from which source(s) this traffic is
expected. Two main modes are supported in IGMPv3 messages: INCLUDE mode and EXCLUDE
mode. While the former announces membership to a host group and provides a list of IP addresses
(the INCLUDE list) from which it wants to receive traffic, the latter announces membership to a host
group and provides a list of IP addresses (the EXCLUDE list) from which it does not want to receive
traffic. The fact that the multicast source can be selected is often referred to as Source Specific
Multicast or SSM.
13.3.2 Configuring IGMP
• Note that, as of V4.3R2E2 software release, multicast routing and IGMP are only supported on the
default VRF.
13.3.2.1 Enabling Multicast Routing
• Multicast routing must be enabled on the device; this is mandatory for IGMP to work.
• Multicast routing enables the router to forward multicast flows. To enable IP multicast forwarding on
the router, use the following command in global configuration mode:
CLI(configure)> ip multicast-routing
• To disable Multicast Routing, use the following command in global configuration mode:
CLI(configure)> no ip multicast-routing
13.3.2.2 Enabling IGMP
• Once PIM is enabled on an interface, IGMP is enabled too on the same interface. By default, IGMPv2
is supported. However, it is possible to force another IGMP version, using the following command:
CLI(config-if)> ip igmp version <1-2-3>
• If IGMPv3 is configured, then IGMPv3 reports are supported. To restore the default configuration, use
the following command:
CLI(config-if)> ip igmp version 2

13.3.2.3 Configuring IGMP Timers
• Each IGMP query is periodically sent to the defined subnet. query interval is the interval in
seconds between each query; use the following command in interface configuration mode:
CLI(config-if)> ip igmp query-interval <1-18000>
To come back to the default configuration, with a query interval set to 125 seconds, use the following
command:
CLI(config-if)> ip igmp query-interval
• Each IGMP query waits for a potential report, in response to the query, until a maximum response
time authorized. To configure this maximum response time, use the following command in interface
configuration mode:
CLI(config-if)> ip igmp query-max-response-time <1-25>
To come back to the default configuration, with a query max response time set to 10 seconds, use the
following command:
CLI(config-if)> ip igmp query-max-response-time
13.3.2.4 Configuring IGMP Access Policies
• It is possible to filter incoming reports upon group address, and even source address when IGMPv3
records are received.
If a standard access-list is chosen, only a group of multicast address records are read and permitted.
An extended access-list permits the configuration of a specific source address and multicast address.
To configure an access-list, use the following command in interface configuration mode:
CLI(config-if)> ip igmp acces-group <name>
To come back to the default configuration, i.e. no filtering applied on incoming IGMP reports, use the
CLI(config-if)> ip igmp access-group
13.3.2.5 Configuring IGMP Static Group
• The following command in interface configuration mode configures the router to be a statically
connected member of the specified group on the interface. To remove the router as a member of the
group, use the no form of this command.
By default, a router is not a statically connected member of an IP multicast group.
CLI(config-if)> [no] ip igmp static-group <group-address>
[source <source-address>]
o group-address is the IP multicast group address of a group to which the router belongs.
o source-address is the IP address of a system within the group from where multicast data
packets originate.
13.3.2.6 Configuring IGMP snooping
• By default IGMP snooping (defined in RFC 4541) is enabled on a bridge group, if a BVI interface
exists for this bridge group. Refer to the BVI Configuration chapter of the OneOS – Bridging & LAN
User Guide for more information.

13.3.3 Configuring IGMP Proxy
• IGMP Proxy enables multicast forwarding based solely on IGMP membership information in a tree like
topology.
• The Proxy behavior follows RFC 4605.
• The Proxy service is interoperable with IGMP version 1 (RFC 1112).
• The Proxy service is interoperable with IGMP version 2 (RFC 2236).
• The IGMP Proxy is only supported in IPv4.
• The Proxy inside the OneAccess device is the only one present on the LAN.
Note that querier election, as described in RFC 4605, is not supported.
13.3.3.1 Interface definition
• The upstream interface is the proxy device's interface that is used in the upstream direction; it is also
referred to as the host interface.
• The downstream interface is each of the proxy device's interfaces that are used in the downstream
direction; they are also referred to as router interfaces.
• The Proxy has a single upstream interface and one or more downstream interfaces.
• The Proxy performs the router portion of the IGMP protocol (RFC1112, RFC2236) on its downstream
interfaces, and the host portion on its upstream interface.
13.3.3.2 Proxy behavior
• A database is maintained to gather all membership information received from the downstream
interface(s).
• The Proxy device sends IGMP membership reports on the upstream interface when queried, and
sends unsolicited reports or leaves when the membership database changes.
• The proxy device sends IGMP query and collect reports from the host on its downstream interfaces.

13.3.3.3 Configuring Proxy support
• Use the following command to configure an interface as upstream or host interface:

CLI (config-if)> ip igmp proxy-service
Enter this command on an interface to enable the forwarding of IGMP reports out the interface, for all
groups on interfaces registered through the ip igmp mroute-proxy command.
• Use the following command to configure an interface as downstream or router interface:

CLI (config-if)> ip igmp mroute-proxy
Enter this command on an interface to enable the forwarding of IGMP reports to a proxy service for all
forwarding entries in the multicast forwarding table.
• The IGMP query interval on the downstream interface can be configured with the following command:
(config-if)> ip igmp query-interval <1-18000>
Each IGMP query is periodically sent to the defined subnet.

To come back to the default configuration, with a query-interval set to 125 seconds, use the
following command:
CLI(config-if)> ip igmp query-interval
• On downstream interfaces, each IGMP query waits for a potential report, in response to the query,
until a maximum authorized response time has passed.
To configure this maximum response time, use the following command:
CLI (config-if)> ip igmp query-max-response-time <1-25>
To come back to the default configuration, with a query-max-response-time set to 10 seconds,

CLI (config-if)> ip igmp query-max-response-time

13.3.4 IGMP Statistics
• Use the following command to display information about the IGMP configuration on the interfaces:
CLI> show igmp interface
The following is an example output of this command:
IGMP is disabled on interface GigabitEthernet 0/1

IGMP version is 3
IGMP query interval is 125 sec
IGMP max query response time is 1 sec
IGMP last member query interval is 1 sec
IGMP inbound access-group is not set
No multicast groups joined by this system
IGMP is enabled on interface GigabitEthernet 0/3

IGMP version is 2
Current IGMP querier 2.2.2.1 (this router)
IGMP is enabled on interface Bvi 1

IGMP version is 3
Current IGMP querier 192.168.157.2 (this router)
IGMP is enabled on interface Tunnel 30

IGMP version is 2
Current IGMP querier 220.0.0.1
IGMP is enabled on interface GigabitEthernet 1/0.255

IGMP version is 2
Current IGMP querier 80.54.123.1
• Use the following command to display IGMP group membership information:

CLI> show igmp groups

IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Ver
230.0.0.3 Bvi 1 00:03:07 00:03:54 192.168.14.5 3
224.0.0.251 Bvi 1 5813d5h45m 00:03:54 192.168.14.5 3

• Use the following command to display IGMP related statistics:

CLI> show igmp statistics

IGMP statistics:
IN: 35 total, 0 too short, 0 checksum errors
11 queries, 0 bad queries
23 reports, 0 bad reports, 0 reports for local groups
0 ssm discards
OUT: 0 reports
Locally joined multicast groups:
224.0.0.1/GigabitEthernet 0/3 (1 sockets)
224.0.0.1/Bvi 1 (1 sockets)
224.0.0.1/Tunnel 30 (1 sockets)
224.0.0.2/Bvi 1 (1 sockets)
224.0.0.13/Bvi 1 (1 sockets)
224.0.0.18/Bvi 1 (1 sockets)
224.0.0.1/Atm 0.1 (1 sockets)
• The following command displays the list of interfaces on which IGMP is configured and shows IGMP
Proxy information per interface:
CLI> show ip igmp-proxy interface
GigabitEthernet 0/0 is UP [#0]
Type : Upstream
State : Active
Interface IP : 10.0.30.32
• The following command provides information about multicast groups serviced and sources sending
multicast traffic:
CLI> show ip igmp-proxy route
• The following command displays multicast cache information and multicast data traffic counters:
CLI> show ip multicast cache
13.3.5 IGMP Debugging
• To display IGMP debugging information, use the following command:

CLI> debug ip igmp
• To display IGMP Proxy debugging information, use the following command:

CLI> debug ip igmp-proxy

1 4 Z O N E - B A S E D F I R E W A L L
14.1 ZONE-BASED FIREWALL OVERVIEW
• In a zone-based firewall, policies are no longer configured on an interface, but are defined between
zones. The user can configure different zones, and interfaces can be attached to a specific zone.
• Traffic will:
1. Freely pass between two interfaces that are not attached to a zone.
2. Not pass between an interface that is attached to a zone and an interface that is not.
3. Freely pass between two interfaces that belong to the same security zone.
4. Not pass from zone X to zone Y unless explicitly specified.
• To permit traffic from zone X to zone Y (including the reply traffic from zone Y to zone X in case of
stateful inspection), you must create a zone-pair from zone X to zone Y and apply a policy to that
zone-pair.
A policy consists of a list of rules that match on individual flows through means of filters; each rule
specifies the action to be taken on the matching traffic.
• A filter specification contains a list of different filter rules, each rule allowing a combined match on
addresses, protocols, and /or port lists, etc …
• When traffic is flowing from an interface with a defined zone on it, to the management zone (or vice
versa), this is by default allowed. However, this can be overruled by defining a policy in the firewall,
between the corresponding zone and the management zone.
• When traffic is flowing from an interface without a zone defined on it, to the management zone (or vice
versa), this is blocked and cannot be overruled in the firewall unless you assign the interface to a
zone.
• Several modules can be identified in the configuration of the firewall functionality (refer to the diagram
next page):
o Interface: attach an interface to a zone.
o Zone: reference object for interfaces and zone-pair definitions.
o Zone-pair: to permit traffic from zone X to zone Y, a "zone X-zone Y" zone-pair combination
must be defined and a policy must be applied to specify the traffic that is allowed.
o Policy: a collection of policy rules, each rule describing a filter to match and the appropriate
action to be taken. Basic actions that can be applied on a Policy Rule are pass/inspect/drop.
o Filter: a collection of filter rules, describing the criteria used to match a packet. Filter criteria
include:
 Source and destination addresses.
 Protocol and port specifications.
o Parameters: contains a number of general parameters to be applied when a connection is
created, such as connection time-out values, connection thresholds, etc …

Interface Firewall Parameters

Zone <name> Name Name
VRF Max. Connections
Zone list Timeouts
Zone-pair list Stealth mode
Options
Parameters <name>
Zone
Name
Zone-pair
Name
Source Zone
Destination Zone
Policy <name>
Policy
Name
Parameters <name>
Policy rules [0..n]
Filter rules Filter Policy rules

Name Name Name
Match criteria Match all / any / none Match <filter> | any
Filter rules [0..n] Action pass| inspect|
drop
ALG FTP | SIP | H323
Parameters <name>
14.1.1 Firewall
On a router, multiple firewall instances can exist. However, only a single firewall instance can be used
within a single VRF.
14.1.2 Zone
A zone is a reference object for interfaces and zone-pair definitions. It is defined by its name.
14.1.3 Zone-pair
To permit traffic from zone X to zone Y, a "zone X-zone Y" zone-pair combination must be configured
together with a specification of the traffic that is allowed or denied. This can be done by applying a policy to
the zone-pair definition.
14.1.4 Policy
A Policy consists of:

• A name.
• A table of policy rules; each rule specifies:
o A rule name.
o A filter-name: a reference to a Filter specification; the keyword any can be used to indicate that
all traffic matches.
o An action to be executed if the filter matches. An action can be pass, inspect, or drop. By
default, the inspect action is applied.

o A reference to a specific ALG (Application Level Gateway) configuration; if a supported ALG is

detected, the code for processing the ALG will be executed by default, even without a specific
reference to an ALG module. If the user wants to influence the parameters by which the ALG is
executed, it can create a specific module for the supported ALGs (e.g. FTP, TFTP, H323, and
SIP) and refer to the specific module in the policy rule. Several ALGs of different types can be
referenced to in a single policy rule, because if a broad filter is specified on this rule, flows of
different protocols can match on this rule. It is also possible to instruct the firewall to bypass the
ALG processing on this rule.
Policies are parsed in the order in which they are configured. To insert additional policy rules in an existing
policy it is possible to insert policy rules at any location within the policy rules table.
14.1.5 Filters
Filters are used to specify packet matching criteria. A Filter consists of:
• A name.
• A [match all | match any | match none] option which indicates when the filter matches. Match all
means all lines in the filter rules table should match, match any means only one of the lines in the filter
rules must match and match none means the filter will match if none of the filter rules match the
packet. Match any is the default value.
• A table of filter rules; for each filter rule, the match definition is based on several possible criteria:
o IP Address definition (an entry for both source and destination address filtering): a host
address, a subnet, an interval or a reference to a collection of addresses (see 14.1.5.1 below).
o Service/application definition (Telnet, SMTP, HTTP …): a protocol/port definition or a reference
to a pre-defined/user-defined service definition (see 14.1.5.2 below).
o Another filter specification.
When adding a new filter rule, by default all criteria are unused.
14.1.5.1 Address collections
An Address Collection module consists of a collection of possible IP address ranges:

1. Host: a simple address, e.g. 12.34.56.78.
2. Subnet: an address / prefix length combination, e.g. 12.34.56.78/24.
3. Interval: a start Interval – end Interval specification, e.g. 12.34.56.78-12.34.56.87.
14.1.5.2 Services
A Service can be used to make a collection of related IP protocol and port specifications which can be
referenced as a whole.

14.1.6 Parameters
A parameters module contains a number of configurable parameters that will be applied when a new
connection is created. Some of these parameters are common for all rules, others are protocol specific:
• Maximum number of simultaneous connections by rule (maxConnsPerRule).
• TCP timer values.
• UDP timer values.
• ICMP:
o Timer values.
o Configure the ICMP error messages that should be allowed for traffic matching on this policy
rule.
• Stealth mode: disable sending ICMP Error messages (Admin prohibited) if data is dropped (on Drop)
or implicitly denied (on Deny), and/or TCP Reset messages when errors are seen in the TCP packets
(on TCP Error).
The user can reference a Parameter module at:

1. Firewall top level.
2. Policy module level.
3. Policy rule level.
When a connection is created as a result of a match on a zone-pair/policy/policy rule combination, the
parameters of the most specific level referring to a parameter module will be used for connection setup.

14.2 ZONE-BASED FIREWALL POLICY DATABASE
All configuration elements will be joined together in the firewall policy database. Packets not matching an
existing flow will be matched against this database. The policy database also serves as the storage point
for the firewall statistics.
If a firewall configuration element is used multiple times in the configuration, the policy database will create
multiple instances of these elements, each with their own set of statistics.
A simplified structure of the policy database is shown below.
LIST ZonePair {
name
status
srcZone
dstZone
counters
refcount
policy {
name
paramset
counters
status
LIST policyRules {
name
status
paramset
action
counters
refcount
filter {
name
matching mode
LIST filterRules {
name
status
counters
refcount
expanded lookup structure
}
}
}
}
}
Because the configuration permits referencing nonexistent elements, the policy database must protect
itself against incomplete configurations. Furthermore, reconfiguring (parts of) policies must in all cases be
handled gracefully with a minimal impact on run-time behavior or previously collected usage statistics.
The basic structure of the policy database is quite simple: it is an ordered list of zone pairs, with a policy
assigned to them.
A policy consists of a global parameter set and an ordered list of policy rules. A policy rule can overrule the
parameter set of the policy it belongs to, but if it doesn’t the policy rule’s parameter set will be a copy of the
policy’s parameter set. A policy rule also has an action and a filter.
Filters consist of a matching mode and a number of filter rules. Filter rules can either be "simple", when
they only use address and service information, or "complex", when they refer to other filters. All filter rules
are expanded when they are entered in the policy database, but a maximum nesting level of 10 filter rules
is enforced.

All of these policy database elements contain a counter structure for statistics (number of packets
processed…) and a status word to indicate possible error conditions (e.g. the configuration references to a
non-existing element) for this element.
The policy database is used to create connection structures, and these connections can update the
statistics throughout the policy database. On connection creation, a number of pointers to the appropriate
counter structures in the policy database are stored in the connection structure and the count of the
referenced elements in the policy database is incremented. On connection destruction, all the relevant
reference counters for that specific session structure are decremented. In general, a non-zero reference
count of some database element means that at least one active connection might still use this policy
database element.
Only "active" policy database elements are inspected for connection creation. A zone pair is active if all its
references (source zone, destination zone and policy) are resolved. A policy can be active even if not all its
policy rules are fully resolved. Incomplete policy rules are skipped. The parameter set must be resolved
before a policy is active. A policy rule is only active if its filter (and all its filter rules) and its parameter set
are resolved.
Reconfiguration of the firewall (adding, deleting or changing of one or more elements) needs to be
explained in more detail. Since the configuration is name-based and the policy database is not, a change
in a configuration element has consequences on every instance of this configuration element in the policy
database.
A reconfiguration can also influence the error status in the policy database: a reference to a non-existing
element can be solved by adding this element, or a reference to an element can become invalid when the
referenced element is deleted. In any case, the status word of the relevant database elements will have to
be updated.
Since policy database elements can be referenced by connections, these elements cannot be deleted or
changed in-place. When there is a change in a configuration element, the corresponding instances in the
policy database are duplicated and brought up-to-date with the new configuration. The original instances
get a deleted flag in their status word and will be deleted later by a follow-up routine once they are no
longer referenced. The corresponding counters will be reset.
Remark: There is one exception to this reconfiguration system. Changes to a parameter set do not create
new database entries. They will immediately become active for new connections, and statistics are not
reset.

14.3 ZONE-BASED FIREWALL CONFIGURATION
14.3.1 Basic configuration
14.3.1.1 Zone-Based Firewall license activation
• Zone-based firewall functionalities are only available when the zone-based firewall software license,
which is part of the ASIP license, is activated. The related commands are rejected if the license is not
activated on the router. License activation is possible if the product has sufficiently hardware
resources and is pre-loaded with the rights to use the license.
• The zone-based firewall software license is part of the ASIP license; use the following command in
global configuration mode to activate the ASIP license:
--------------------------------------------------------------
--------------------------------------------------------------
--------------------------------------------------------------
--------------------------------------------------------------
CLI(configure)>
• Note that the zone-based firewall software license is also activated with
the license activate firewall command.
14.3.1.2 Creating a firewall instance
To create a new firewall instance, use the following command in global configuration mode:
CLI(configure)> firewall <firewall-name> [maximum-connections <max-cnx>]
CLI(firewall)>
The above command will create a new firewall instance or will enter firewall configuration mode for this
instance if it was already created.
max-cnx ranging from 1000 to 10000 (default 1000) can be used to limit the number of connections the
firewall will accept.
Note: for an already existing firewall instance the change of the maximum number of connections is done
using the max-connections command in firewall configuration mode (see 14.3.2.7).
To remove a firewall instance, use the following command in global configuration mode:
CLI(configure)> no firewall <firewall-name>
All the following firewall commands, except assigning an interface to a zone, are entered in firewall
configuration mode.
14.3.1.3 Using another VRF than the default VRF

To set the VRF the firewall applies to, use the following command in firewall configuration mode:
CLI(firewall)> vrf <name>
To remove the VRF from the firewall, use the following command in firewall configuration mode:
CLI(firewall)> no vrf <name>
To use the default VRF, use the following command in firewall configuration mode:
CLI(firewall)> default vrf
14.3.1.4 Adding zones to a firewall instance
To create a new zone, use the following command in firewall configuration mode:
CLI(firewall)> zone <zone-name>
To remove a zone from the firewall, use the following command in firewall configuration mode:
CLI(firewall)> no zone <zone-name>
14.3.1.5 Assigning an interface to a zone
The following command, available in interface configuration mode assigns the interface to the specified
firewall zone. The VRF of the interface and of the firewall must match.
CLI(config-if)> ip firewall zone <zone-name>
To remove the interface from the zone, use the following command in interface configuration mode:
CLI(config-if)> no ip firewall zone [<zone-name>]
14.3.1.6 Defining filters on a firewall instance
To create a new filter or edit an existing one and enter in filter configuration mode, use the following
command in firewall configuration mode:
CLI(firewall)> filter <filter-name>
CLI(fw-filter)>
To remove a filter from the firewall, use the following command in firewall configuration mode:
CLI(firewall)> no filter <filter-name>
To specify if all rules, at least one or no rule should match for the filter to return a positive result, use the
following command in filter configuration mode (default is any).
CLI(fw-filter)> match { all | any | none }
To set the match mode to any, use the following command in filter configuration mode:
CLI(fw-filter)> default match
Note: There is no filter rule configuration mode. The properties have been grouped together to limit the
configuration size. This implies that it might be necessary to configure a filter rule via several of the
following commands if the properties are not available in a single command.
Use the following command in filter configuration mode to create or edit a filter rule whose properties are
related to matching source, destination and service (that should match); not-source, not-destination and
not-service (that should not match).
CLI(fw-filter)> rule <rule-name> [source <source> | not-source <source>]
[destination <destination> | not-destination <destination>]
[service <service-name> | not-service <service-name>]

source and destination can be a host IP address or a network address (IP address / prefix length).
service-name is a reference to a user defined service (see 14.3.2.5), or an inline service definition in the
format protocol:port, where protocol can be a protocol number or any of the pre-defined named
protocols (ICMP, IGMP, IP, TCP, UDP, IPv6, GRE, ESP, AH, OSPF, VRRP, L2TP), port can be a port
number or any of the pre-defined named ports (bgp, domain, echo, ftp, ftp-data, h323, http-alt,
https, ipsec-nat-t, isakmp, nntp, ntp, pop3, radius, router, smtp, snmp, snmptrap, ssh,
syslog, tacacs, telnet, tftp, www).
Use the following command in filter configuration mode to create or edit a filter rule whose properties are
related to matching filter and TOS (that should match); not-filter and not-TOS (that should not match).
CLI(fw-filter)> rule <name> [filter <filter> | not-filter <filter>]
[tos <tos> | not-tos <tos>]
filter is a reference to a defined filter; tos is a value ranging from 0 to 255.
Refer to 14.3.2.2 section for more filter configuration commands.
To exit filter configuration mode, use the following command in filter configuration mode:
CLI(fw-filter)> exit
CLI(firewall)>
14.3.1.7 Defining policies on a firewall instance
To create a new policy or edit an existing one and enter in policy configuration mode, use the following
CLI(firewall)> policy <policy-name>
CLI(fw-policy)>
To remove a policy from the firewall, use the following command in firewall configuration mode:
CLI(firewall)> no policy <policy-name>
Note: There is no policy rule configuration mode. The properties have been grouped together to limit the
configuration size. This implies that it might be necessary to configure a policy rule via multiple commands
if the properties are not available in a single command.
Use the following command in policy configuration mode to create or edit a policy rule whose properties
are related to matching a filter, defining the action to take (pass, inspect or drop) and the parameters to
apply.
CLI(fw-policy)> rule <rule-name> [filter <filter>]
[action { pass | inspect | drop }]
[parameters <parameter>]
filter is a reference to a defined filter. If no filter is configured, all traffic matches.

Action (default action is inspect) can be one of the following:
• inspect: traffic can pass, and the reverse flow is also added; in case of TCP the session setup
(SYN/SYN_ACK) and teardown (RST or FIN) are also taken into account.
• pass: traffic can pass, but no reverse flow is created, so if traffic has to return, it needs to be explicitly
configured in the reverse zone pair.
• drop: traffic can not pass.
parameter is a reference to a defined parameter set (see 14.3.2.8).

Use the following command in policy configuration mode to create or edit a policy rule whose properties
are related to matching with one or more application level gateways:
CLI(fw-policy)> rule <name> alg [ftp <alg-name>] [tftp <alg-name>]
alg-name is a reference to an ALG definition (see 14.3.2.6).
Refer to 14.3.2.3 section for more policy configuration commands.
To exit policy configuration mode, use the following command in policy configuration mode:
CLI(fw-policy)> exit
CLI(firewall)>
14.3.1.8 Adding zone pairs to a firewall instance
To creates a new zone pair or edit an existing one and enter in zone pair configuration mode, use the
following command in firewall configuration mode:
CLI(firewall)> zone-pair <zone-pair-name>
CLI(fw-zone-pair)>
To remove a zone pair from the firewall, use the following command in firewall configuration mode:
CLI(firewall)> no zone-pair <zone-pair-name>
To set the destination zone of the zone pair, use the following command in zone pair configuration mode:
CLI(fw-zone-pair)> dst-zone <zone-name>
To remove the destination zone from the zone pair, use the following command in zone pair configuration
mode:
CLI(fw-zone-pair)> no dst-zone
To set the source zone of the zone pair, use the following command in zone pair configuration mode:
CLI(fw-zone-pair)> src-zone <zone-name>
To remove the source zone from the zone pair, use the following command in zone pair configuration
mode:
CLI(fw-zone-pair)> no src-zone
To set the policy of the zone pair, use the following command in zone pair configuration mode:
CLI(fw-zone-pair)> policy <policy-name>
To remove the policy from the zone pair, use the following command in zone pair configuration mode:
CLI(fw-zone-pair)> no policy
To exit the zone pair configuration mode, use the following command in zone pair configuration mode:
CLI(fw-zone-pair)> exit
CLI(firewall)>
14.3.2 Advanced configuration

14.3.2.1 Inspection configuration
To enable firewall inspection, which passes the data through the firewall (this is the default), use the
CLI(firewall)> inspection
To disable firewall inspection, which bypasses the firewall functionality without having to remove the
firewall configuration, use the following command in firewall configuration mode:
CLI(firewall)> no inspection
14.3.2.2 Filter configuration
To create an empty rule with sequence number seq-nr, use the following command in filter configuration
mode:
CLI(fw-filter)> rule <rule-name> [seq-nr <0..2147483647>]
To renumber the rules in the filter, starting from start in steps of increment (default start is 10; default
increment is 10), use the following command in filter configuration mod:
CLI(fw-filter)> resequence [<start> [<increment>]]
Note: For removing a filter rule property there is no grouping of properties. All properties can be removed
with a separate command.
To remove the filter rule from the filter, use the following command in filter configuration mode:
CLI(fw-filter)> no rule <rule-name>
To remove the destination from the filter rule, use the following command in filter configuration mode:
CLI(fw-filter)> no rule <rule-name> destination
To remove the filter from the filter rule, use the following command in filter configuration mode:
CLI(fw-filter)> no rule <rule-name> filter
To remove the service from the filter rule, use the following command in filter configuration mode:
CLI(fw-filter)> no rule <rule-name> service
To remove the source from the filter rule, use the following command in filter configuration mode:
CLI(fw-filter)> no rule <rule-name> source
To remove the TOS from the filter rule, use the following command in filter configuration mode:
CLI(fw-filter)> no rule <rule-name> tos
14.3.2.3 Policy configuration
To set the parameters of the policy, use the following command in policy configuration mode:
CLI(fw-policy)> parameters <params>
params is a reference to a parameter definition.
To create an empty rule with sequence number seq-nr, use the following command in policy
configuration mode:
CLI(fw-policy)> rule <rule-name> [seq-nr <0..2147483647>]

To renumber the rules in the policy, starting from start in steps of increment (default start is 10; default
increment is 10), use the following command in policy configuration mode:
CLI(fw-policy)> resequence [<start> [<increment>]]
Note: For removing a policy rule property there is no grouping of properties. All properties can be removed
with a separate command.
To remove the policy rule from the policy, use the following command in policy configuration mode:
CLI(fw-policy)> no rule <rule-name>
To remove all ALGs from the policy rule, use the following command in policy configuration mode:
CLI(fw-policy)> no rule <rule-name> alg
To remove the FTP ALG from the policy rule, use the following command in policy configuration mode:
CLI(fw-policy)> no rule <rule-name> alg ftp
To remove the TFTP ALG from the policy rule, use the following command in policy configuration mode:
CLI(fw-policy)> no rule <rule-name> alg tftp
To remove the filter from the policy rule, use the following command in policy configuration mode:
CLI(fw-policy)> no rule <rule-name> filter
To remove the parameters from the policy, use the following command in policy configuration mode:
CLI(fw-policy)> no parameters
To remove the parameters from the policy rule, use the following command in policy configuration mode:
CLI(fw-policy)> no rule <rule-name> parameters
To set the filter rule action to inspect, use the following command in policy configuration mode:
CLI(fw-policy)> default rule <rule-name> action
14.3.2.4 Address-collection configuration
To create a new address collection or edit an existing one and enter in address collection configuration
mode, use the following command in firewall configuration mode:
CLI(firewall)> address-collection <collection-name>
CLI(fw-addr-collect)>
To remove an address collection from the firewall, use the following command in firewall configuration
mode:
CLI(firewall)> no address-collection <collection-name>
To add an address range to the address collection, use the following command in address collection
configuration mode:
CLI(fw-addr-collect)> [no] address-range <value>
value can be a reference to an address collection, a host IP address, a network address (IP address /
prefix length) or an IP address range (start IP address - end IP address).
Use the no form of the command to remove the given address range.
Then, exit the address collection configuration mode:

CLI(fw-addr-collect)> exit

CLI(firewall)>
14.3.2.5 Service configuration
To create a new service or edit an existing one and enter in service configuration mode, use the following
CLI(firewall)> service <service-name>
CLI(fw-service)>
To remove a service from the firewall, use the following command in firewall configuration mode:
CLI(firewall)> no service <service-name>
To create an IP service record, use the following command in service configuration mode:
CLI(fw-service)> record ip <protocol>
protocol can be a protocol number or one of the following pre-defined protocol names: ICMP, IGMP, IP,
TCP, UDP, IPv6, GRE, ESP, AH, OSPF, VRRP, L2TP.
To remove an IP service record, use the following command in service configuration mode:
CLI(fw-service)> no record ip <protocol>
To create a TCP service record with a required destination start port plus optional destination end port and
a required start port plus optional source end port, use the following command in service configuration
mode:
CLI(fw-service)> record tcp dst-port <tcpDstStartPort> [<tcpDstEndPort>]
src-port <tcpSrcStartPort> [<tcpSrcEndPort>]
Each TCP port parameter can be any, a port number or one of the following pre-defined port names: bgp,
echo, ftp, ftpdata, h323, http-alt, https, nntp, smtp, ssh, tacacs, telnet or www.
To remove a TCP service record with a required destination start port plus optional destination end port
and a required start port plus optional source end port, use the following command in service configuration
mode:
CLI(fw-service)> no record tcp dst-port <tcpDstStartPort>
[<tcpDstEndPort>] src-port <tcpSrcStartPort> [<tcpSrcEndPort>]
To create a UDP service record with a required destination start port plus optional destination end port and
a required start port plus optional source end port, use the following command in service configuration
mode:
CLI(fw-service)> record udp dst-port <udpDstStartPort> [<udpDstEndPort>]
src-port <udpSrcStartPort> [<udpSrcEndPort>]
Each UDP port parameter can be any, a port number or one of the following pre-defined port names:
domain, echo, ipsec-nat-t, isakmp, ntp, pop3, radius, router, snmp, snmptrap, syslog,
tacacs or tftp.
To remove a UDP service record with a required destination start port plus optional destination end port
and a required start port plus optional source end port, use the following command in service configuration
mode:
CLI(fw-service)> no record udp dst-port <udpDstStartPort>
[<udpDstEndPort>] src-port <udpSrcStartPort> [<udpSrcEndPort>]
To exit service configuration mode, use the following command in service configuration mode:
CLI(fw-service)> exit
CLI(firewall)>

14.3.2.6 Application Level Gateways – ALG – configuration
Note: if an ALG is defined, by default all commands are allowed.
To create a new FTP ALG or edit an existing one and enter in FTP ALG configuration mode, use the
CLI(firewall)> alg ftp <alg-name>
CLI(fw-alg-ftp)>
To remove a FTP ALG from the firewall, use the following command in firewall configuration mode:
CLI(firewall)> no alg ftp <alg-name>
To allow the given commands, use the following command in FTP ALG configuration mode:
CLI(fw-alg-ftp)> allow command [write-file] [read-file] [list-dir]
[create-dir] [remove-dir] [change-dir] [passive-mode] [all]
To deny the given commands, use the following command in FTP ALG configuration mode:
CLI(fw-alg-ftp)> deny command [write-file] [read-file] [list-dir]
[create-dir] [remove-dir] [change-dir] [passive-mode] [all]
Use the following command in FTP ALG configuration mode to enable (default) or disable the FTP ALG:
CLI(fw-alg-ftp)> enable
CLI(fw-alg-ftp)> disable
Then, exit the FTP ALG configuration mode:

CLI(fw-alg-ftp)> exit
CLI(firewall)>
To create a new TFTP ALG or edit an existing one and enter in TFTP ALG configuration mode, use the
CLI(firewall)> alg tftp <alg-name>
CLI(fw-alg-tftp)>
To remove a TFTP ALG from the firewall, use the following command in firewall configuration mode:
CLI(firewall)> no alg tftp <alg-name>
To allow the given commands, use the following command in TFTP ALG configuration mode:
CLI(fw-alg-tftp)> allow command [write-file] [read-file] [all]
To deny the given commands, use the following command in TFTP ALG configuration mode:
CLI(fw-alg-tftp)> deny command [write-file] [read-file] [all]
Use the following command in TFTP ALG configuration mode to enable (default) or disable the TFTP ALG:
CLI(fw-alg-tftp)> enable
CLI(fw-alg-tftp)> disable
Then, exit the TFTP ALG configuration mode:

CLI(fw-alg-tftp)> exit
CLI(firewall)>
To define a default ALG used when a policy rules' action is inspect and no specific ALG is referenced,
use the following command in firewall configuration mode:
CLI(firewall)> alg default { ftp | tftp | sip | h323 } enable

To remove the default ALG, use the following command in firewall configuration mode:
CLI(firewall)> alg default { ftp | tftp | sip | h323 } disable
14.3.2.7 Maximum number of connections configuration
To change the maximum number of connections for the firewall, use the following command in firewall
configuration mode:
CLI(firewall)> max-connections <max-connections>
max-connections ranging from 1000 to 10000 (default 1000) is used to limit the number of connections
the firewall will accept. Note that the change of the maximum number of connections is only taken into
account after a reboot of the device; an information message is displayed in that case.
To default the maximum number of connections (to 1000), use the following command in firewall
configuration mode:
CLI(firewall)> default max-connections
14.3.2.8 Parameter set configuration
To create a new parameter set or edit an existing one and enter in parameter configuration mode, use the
CLI(firewall)> parameter <parameter-name>
CLI(fw-params)>
To remove a parameter set from the firewall, use the following command in firewall configuration mode:
CLI(firewall)> no parameter <parameter-name>
To set the maximum number of connections per rule (default is 0 meaning no limitation at all), use the
following command in parameter configuration mode:
CLI(fw-params)> max-conns-per-rule <max-conns-per-rule>
To return to the maximum number of connections default value (no limitation at all), use the following
command in parameter configuration mode:
CLI(fw-params)> default max-conns-per-rule
Each connection in the firewall has a timeout installed. If no traffic runs over one of the flows of the
connection during this timeout, the connection and its flows will be removed from the firewall.
This timeout is configurable in "general", but can be more specifically defined for some protocols (UDP,
TCP, and ICMP). For these protocols, the timer depends on the state the connection has reached.
To set the general timeout in seconds (default is 60s), use the following command in parameter
configuration mode:
CLI(fw-params)> timeout <timeout>
To return to the general timeout default value, use the following command in parameter configuration
mode:
CLI(fw-params)> default timeout
The TCP watch timeout is used when the TCP connection setup is started, but not completed. We expect
each answer within the SYN, SYN/ACK, ACK sequence to be sent within the watch timeout. If a SYN
packet is received, but no matching SYN/ACK and ACK (e.g. SYN flooding attack), the connection will be
removed at TCP watch timer firing. To set the TCP watch timeout in seconds (default is 30s), use the
CLI(fw-params)> tcp watch-timeout <1..4294967295>

To return to the TCP watch timeout default value, use the following command in parameter configuration
mode:
CLI(fw-params)> default tcp watch-timeout
The TCP connection timeout is used once the TCP connection is properly established; it has to be a much
larger timeout. To set the TCP connection timeout in seconds (default is 86400s – 1 day), use the following
CLI(fw-params)> tcp connection-timeout <1..4294967295>
To return to the TCP connection timeout default value, use the following command in parameter
configuration mode:
CLI(fw-params)> default tcp connection-timeout
The TCP FIN-RST timeout is used when one of the endpoints within the TCP connection wants to tear
down the connection with a FIN or RST packet; in that case we expect the other side to send an ACK or its
own FIN/RST packet within a much shorter time than the connection time out. It makes no sense to keep
the connection open for a long time. To set the TCP FIN-RST timeout in seconds (default is 5s), use the
CLI(fw-params)> tcp fin-rst-timeout <1..4294967295>
To return to the TCP FIN-RST timeout default value, use the following command in parameter
configuration mode:
CLI(fw-params)> default tcp fin-rst-timeout
The UDP watch timeout is used when a first UDP packet is sent in one direction and creates the firewall
connection and flows. We expect an "answer" (UDP packet in the reverse direction) to pass over the
connection within the watch timeout before the connection is timed out. To set the UDP watch timeout in
seconds (default is 5s), use the following command in parameter configuration mode:
CLI(fw-params)> udp watch-timeout <1..4294967295>
To return to the UDP watch timeout default value, use the following command in parameter configuration
mode:
CLI(fw-params)> default udp watch-timeout
The UDP timeout is used once traffic has passed in both directions, the UDP connection is considered
"established" and a larger timeout is used. To set the UDP timeout in seconds (default is 60s), use the
CLI(fw-params)> udp timeout <1..4294967295>
To return to the UDP timeout default value, use the following command in parameter configuration mode:
CLI(fw-params)> default udp timeout
There is a timeout for DNS traffic; it is shorter than the one for regular UDP traffic. To set the DNS timeout
in seconds (default is 10s), use the following command in parameter configuration mode:
CLI(fw-params)> dns timeout <1..4294967295>
To set the ICMP timeout in seconds (default value is 60s), use the following command in parameter
configuration mode:
CLI(fw-params)> icmp timeout <timeout>
To return to the ICMP timeout default value, use the following command in parameter configuration mode:

CLI(fw-params)> default icmp timeout
To apply in bytes TCP MSS adjustment in one way or both ways (default is off), use the following
CLI(fw-params)> tcp mss-adjust <500-2000> [forward] [reverse]
To return to the default behavior (TCP MSS adjustment not used in one way or both ways), use the
CLI(fw-params)> default tcp mss-adjust [forward] [reverse]
To enable stealth mode on deny (default is off), use the following command in parameter configuration
mode:
CLI(fw-params)> stealth on-deny
To disable stealth mode on deny, use the following command in parameter configuration mode:
CLI(fw-params)> no stealth on-deny
To enable stealth mode on drop (default is on), use the following command in parameter configuration
mode:
CLI(fw-params)> stealth on-drop
To disable stealth mode on drop, use the following command in parameter configuration mode:
CLI(fw-params)> no stealth on-drop
To enable stealth mode on TCP error (default is off), use the following command in parameter
configuration mode:
CLI(fw-params)> stealth on-tcp-error
To disable stealth mode on TCP error, use the following command in parameter configuration mode:
CLI(fw-params)> no stealth on-tcp-error
To exit parameter configuration mode, use the following command in parameter configuration mode:
CLI(fw-params)> exit
14.3.2.9 Attacks configuration
Note: only the syn-flooding attack is currently implemented.

The number of incomplete TCP sessions (SYN received but no ACK received) is monitored. When this
number crosses the upper level threshold (50 by default) the warning message "ATTACK:
ALERT:TCP_AGGR_MODE: max incomplete high threshold crossed, enter aggressive
mode" is displayed and the aggressive mode is entered. When the firewall is in aggressive mode and a
new TCP SYN arrives, the oldest incomplete TCP session is removed. When the number of incomplete
TCP sessions drops down below the lower level threshold (40 by default) the warning message "ATTACK:
ALERT:TCP_AGGR_MODE: max incomplete low threshold crossed, leaving aggressive
mode" is displayed and the aggressive mode is left.
To select another value than the default upper level threshold value, use the following command in firewall
configuration mode:
CLI(firewall)> attacks tcp-max-incomplete-high <0-4294967295>
To select another value than the default lower level threshold value, use the following command in firewall
configuration mode:
CLI(firewall)> attacks tcp-max-incomplete-low <0-4294967295>

To return to the default value (50) for the upper level threshold, use the following command in firewall
configuration mode:
CLI(firewall)> default attacks tcp-max-incomplete-high
To return to the default value (40) for the lower level threshold, use the following command in firewall
configuration mode:
CLI(firewall)> default attacks tcp-max-incomplete-low
14.3.2.10 Flow statistics configuration
Flow statistics can be updated for every packet (immediate – more accurate, default behavior) or globally
when flow is terminated (delayed – requires less processing power). To define how flow statistics are
updated, use the following command in firewall configuration mode:
CLI(firewall)> flow-stats-processing { immediate | delayed }
To return to the default behavior (flow statistics are updated for every packet), use the following command
in firewall configuration mode:
CLI(firewall)> default flow-stats-processing
14.3.2.11 Logging configuration
Note: in the following the default destination is messages; the default priority level is warning; and
emergency messages are always logged (even when the no logging command is in force).
To enable logging for the specified ALG name or for all ALG names, use the following command in firewall
configuration mode:
CLI(firewall)> logging alg { all | ftp | tftp | sip | h323 }
To disable logging of one of the listed ALGs or all ALGs, use the following command in firewall
configuration mode:
CLI(firewall)> no logging alg { all | ftp | tftp | sip | h323 }
To enable detailed ALG logging to one of the listed destinations with priority level equal or higher than the
given level, use the following command in firewall configuration mode:
CLI(firewall)> logging alg destination { syslog | messages | console }
level { emergency | alert | critical | error | warning | notice
| informational | debug | default }
To disable ALG logging to the specified destination, use the following command in firewall configuration
mode:
CLI(firewall)> no logging alg destination { syslog | messages | console }
To default the ALG logging (to none), use the following command in firewall configuration mode. The
optional destinations parameter resets to level warning the firewall ALG logging destinations (syslog,
messages and console).
CLI(firewall)> default logging alg [destinations]
To enable logging of the specified attack type or for all known attack types, use the following command in
firewall configuration mode:
CLI(firewall)> logging attack { all | syn-flooding | ping-of-death
| ip-spoofing | win-nuke | ip-option | tcp-probe }
Note: only the syn-flooding attack is currently implemented (refer to 14.3.2.9).

To disable logging of the specified attack type or of all attack types, use the following command in firewall
configuration mode:

CLI(firewall)> no logging attack { all | syn-flooding | ping-of-death

| ip-spoofing | win-nuke | ip-option | tcp-probe }
To enable detailed attack logging to the specified destination with priority level equal or higher than the
CLI(firewall)> logging attack destination { syslog | messages | console }
To disable attack logging to the specified destination, use the following command in firewall configuration
mode:
CLI(firewall)> no logging attack destination { syslog | messages
| console }
To default the attacks logging (to none), use the following command in firewall configurations mode. The
optional destinations parameter resets to level warning the firewall attack logging destinations (syslog,
CLI(firewall)> default logging attack [destinations]
To enable logging of the specified configuration message or of all configuration messages, use the
CLI(firewall)> logging configuration { all | reconfig | config-error }
To disable logging of the specified configuration message or of all configuration messages, use the
CLI(firewall)> no logging configuration { all | reconfig | config-error }
To enable detailed configuration messages logging to the specified destination with priority level equal or
higher than the given level, use the following command in firewall configuration mode:
CLI(firewall)> logging configuration destination { syslog | messages
| console } level { emergency | alert | critical | error | warning
| notice | informational | debug | default }
To disable configuration logging to the specified destination, use the following command in firewall
configuration mode:
CLI(firewall)> no logging configuration destination { syslog | messages
| console }
To default configuration messages logging (to configuration errors), use the following command in firewall
configuration mode. The optional destinations parameter resets to level warning the configuration
messages logging destinations (syslog, messages and console).
CLI(firewall)> default logging configuration [destinations]
To enable logging of the specified general messages or of all general messages, use the following
CLI(firewall)> logging general { all | system-errors | memory }
To disable logging of the specified general message or of all general messages, use the following
CLI(firewall)> no logging general { all | system-errors | memory }
To enable detailed logging of general messages to the specified destination with priority level equal or
higher than the given level, use the following command in firewall configuration mode:
CLI(firewall)> logging general destination {syslog | messages | console }

To disable general messages logging to the specified destination, use the following command in firewall
configuration mode:
CLI(firewall)> no logging general destination { syslog | messages
| console }
To default the general messages logging (to none), use the following message in firewall configuration
mode. The optional destinations parameter resets to level warning the general messages logging
destinations (syslog, messages and console).
CLI(firewall)> default logging general [destinations]
To enable logging of the specified event or for all traffic related events, use the following command in
firewall configuration mode:
CLI(firewall)> logging traffic { all | connection | drop-policy
| implicit-deny | half-open-connection | packet }
To disable logging of the specified traffic related event or of traffic related events, use the following
CLI(firewall)> no logging traffic { all | connection | drop-policy
| implicit-deny | half-open-connection | packet }
To enable detailed traffic logging to the specified destination with priority level equal or higher than the
CLI(firewall)> logging traffic destination { syslog | messages | console}
To disable traffic logging to the specified destination, use the following command in firewall configuration
mode:
CLI(firewall)> no logging traffic destination { syslog | messages
| console }
To default the traffic logging (to none), use the following command in firewall configuration mode. The
optional destinations parameter resets to level warning the traffic logging destinations (syslog,
CLI(firewall)> default logging traffic [destinations]
To default all logging criteria (to their default values – see above), use the following command in firewall
configuration mode:
CLI(firewall)> default logging

14.4 ZONE-BASED FIREWALL STATISTICS
At any stage of the configuration, information about the firewall(s) can be displayed.
To limit the output of the firewall show commands, you can define a filter, so the output will be filtered, and
only information for that specified firewall will be displayed.
CLI> firewall display-filter <filter-name>
Use the following command to display the currently active display-filter:

CLI> show firewall display-filter
To display configuration information related to the firewall, use the following command:
CLI> show firewall config [<firewall-name>]
If no firewall name is specified, configuration information for all firewalls is displayed (possibly filtered by
the firewall display-filter). If a firewall name is specified, configuration information for the specified firewall
is displayed (in this case, the display-filter is ignored).
The configuration shown in this way is the same as what is shown in the show running-config
command, except that sequence numbers are added to policy rules and filter rules. This allows you to
insert rules in between existing rules.
To display information on the policy database, use the following command:

CLI> show firewall policy-database [detail] [legend] [zone-pair <name>]
Adding the keyword detail will give you much more detailed information on the database. As it uses
numbers or characters (depending on displaying detailed information or not) for the status information, it
might be useful to add the keyword legend, which will add the legend at the beginning of the output. To
limit the output to a single zone-pair, especially useful when displaying detailed information, you can
specify it with name. Traffic to/from the device itself (i.e. destination IP or source IP is an address of the
device) is associated to the management zone of the internal zone pair. By default all connections to
the management zone are permitted – you can override this behavior by explicitly defining rules from a
user defined zone to the management zone
show firewall policy-database legend
1: deleted
2: source zone incomplete
4: destination zone incomplete
8: outbound nat incomplete
10: policy incomplete
20: policy rules incomplete. For more info: show firewall policy-database detail
40: internal
Firewall demosetup
zone-pair src-zone dst-zone policy nat status ref-cnt nr sys-up-time
corp2dmz corporate dmz corp2dmz - 20 4 3 0d 00:00:10
corp2int corporate internet corp2int - 20 0 3 0d 00:00:10
dmz2corp dmz corporate dmz2corp - 0 1 3 0d 00:00:10
dmz2int - internet dmz2int - 22 0 2 0d 00:00:10
int2dmz internet dmz - - 10 0 2 0d 00:00:07
int2manag internet management int2manag - 20 0 3 0d 00:00:09
internal corporate management internal - 40 0 0 0d 00:00:07
internal dmz management internal - 40 1 0 0d 00:00:07
internal management corporate internal - 40 0 0 0d 00:00:07
internal management dmz internal - 40 0 0 0d 00:00:07
internal management internet internal - 40 0 0 0d 00:00:07

We see for zone-pair corp2dmz, the status indicates incomplete policy rules; we can display a more
detailed listing (see below). Note that even though the policy rules are incompletes, the policy can be used
and traffic is going over it (the incomplete rules are simply disregarded as if they are not in the
configuration).
show firewall policy-database detail legend zone-pair corp2dmz
+: match -: no match
A: action incomplete
a: alg incomplete
D: deleted
d: destination address collection incomplete
F: filter incomplete
f: filter rules incomplete
i: internal
M: parameter set incomplete
n: inbound nat incomplete
N: outbound nat incomplete
P: policy incomplete
p: policy rules incomplete
S: service incomplete
s: source address collection incomplete
Z: destination zone incomplete
z: source zone incomplete
Firewall demosetup
zone-pair:corp2dmz_3 0d 00:00:10 status:normal ref-cnt:2 processed/applied/connections:4/4/8 packets/octets:7617/309663
src-zone corporate status:normal
dst-zone dmz status:normal
policy:corp2dmz 0d 00:00:10 status:normal ref-cnt:0 processed/applied/connections:4/4/8 packets/octets:7617/309663
rule:allowssh_1 0d 00:00:08 status:normal ref-cnt:0 processed/applied/connections:4/0/0 packets/octets:0/0
filter:ssh(+) 0d 00:00:08 status:normal ref-cnt:0 processed/applied/connections:4/0/0 packets/octets:0/0
mode any
rule:matchssh_0 0d 00:00:08 status:normal ref-cnt:0 processed/applied/connections:4/0/0 packets/octets:0/0
service (+)
protocol src-port dst-port
6 0 - 65535 22 - 22
rule:allowtelnet_1 0d 00:00:08 status:normal ref-cnt:1 processed/applied/connections:4/1/1 packets/octets:358/14441
filter:telnet(+) 0d 00:00:08 status:normal ref-cnt:1 processed/applied/connections:4/1/1 packets/octets:358/14441
mode any
rule:matchtelnet_0 0d 00:00:08 status:normal ref-cnt:1 processed/applied/connections:4/1/1 packets/octets:358/14441
service (+)
6 0 - 65535 23 - 23
rule:allowftp_2 0d 00:00:10 status:normal ref-cnt:0 processed/applied/connections:3/2/6 packets/octets:7024/281122
filter:ftp(+) 0d 00:00:09 status:normal ref-cnt:0 processed/applied/connections:3/2/6 packets/octets:7024/281122
mode any
rule:matchftp_0 0d 00:00:09 status:normal ref-cnt:0 processed/applied/connections:3/2/6 packets/octets:7024/281122
service (+)
6 0 - 65535 21 - 21
alg ftp:ftpall 0d 00:13:35 status:normal ref-cnt:0
write-file read-file list-dir create-dir remove-dir change-dir passive-mode
allow allow allow allow allow allow allow
rule:allowweb_1 0d 00:00:09 status:normal ref-cnt:0 processed/applied/connections:1/0/0 packets/octets:0/0
filter:web(+) 0d 00:00:09 status:normal ref-cnt:0 processed/applied/connections:1/0/0 packets/octets:0/0
mode any
rule:matchweb_2 0d 00:00:09 status:normal ref-cnt:0 processed/applied/connections:1/0/0 packets/octets:0/0
service:web(+) status:normal
6 0 - 65535 80 - 80
6 0 - 65535 8080 - 8080
If logging is configured to send messages to the message table, these messages can be displayed with
the following commands:
CLI> show firewall log-messages
firewall: demosetup
(0d 00:02:37){006} TRAFFIC:NOTIC:CONN_TIMEOUT: id 15 src 192.168.2.3 dst 192.168.2.255 prot udp srcPort 137 dstPort 137
(0d 00:02:50){007} CONFIG :ERROR:INCOMPL_POLICYRULE: denyall
(0d 00:02:50){009} CONFIG :ERROR:INCOMPL_ZONEPAIR: dmz2int
(0d 00:02:50){011} CONFIG :ERROR:INCOMPL_ZONEPAIR: int2dmz
(0d 00:02:52){013} TRAFFIC:NOTIC:CONN_CREATE: id 16 src 192.168.2.3 dst 192.168.2.255 prot udp srcPort 137 dstPort 137
If you only want to see the log-messages for configuration, you can use the following command:
CLI> show firewall config-messages
firewall: demosetup
seq-nr time msg-id severity message
7 0d 00:02:50 INCOMPL_POLICYRULE ERROR denyall
9 0d 00:02:50 INCOMPL_ZONEPAIR ERROR dmz2int
11 0d 00:02:50 INCOMPL_ZONEPAIR ERROR int2dmz

A short overview of which zone is defined on which interface, use the following command:
CLI> show firewall interfaces
firewall: demosetup
name zone
FastEthernet 0/0 corporate
FastEthernet 0/3 dmz
FastEthernet 1/0 internet
Use the following to display info on the existing flows for the firewall(s):
CLI> show firewall flows [detail] [conn-id <id>]
show firewall flows

firewall: demosetup
src-zone dst-zone src-address dst-address prot src-prt dst-prt timeout packets conn-id alg-id
> corporate dmz 192.168.1.1 192.168.2.2 tcp 2031 telnet 00d 23:59:59 114 38 -
< dmz corporate 192.168.2.2 192.168.1.1 tcp telnet 2031 00d 23:59:59 116 38 -
> corporate dmz 192.168.1.1 192.168.2.3 icmp - - 00d 00:00:59 124 42 -
< dmz corporate 192.168.2.3 192.168.1.1 icmp - - 00d 00:00:59 124 42 -
> corporate dmz 192.168.1.1 192.168.2.3 tcp 2072 ftp 00d 23:59:43 10 50 -
...
> dmz corporate 192.168.2.2 192.168.1.1 udp 1028 2082 00d 00:00:59 301 58 tftp
< corporate dmz 192.168.1.1 192.168.2.2 udp 2082 1028 00d 00:00:59 304 58 tftp
Adding the keyword detail will give you more detailed information on the flows. Especially in that case, it
might be useful to specify a single connection by using conn-id to limit the output to the desired
connection.
show firewall flows detail conn-id 56
firewall: demosetup
> src-intf=FastEthernet 0/0, src-zone=corporate, dst-intf=FastEthernet 0/3, dst-zone=dmz
src-address=192.168.1.1, dst-address=192.168.2.3
age=0d 00:00:21, timeout=0d 23:59:59, mode=FA, conn-id=56, alg-id=ftp:54, packets/octets=5251/210052
zone-pair=corp2dmz, policy=corp2dmz, policy-rule=allowftp, filter=ftp, filter-rule=matchftp
prot=tcp, src-port=2079, dst-port=3708, state=established, seq-nr=316472412, acked-nr=316472412
< src-intf=FastEthernet 0/3, src-zone=dmz, dst-intf=FastEthernet 0/0, dst-zone=corporate
age=0d 00:00:21, timeout=0d 23:59:59, mode=RA, conn-id=56, alg-id=ftp:54, packets/octets=10658/15611056
zone-pair=corp2dmz, policy=corp2dmz, policy-rule=allowftp, filter=ftp, filter-rule=matchftp
prot=tcp, src-port=3708, dst-port=2079, state=established, seq-nr=4061000540, acked-nr=4060997620
show firewall flows detail conn-id 58

firewall: demosetup
> src-intf=FastEthernet 0/3, src-zone=dmz, dst-intf=FastEthernet 0/0, dst-zone=corporate
age=0d 00:00:21, timeout=0d 00:00:59, mode=FA, conn-id=58, alg-id=tftp, packets/octets=489/15648
zone-pair=dmz2corp, policy=dmz2corp, policy-rule=allowtftp, filter=tftp, filter-rule=matchtftp
prot=udp, src-port=1028, dst-port=2082
< src-intf=FastEthernet 0/0, src-zone=corporate, dst-intf=FastEthernet 0/3, dst-zone=dmz
age=0d 00:00:21, timeout=0d 00:00:59, mode=RA, conn-id=58, alg-id=tftp, packets/octets=490/266560
zone-pair=dmz2corp, policy=dmz2corp, policy-rule=allowtftp, filter=tftp, filter-rule=matchtftp
prot=udp, src-port=2082, dst-port=1028
Statistics on number of packets, connections and fragmentation can be displayed by the following
command:
CLI> show firewall statistics
firewall: demosetup
packets
processed: 34455
passed : 34448
dropped : 0
rejected : 7
invalid interface : 0
no policy : 0
no connection setup: 5
protocol : 2
alg : 0
bandwidth : 0
connections
created : 68
closed : 10
timed out: 55
fragments
fragmented packets: 0
fragments received: 0
cached fragments : 0
lost fragments : 0

Use the following command to reset the firewall statistics:

CLI> clear firewall counters
Use the following command to clear a firewall connection by its ID:

CLI> clear firewall connection conn-id <id>
Use the following command to clear firewall connections generated by a policy rule. Use the obsolete
keyword to clear only the firewall connections generated by an obsolete instance of a policy rule.
CLI> clear firewall connection policy-rule <name> [obsolete]

1 5 O P E N S O U R C E S O F T W A R E
The OneAccess Operating System (OneOS) includes source code covered by the GNU General Public
License (GPL) terms and conditions. As a result the OneOS distribution terms allow distribution in source
code form of the software library named hereafter:
• Zebra routing software, Copyright (C) 2000 Kunihiro Ishiguro.
• 4.4BSD software, Copyright (C) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The
Regents of the University of California. All rights reserved.
The GPL files can be obtained by connecting to the following URL: http://www.oneaccess-
net.com/en/fsoft/fsoft.html. OneAccess is committed to provide the sources on request for 3 years after
time of purchase of the product.

User Ref Oneos Book Advanced Ip

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

User Ref Oneos Book Advanced Ip

Uploaded by

Copyright:

Available Formats

O N E O S

381, Avenue du Général de Gaulle

articles 425 and in accordance with the penal code.

after Sales Service division.

Twenty-first edition: April 2016

Advanced IP User Guide Page 1.1-2 of 277

Advanced IP User Guide Page 1.1-3 of 277

1.1 FEATURE MATRIX

Advanced IP User Guide Page 1.1-4 of 277

Advanced IP User Guide Page 1.1-5 of 277

Advanced IP User Guide Page 1.1-6 of 277

Advanced IP User Guide Page 1.1-7 of 277

1.2 TABLE OF CONTENTS

1 INTRODUCTION ....................................................................................................................................... 1.1-3

Advanced IP User Guide Page 1.2-8 of 277

3.1.2 DHCPv6 Pool Configuration ............................................................................................. 3.1-35

Advanced IP User Guide Page 1.2-9 of 277

5.7.1 Protecting a Tunnel with an IPsec Profile ......................................................................... 5.7-81

Advanced IP User Guide Page 1.2-10 of 277

6.2.5.2 Re-Registration on Rekey ....................................................................................6.2-144

Advanced IP User Guide Page 1.2-11 of 277

9.2.2.6 Modification of BGP Routing ................................................................................9.2-183

Advanced IP User Guide Page 1.2-12 of 277

10.3.6.2 Override MTU Check ..........................................................................................10.3-216

Advanced IP User Guide Page 1.2-13 of 277

13.3.3.3 Configuring Proxy support ..................................................................................13.3-250

Advanced IP User Guide Page 1.2-14 of 277

2.1 INTRODUCTION TO ONEOS IPV6 FEATURES

2.1.1 IPv6 Address Writing Rules

2.1.1.1 IPv6 Addresses

Normal Format Compressed Format

The hexadecimal writing of IPv6 addresses is not case-sensitive in OneOS CLI.

2.1.1.2 IPv6 Prefix

Advanced IP User Guide Page 2.1-15 of 277

2.1.1.3 IPv6 URL

2.1.2 IPv6 Features

2.1.2.1 IPv6 Fast Forwarding

2.1.2.2 Multiple IPv6 Addresses per Interface

2.1.2.3 IPv6 Virtual Interfaces

2.1.2.4 IPv6 Static Routing

2.1.2.5 IPv6 Dynamic Routing

2.1.2.6 IPv6 Virtual Routing and Forwarding (VRF)

Advanced IP User Guide Page 2.1-16 of 277

2.1.2.7 IPv6 Packet Processing Path

2.2 IPV6 CONFIGURATION COMMANDS

2.2.1 IPv6 activation on an interface

Advanced IP User Guide Page 2.2-17 of 277

2.2.2 IPv6 Addresses Configuration

2.2.2.1 Static IPv6 Address configuration

CLI(config-if)> no ipv6 address prefix <ipv6-address>/<prefix-len>

2.2.2.2 Stateless Auto-configuration of IPv6 Address

2.2.2.3 Static IPv6 anycast address configuration

CLI(config-if)> no ipv6 address prefix <ipv6-addr>/<prefix-len> anycast

Advanced IP User Guide Page 2.2-18 of 277

2.2.2.4 Static IPv6 address configuration using a EUI-64 interface ID

CLI(config-if)> no ipv6 address prefix <ipv6-addr>/<prefix-len> eui-64

2.2.2.5 Static IPv6 link-local address configuration

2.2.2.6 IPv6 address configuration using prefix delegation

Advanced IP User Guide Page 2.2-19 of 277

2.2.2.7 Configuration of IPv6 Addressing for PPP Interfaces

2.2.3 Enabling IPv6 Forwarding

2.2.4 Static IPv6 Routes Configuration

o ipv6-address-prefix is under the form X:X:X:X::X/<0-128> (see 2.1.1.2).