Datacom 2500

ACCESS ROUTERS
Version 1.18.4
QUICK CONFIGURATION GUIDE
204.4305.14 - February 17, 2023

DM2500 - Quick Configuration Guide Contacts
Contacts
Technical Support
Datacom has available a support portal - DmSupport, to help the customers in use and config of our equipment.
Access to the DmSupport can be made through link: https://supportcenter.datacom.com.br
In this site the following are available: firmwares, technical datasheets, config guide, MIBs and manuals for down-
load. In addition, it allows opening of calls for assistance with our technical team.
Telephone Number: +55 51 3933-3122
We would like to highlight that our assistance through telephone support is available from Monday through Friday from
08:00 AM through 05:30 PM.
Important: For support assistance 24x7, please request a quotation to our sales department.
General Information
For any other additional information, please visit the https://www.datacom.com.br/en or call:
DATACOM
Rua América, 1000
92990-000 - Eldorado do Sul - RS - Brazil
+55 51 3933-3000
DATACOM 204.4305.14 - February 17, 2023 2

DM2500 - Quick Configuration Guide Product Documentation
Product Documentation
This document is part of a set of documents prepared to provide all necessary information about DATACOM products.
Software Platform
• Quick Configuration Guide - Provides instructions on how to set functionalities in a quick manner in the equipment
• Release Notes - Provides instructions on the new functionalities, identified defects and compatibilities between
Software and Hardware
Hardware Platform
• Datasheet - Provides the Hardware and Software technical characteristics of product
• Installation Guide - Provides instructions on the procedures covering product installation
The availability of some documents can vary depending on the type of product.
Access https://supportcenter.datacom.com.br to locate the related documents or contact the Technical Support for
additional information.

DM2500 - Quick Configuration Guide Introduction to the document
Introduction to the document
About this Document
The present document is a set of instructions that provide a quick and objective explanation on the use of the functionalities
available in the product. It also covers the initial configs that are generally required immediately after installation of the
product.
This document was developed to be used as an eventual source for solution of technical issues, and for this reason its
sequential reading is not mandatory. However, if you are setting the equipment and is not familiar with the product,
reading of the document since the beginning is recommended.
It is presumed that the individual or individuals that manage any aspect of the product should have the basic knowledge of
Ethernet, network protocols and communication networks in general.
Audience
This guide is directed to network administrators, technicians or teams qualified to install, set, plan and maintain this
product.
Conventions
To facilitate understanding of the present manual, the following conventions were adopted:
Icons
Icon Type Description
Note The notes explain in a better manner a detail included in the text.

DM2500 - Quick Configuration Guide Introduction to the document
Icon Type Description
WEEE Directive Symbol (Applicable in the European Union and other European coun-
tries with separate collection systems). This symbol on the product or its packaging
indicates that this product must not be disposed of with other waste. Instead, it is your
responsibility to dispose of your waste equipment by handing it over to a designated
collection point for the recycling of waste electrical and electronic equipment. The
Note
separate collection and recycling of your waste equipment at the time of disposal
will help conserve natural resources and ensure that it is recycled in a manner that
protects human health and the environment. For more information about where you
can drop off your consumer waste equipment for recycling, please contact your local
city recycling office or the dealer from whom you originally purchased the product.
This symbols means that, case the procedure was not correctly followed, may exist
Warning
electrical shock risk.
Warning Represents laser radiation. It is necessary to avoid eye and skin exposure.
Warning Non-ionizing radiation emission.
This symbol means that this text is very important and, if the orientations were not
Caution
correct followed, it may cause damage or hazard.
Indicates that equipment, or a part is ESDS (Electrostatic Discharge Sensitive). It should

Caution
not be handled without grounding wrist strap or equivalent.
A warning icon requests special attention to the conditions that, if not avoided, may cause physical damages
to the equipment.
A caution icon requests special attention to the conditions that, if not avoided, may result in risk of death of
serious injury.

DM2500 - Quick Configuration Guide Table of Contents
Table of Contents
Contacts 2
Product Documentation 3
Introduction to the document 4
1 Basic Management 12
1.1 First Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.1 Installing and energizing the equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.2 Accessing the equipment using the console port . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.3 Accessing the equipment using a ethernet port . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.4 Accessing the equipment for the first time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Firmware Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1 Firmware Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 CLI Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.1 Operational Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2 Configuration Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.3 Configuration Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.4 Pasting configuration commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1 Restoring the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.2 Restoring to the Factory Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 Files Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.1 Configuration to a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.2 Exporting Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.3 Importing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.4 Handling Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.5 Configuration from a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5.6 Configuration from SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Equipment Management 21
2.1 Management Interface Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.1 Management through an exclusive interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.2 Shared management in a physical interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 CLI Access Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 Configuring the SSH and Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Hostname Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Banner Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 System Clock Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

DM2500 - Quick Configuration Guide TABLE OF CONTENTS
2.6 Summertime Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.7 Default Password Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 Network Management 27
3.1 NTP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1 NTP access restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.2 Verifying NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Syslog Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Verifying Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 SNMP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Configuring the SNMPv2 protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Configuring the SNMPv3 protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.4 Verifying SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Last reboot reason . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1 Checking the last reboot reason . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Connectivity Tools 34
4.1 Ping and Ping6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Traceroute and Traceroute6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 SSH Client and Telnet Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Source Address Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Wake on Lan (Wol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 OAM 38
5.1 NetFlow/IPFIX Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.1 Verifying NetFlow/IPFIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Macros and Watch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.1 Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.2 Verifying Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.3 Watch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.4 Performing an action with Watch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.5 Verifying Watch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3 TWAMP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1 Setting the TWAMP Reflector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.2 Setting the TWAMP Sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.3 Setting the TWAMP behind NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.4 IP SLA Object Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.5 TWAMP Comparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3.6 Verifying Twamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.4 Tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5 Dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6 Show tech-support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7 Monitor Bandwidth Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7.1 Configuring the server mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7.2 Configuring the client mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6 Users Authentication 50
6.1 Change the default password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2 Local Users Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3 TACACS+ Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.1 Verifying TACACS+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4 RADIUS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4.1 Verifying RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7 Interfaces 55
7.1 Ethernet Interfaces Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.1.1 Setting speed and duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.1.2 Verifying Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2 Loopback Interface Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2.1 Verifying Loopback Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3 Bridge Interface Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3.1 Verifying Bridge Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.4 Bonding Interfaces (Aggregation) Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.4.1 Bonding Interface Static Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.4.2 Bonding Interface Dynamic Mode (LACP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.4.3 Verifying Bonding Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8 LTE Connection 61
8.1 LTE Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.2 LTE configuration using template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.3 Manual LTE Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.4 Verifying LTE Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9 IP Services 64
9.1 DHCPv4 Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.1.1 Configuring DHCPv4 Server Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.1.2 Verifying DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.2 DHCPv6 Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.2.1 Verifying DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

9.3 DHCPv4 Relay Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

9.3.1 Verifying DHCPv4 Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.4 DHCPv6 Relay Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.4.1 Verifying DHCPv6 Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.5 DHCPv4 Client Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.5.1 Verifying DHCPv4 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.6 DHCPv6 Client Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.6.1 Verifying DHCPv6 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.7 PPPoE Client Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.7.1 Verifying PPPoE Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
10 Routing 71
10.1 Routing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
10.1.1 Static Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
10.1.2 Routing between VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
10.1.3 Enabling ECMP in static routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
10.1.4 Verifying Static Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.2 PBR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
10.2.1 Verifying PBR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
10.3 RIP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
10.3.1 Verifying RIP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
10.4 RIPng Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
10.4.1 Verifying RIPng Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.5 OSPFv2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.5.1 Configuring a Virtual Link in OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.5.2 Enabling ECMP in OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
10.5.3 Setting LSA filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
10.5.4 Filtering of LSAs announced for other areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
10.5.5 Filtering of LSAs announced for the specified area . . . . . . . . . . . . . . . . . . . . . . . . . . 79
10.5.6 Filtering of LSAs using prefix-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
10.5.7 Verifying OSPFv2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.6 OSPFv3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.6.1 Enabling ECMP in OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.6.2 LSA filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.6.3 Verifying OSPFv3 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.7 BGP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.7.1 iBGP IPv4 neighbor configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
10.7.2 eBGP IPv4 neighbor configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
10.7.3 eBGP IPv4 neighbor configuration with loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . 85

10.7.4 Verifying BGP IPv4 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10.7.5 iBGP IPv6 neighbor configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
10.7.6 eBGP IPv6 neighbor configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.7.7 eBGP IPv6 neighbor configuration with loopback . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.7.8 Communities configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10.7.9 Enabling ECMP in BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.7.10 AS-Override configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.7.11 Verifying BGP IPv6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
10.8 BFD Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
10.8.1 BFD in static routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
10.8.2 BFD in OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
10.8.3 BFD in OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
10.8.4 BFD in BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
10.8.5 Verifying BFD Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
10.9 VRRP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
10.9.1 Setting the VRRPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
10.9.2 Setting the VRRPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10.9.3 Setting the VRRP Track Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
10.9.4 Setting the VRRP Track Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
10.9.5 Setting the VRRP Transition Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
10.9.6 Verifying VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
10.10 PIM Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
10.10.1 Setting IGMP version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
10.10.2 Verifying PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
10.11 VRF Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
10.11.1 Setting the VRF lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10.11.2 Verifying VRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
10.12 ECMP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
10.12.1 Load balance per packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
10.12.2 Load balance per flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
10.12.3 Disabling ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
11 Tunneling 111
11.1 GRE tunnels Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
11.1.1 IPv4 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
11.1.2 IPv6 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
11.1.3 GRE IPV4 Tunnel with IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
11.2 IPSec tunnels Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
11.2.1 Site-to-site IPsec IPv4 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

11.2.2 Site-to-site IPsec IPv6 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

11.2.3 Site-to-site tunnel IPsec with NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.2.4 IPsec Tunnel with Virtual Tunnel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.2.5 IPsec Tunnel via LTE Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.2.6 Dynamic Multipoint IPsec VPNs (DMVPN) Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
12 QoS 131
12.1 Rate Limit Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
12.2 Classification, priorization and remarking of egress traffic Configuration . . . . . . . . . . . . . . . . . 132
12.2.1 Classification and priorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
12.2.2 Remarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
12.2.3 Classifying locally generated packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
12.2.4 Classifying by address or port range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
12.3 DSCP remarking of ingress traffic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
12.3.1 Configuring the shaper on ingress traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13 Security 137
13.1 Configuring the NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.1.1 Source NAT (SNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
13.1.2 Destination NAT (DNAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
13.1.3 Verifying NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
13.2 Configuring the Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
13.2.1 Configuring ACL Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
13.2.2 Configuring the stateful Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
13.2.3 Firewall protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
13.2.4 Verifying Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
13.3 Verifying Open Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
13.4 802.1X Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
13.4.1 Enabling dot1x on ethernet/bonding interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
13.4.2 Enabling dot1x on bridge interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
13.4.3 Verifying dot1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Legal Note 152
Warranty 152

DM2500 - Quick Configuration Guide 1 Basic Management
1 Basic Management
This chapter contains the following sections:
• First login
• Firmware Management
• CLI Overview
• Configuration Management
• Files Management
1.1 First Login
1.1.1 Installing and energizing the equipment
Please check the detailed instructions in the equipment Installation Guide.
1.1.2 Accessing the equipment using the console port
Accessing the equipment using the console port
Access to equipment CLI can be carried out through the console port. A serial cable is required. A terminal emulator such
as Hyper Terminal or similar is also needed. The terminal settings must be set as 9600 8N1.
1.1.3 Accessing the equipment using a ethernet port
Accessing the equipment using an Ethernet port
In the factory configuration, Ethernet interface eth1 is configured with IP address 192.168.0.25/24. SSHv2 and TELNET are
enabled by default.

It is possible to manage the equipment through any Ethernet interface. Additional configuration can be performed to allow
access through other interface and also do disable SSHv2 or TELNET protocols, if required.
1.1.4 Accessing the equipment for the first time
To login to the equipment for the first time, the admin user and admin default password must be used.
dm2500 login: admin

Password: admin
dm2500:~$
For security purposes, it is highly recommended to change the equipment default password.
Please read the Users’ Authentication chapter to check on how to proceed to change the user password.
1.2 Firmware Management
1.2.1 Firmware Update
Contact DATACOM Technical support to check the firmware images available for download and installation
according to your products.
It will be necessary to use a PC with a TFTP, SCP or HTTP Server installed in order to download the firmware to the
equipment.
It is possible to check the firmware installed in the equipment using the show firmware command:
dm2500:~$ show firmware

Software:
Version Release Date State
----------------- --------------------- -----------------
1.4.2 2018-07-06 14:25:24 Active/Startup
1.4.0 2018-06-22 09:57:23 Inactive
State:
Active - Running firmware
Invalid - Partition is empty or corrupted
Inactive - Firmware is not running
Startup - Firmware to be used in the next boot
To download the firmware file through TFTP, use the following command:
firmware add tftp://172.22.107.11/pd3701-1.4.4.swu

Warning! This will overwrite 1.4.0.
Proceed with this operation? (Yes/No) [No] yes
1.4.4 loaded successfully in inactive partition.
Do you want to mark the new firmware as startup and reboot now? (Yes/No) [No] yes [Enter]

An automatic reboot will occur after the firmware update procedure.
If it is decided not to perform the firmware swap and reboot after the download, the user may execute the firmware swap
later:
dm2500:~$ firmware swap
Do you want to swap the startup firmware partition? [Yes/No] [Yes] yes
1.4.4 is now the startup firmware partition.
Proceed with reboot? (Yes/No) [No] yes
The user may choose not to reboot the equipment after firmware download and activation to finish the upgrade at a later
time. To finish the firmware upgrade, the user should use the reboot command:
reboot
1.3 CLI Overview
DM2500 CLI supports the configuration and operational.
1.3.1 Operational Mode
After login in the equipment, the CLI is in the operational mode. In this mode it is possible to check the equipment
information, run connectivity tests and more. In this mode, it is not possible to modify the equipment configuration.
While in the operational mode, the CLI prompt will display as prefix the name of host followed by the $ character.
dm2500:~$
To check the list of possible operational commands, press the question mark ? or the [Tab] key in the
prompt.
It is possible to check some important information of the equipment in the operational mode using the following
commands:
Comando Descrição
show inventory Show equipment inventory
show environment Shows value of temperature sensors
show psu Shows power supply status

Comando Descrição
show firmware Shows firmware version
show configuration Shows current configuration of the equipment
show system cpu-utilization Shows CPU utilization
show system memory Shows memory usage
show system uptime Shows equipment uptime
show system clock Shows equipment current time
show users Shows users connected to the equipment
show system storage Shows the system storage space
It is possible to execute any command of the operational mode in the configuration mode adding the keyword run before
the command. Below there is an example:
run show configuration
1.3.2 Configuration Mode
To modify the configuration it is necessary to enter in the configuration mode through the following command:
configure
After entering in the configuration mode, the CLI prompt will exhibit the # character as indicated below:
dm2500#
To exit the configuration mode, the user should use the following command:
dm2500# exit
1.3.3 Configuration Types
DM2500 has three configurations, the candidate, the startup and the running configuration, as explained below.
• Candidate configuration: While the user changes the configuration and do not commits it, the configuration
is temporarily saved as candidate. If the equipment is rebooted or the user quits the session, the candidate
configuration is lost.
• Running configuration: After the user commits the candidate configuration, it is applied to the running configura-
tion. If the equipment reboots, the running configuration is lost.

• Startup configuration: The startup configuratoin is loaded when the device boots. After the commit command, the
user should run the save command to save the running configuration to the startup configuration.
To activate the candidate configuration, is necessary to copy it to the running configuration. The commit command
applies the candidate config to the running config.
commit
The user can temporarily apply the candidate configuration. When executing the command commit-confirm, the
candidate config is applied. The user must execute the commit command to apply the config definitively. If the commit is
not execute, the configuration is rolled back after the default time of 10 minutes.
The default 10 minutos timeout can be changed, as shown below, where the timeout is set to 5 minutes.
commit-confirm 5
! Confirming the configuration commit

confirm
To save the running config to the startup config, the user should use the save command, which will save the configuration.
The configuration is saved by default in the config.boot file. The save command must be executed in the configuration
mode.
save
Saving configuration to ’config.boot’...
Done
[edit]
In the configuratoin mode, to discard all uncommited changes, the user can use the discard command.
discard
The use can check the current configuration using the show configuration command.
show configuration
To check the candidate configuration, the user can execute the show command while in configuration mode.
show
The check the differences between the current configuration and the candidate one, the user should execute the command
compare.
compare

1.3.4 Pasting configuration commands
To paste a large number of configuration lines, the paste mode should be used. In the configuration mode, enter the paste
command. Then, the configuration commands can be pasted. To apply the configuration and exit the paste mode, enter
the commit command.
Only configuration commands in the set or delete formats can be used.
In the example below, the user enters in the paste mode.
configure
paste
And then, the user pastes the configuration with the commit command at the end.
set system host-name DM2500-A

delete interfaces ethernet eth1 address
set interfaces ethernet eth2 address 10.0.0.1/24
set protocols static route 0.0.0.0/0 next-hop 10.0.0.254
commit
1.4 Configuration Management
1.4.1 Restoring the Configuration
To revert to the last commited configuration, the user should use the rollback command.
rollback
commit
To complete the rollback, a reboot is needed. Be aware that during this procedure, there will be a brief
service interruption.
1.4.2 Restoring to the Factory Config
To restore to the factory configuration, use the load default command.
The folloing procedure will erase the current configuration and load the factory config.

load default
commit
1.5 Files Management
1.5.1 Configuration to a File
The user can save the candidate configuration without needing to commit it, as shown below, where the candidate config
is saved to the CANDIDATE-CONFIG file.
save CANDIDATE-CONFIG
1.5.2 Exporting Files
The user can export a configuration file to a SCP, FTP or TFTP server. The following command will send via TFTP protocol
the CONFIG_1 file to the server 172.1.1.1.
save tftp://172.1.1.1/CONFIG_1
1.5.3 Importing Files
The command below shows how to copy the configuration file config_1 from TFTP server 192.168.0.15 to the equipment.
The load command will erase the current configuration and replace it by the configuration in the file.
configure
load tftp://192.168.0.15/config_1
commit
The merge command can also be used. It will merge the current configuration against the configuration present in the file.
configure
merge tftp://192.168.0.15/config_1
commit
1.5.4 Handling Files
To list all saved files, the user should use the show configuration files in the operational mode.
show configuration files
To show the content of a file, the user should use the command below in the operational mode.
show configuration files <file-name>

Do delete a file, use the command below.
delete configuration <file-name>
1.5.5 Configuration from a File
The load command replaces the candidate configuration with the configuration in the specified file.
load <file-name>
commit
It is possible to merge the candidate configuration with the configuration in a saved file. The configuration commands in
the file will be merged to the candidate configuration or will replace it in case of conflict.
merge <file-name>
commit
1.5.6 Configuration from SNMP
The DM2500 allows to configure the equipment through SNMP protocol using the DATACOM-ROUTER-B-MIB MIB.
The user will be able to use text mode configuration files previously created and made available on a TFTP server.
The equipment must have management and SNMP previously configured. For more information, see
the chapter Configuring the SNMP protocol. For security reasons, we suggest using SNMPv3 for these
operations.
The following command sequence is supported only on computers running Linux operating system.
Import configuration file
Suppose the user wants to apply the cfg-snmp-dm2500 configuration to the running-config of the DM2500 with IPv4
172.22.109.30 device via SNMP protocol using a TFTP server with IPv4 address 10.0.120.96.
Below is the command sequence for applying the cfg-snmp-dm2500 file configuration to running-config.
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyFile-
Name.0 s cfg-snmp-dm2500
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyServerAd-
dress.0 a 10.0.120.96
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyProto-
col.0 i 1
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyDestFile-
Type.0 i 1
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyInit-
Transfer.0 i 2

snmpget -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyStatus.0
Export configuration file
Using the MIB DATACOM-ROUTER-B-MIB it is also possible to export the equipment startup-config using TFTP, FTP and
SFTP. The following is an example of backup using the SNMP protocol.
The equipment must have management and SNMP previously configured. For more information, see
the chapter Configuring the SNMP protocol. For security reasons, we suggest using SNMPv3 for these
operations.
The following command sequence is supported only on computers running Linux operating system.
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyServerAd-
dress.0 a 10.0.120.96
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyProto-
col.0 i 1
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyDestFile-
Type.0 i 2
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyFile-
Name.0 s cfg-snmp-dm2500
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyEx-
port.0 i 2
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyInit-
Transfer.0 i 2
snmpget -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyStatus.0
To use the FTP and SFTP protocols, it is necessary to configure the username and password as shown in the example.
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopy-
User.0 s username
snmpset -v3 -l authPriv -u userv3 -a SHA -A "user1234" -x AES -X "pass1234" 172.22.109.30 rtbConfigCopyPass-
word.0 s password

DM2500 - Quick Configuration Guide 2 Equipment Management
2 Equipment Management
This chapter will guide to user to perform equipment management configurations. This chapter contains the following
sessions:
• Management Interface Configuration
• CLI Access Configuration
• Hostname Configuration
• Banner Configuration
• System Clock Configuration
• Summertime Configuration
• Default Password Recovery
2.1 Management Interface Configuration
The equipment can be management through any interface with a configured IP address.
It is described how to configure a management IP address in those interfaces.
It is possible to configure an interface with IPv4 or IPv6 address for equipment management.
The diagram below represents the network topology which will be used as base in this section.
Management Interface Configuration
2.1.1 Management through an exclusive interface
This configuration mode is used when it is possible to use a dedicated ethernet interface for management. By default, the
IP address 192.168.0.25/24 is configured in the physical interface eth1.
In the procedure below, the default IP address is removed from eth1 and the new IP address 172.24.22.1/24 and gateway
172.24.22.254 are configured:

configure
delete interfaces ethernet eth1 address 192.168.0.25/24
set system gateway-address 172.24.22.254
commit
save
2.1.2 Shared management in a physical interface
In this configuration mode, the management IP address is assigned to a VLAN making it possible to configure another
VLANs and their repective IP addresses in the same interface. By default, the IP address 192.168.0.25/24 is configured in
the physical interface eth1.
In the procedure below, the default IP address is removed from eth1 and the new IP address 172.24.22.1/24 and gateway
172.24.22.254 are configured in the VLAN 10:
configure
delete interfaces ethernet eth1 address 192.168.0.25/24
set interfaces ethernet eth1 vif 10 address 172.24.22.1/24
commit
save
2.2 CLI Access Configuration
The SSH (Secure Shell) and TELNET are protocols used for access to the equipment terminal. Both are enabled in the
equipment factory configuration. It is recommended to deactivate the TELNET if it is not used, as it is a protocol less safe as
related to the SSH.
2.2.1 Configuring the SSH and Telnet
The next steps will show how to deactivate the TELNET protocol.
configure
delete service telnet
commit
If deemed necessary, it is possible to change the ports and enabled addresses to access the services. Considering that the
user would like to change the TELNET port from the 23 to port 2323. And, for the SSH the port will be changed from the 22
to port 2222.
The procedure below will show how to execute these configurations:
configure
set service telnet port 2323
set service ssh port 2222
commit
To persist the configuration after an eventual reboot, the user should use the save command after the commit command.

Below are the main commands available to check this feature. If the user is at configuration level, it is necessary to use the
keyword run before the command.
show system login users
2.3 Hostname Configuration
To configure the hostname DATACOM-ROUTER-R1, use the following commands:
configure
set system host-name DATACOM-ROUTER-R1
commit
save
2.4 Banner Configuration
The banner can be configured for pre-login and post-login.
The banner content must be configured in a single line and be between double-quotes (””).
It is possible to configure a multiline banner using the \n character to break lines.
The procedure below shows how to configure a pre-login banner:
configure
set system login banner pre-login "Access allowed only for \nauthorized personnel.
\n"
commit
save
The procedure below shows how to configure a post-login bannter:
configure
set system login banner post-login "Welcome to DM2500\n"
commit
save
2.5 System Clock Configuration
The time and date configuration is important for log and events viewing. The use can set the system clock from the
operatinal mode. Configuration commit is not needed.

It is recomended the use of a NTP server for centralized clock synchronization.
The syntax to configure date and time is: Month|Day|Hour|Minute|Year.
The command below shows how to set date and time to 08-jun-2017 15:40.
set system clock 060815402017
To change the timezone to Brazil/East, use the command below:
configure
set system time-zone Brazil/East
commit
save
To check the equipment date and time, use the command show system clock:
show system clock
2.6 Summertime Configuration
When a timezone is configured, the summertime is automatically configuring according to that timezone standard. In case
it is necessary to change the timezone, the commands below can be used:
configure
set system clock summer-time recurring BRST month-to-start 11
set system clock summer-time recurring BRST month-to-end 2
set system clock summer-time recurring BRST time-to-start 00:00
set system clock summer-time recurring BRST time-to-end 00:00
set system clock summer-time recurring BRST week-day-to-start 1
set system clock summer-time recurring BRST week-day-to-end 1
set system clock summer-time recurring BRST week-to-start 1
set system clock summer-time recurring BRST week-to-end 4
commit
save
2.7 Default Password Recovery
To reset the admin user password on the DM2500, it is necessary to access the equipment through the console and restart
it. During boot, when you see the message Hit Ctrl+C to stop autoboot: 3, press CTRL+C to access U-Boot. You will be
prompted for a password.

bsup .............
Stage 1 bootloader
Stage 2 bootloader (Build time: Oct 29 2020 - 14:01:38) (DM2500-0.1-0)
Quad-Core UPC, Core clock: 1500 MHz, IO clock: 600 MHz, DDR clock: 667 MHz (1334 Mhz DDR)
DRAM: 1 GiB
Clearing DRAM...... done
Searching for a valid stage 3 bootloader... Found at first region
Stage 3 bootloader (Build time: May 20 2020 - 15:15:02) (DM2500-0.2-0)
Quad-Core UPC, Core clock: 1500 MHz, IO clock: 600 MHz, DDR clock: 667 MHz (1334 Mhz DDR)
DRAM: 1 GiB
Clearing DRAM...... done
Hit Ctrl+C to stop autoboot: 1
Equipment info: SN 5474034 MAC 70:cd:91:69:80:c4
Password:
To generate the U-Boot password, it is necessary to contact Datacom Support and inform the device’s serial number and
MAC address, displayed during boot. After entering the password and pressing ENTER, type printenv.
Equipment info: SN 5474034 MAC 70:cd:91:69:80:c4

Password: ********
dm2500# printenv
...
octeon_boot=bootoctlinux $loadaddr coremask=$coremask mem=0 console=ttyS0,$baudrate root=$rootfs_dev root-
wait rootfstype=sqs
...
dm2500#
Execute the command below to load the factory configuration by adding the parameter dmrestore_cfg at the end of the
line.
dm2500# edit octeon_boot
edit: bootoctlinux $loadaddr coremask=$coremask mem=0 console=ttyS0,$baudrate root=$rootfs_dev rootwait rootf-
stype=squashfs dmrestore_cfg
dm2500#
Check if the edit was successful using the printenv command.
dm2500# printenv
...
octeon_boot=bootoctlinux $loadaddr coremask=$coremask mem=0 console=ttyS0,$baudrate root=$rootfs_dev root-
wait rootfstype=squashfs dmrestore_cfg
...
dm2500#
Execute run bootcmd to load a default configuration.
dm2500# run bootcmd

Booting system from second firmware region...
Allocating memory for ELF segment: addr: 0xffffffff80800000 (adjusted to: 0x800000), size 0x1066850
## Loading big-endian Linux kernel with entry point: 0xffffffff80f3bbe0 ...
Bootloader: Done loading app on coremask:
0xf
Starting cores:
0xf
Initializing, please wait...
Offload disabled
Loading configuration
Force default config. Backup to restored-config.bkp. Default config was restored.
dm2500 login:
Use username and password admin to login to the device.

dm2500 login: admin

Password:
Last login: Tue Feb 8 18:16:14 UTC 2022 on ttyS0
dm2500:~$
The commands to change the password of a local user can be found in the topic Change the default password.
The last configuration can be restored as shown below.
dm2500:~$ configure
l[edit]
[edit]
dm2500# load restored-config.bkp
Loading configuration from ’restored-config.bkp’...
Load complete. Use ’commit’ to make changes active.
[edit]
dm2500# commit
[edit]
dm2500-cpe-client# save
Saving configuration to ’config.boot’...
Done
[edit]
dm2500-cpe-client# exit
exit
dm2500-cpe-client:~$

DM2500 - Quick Configuration Guide 3 Network Management
3 Network Management
This chapter will guide to user to perform network management configurations. This chapter contains the following
sessions:
• NTP Configuration
• Syslog Configuration
• SNMP Configuration
• Last reboot reason
3.1 NTP Configuration
The NTP (Network Time Protocol) is used to synchronized the system clock to a remote server. That is important to log and
event visualization.
The DM2500 can act as both a server (provides time) and client (queries time) simultaneously.
It is possible to configure NTP with IPv4 or IPv6 addresses.
The scenario below will be used to show the NTP configuration.
Configuring the NTP protocol
To configure the DM2500 as client of two NTP servers with IPv4 addresses 172.24.22.201 and 172.24.22.202, follow the
procedure below:
configure
set system ntp server 172.24.22.201
commit
save
After the NTP client is configured, the router will also be acting as an NTP server through the active interfaces.
Configure prefer parameter for marks the server as preferred. All other parameters of quality being equal, this host will be
chosen for synchronization among a set of correctly operating hosts.

configure
set system ntp server 172.24.22.202 prefer
commit
save
The available commands for troubleshooting can be found in the topic Verifying NTP.
3.1.1 NTP access restrictions
NTP access restrictions add access rules to the router, acting as a firewall.
The figure below illustrates a scenario with DM2500 synchronizing the clock from an Internet NTP server and acting as an
NTP server with access rules.
NTP server
Suppose DM2500 synchronizes the clock over the Internet with the NTP server 200.160.7.186 and the administrator wants
the router to act as an NTP server only for the device with IP address 10.0.120.1 and devices on the 172.22.108.0/24 network.
The settings below will demonstrate how to perform this procedure.
configure
set system ntp access-control rule 1 action ’permit’
set system ntp access-control rule 1 match-group ’1’
set system ntp access-control rule 1 permit ’serve’
set system ntp access-group 1 address ’10.0.120.1’
set system ntp access-control rule 2 action ’permit’
set system ntp access-control rule 2 match-group ’2’
set system ntp access-control rule 2 permit ’serve’
set system ntp access-group 2 address ’172.22.108.0/24’
set system ntp server ’200.160.7.186’
commit
save
Suppose the administrator wants the router to act only as an NTP client, not allowing it to act as a server. The settings
below will demonstrate how to perform this procedure.

configure
set system ntp access-control default action deny-all
commit
save
The available commands for troubleshooting can be found in the topic Verifying NTP.
3.1.2 Verifying NTP
Below are the main commands available to check the feature. If the user is at the config level, the usage of the keyword
run before the command is required.
show ntp
show ntp detail
show ntp <IP Server>
show ntp authentication
show vrf <vrf-name> ntp
show vrf <vrf-name> ntp detail
show vrf <vrf-name> ntp <IP Server>
show vrf <vrf-name> ntp authentication
show system clock
3.2 Syslog Configuration
According to RFC5424, syslog protocol is used to transport log messages to a centralized server. for instance, if a Ethernet
interface goes down, a message informing that status change will be sent to the server. That is important for log visualization
in an unique and centralized location. DM2500 does no support log severity. All logs are sent to the server once it is
configured.
It is possible to configure a Remote Syslog with IPv4 or IPv6 addresses.
The topology below is used to demonstrate the Remote Syslog configuration.
Configuring a syslog remote server

The following procedure shows how to configure the DM2500 as a Remote Syslog server client with IPv4 address 10.1.100.7:
configure
set system syslog host 10.1.100.7
commit
save
The available commands for troubleshooting can be found in the topic Verifying Syslog.
3.2.1 Verifying Syslog
show configuration | match syslog

show log
show log tail
clear log
3.3 SNMP Configuration
SNMP is a protocol that helps network administrators to manage devices, identify and troubleshoot problems in the
network.
The SNMP protocol has three versions:
Command Description
The original SNMP version does not have any type of security, since it
SNMPv1
uses a plain text community for authentication.
This version was developed to fixed some v1 problems, but security is

SNMPv2
still ad issue since the plain text community is still used.
SNMPv3 supports encripted authentication and payload. Authentication

SNMPv3 can use SHA or MD5. Payload supports DES or AES encription. It is
recommended to use SNMPv3, mainly in non-trusted networks.
It is possible to configure the SNMP protocol with IPv4 or IPv6 addresses.
The topology bellow will be used to illustrate the SNMP protocol configuration.

Configuring the SNMP protocol
3.3.1 Configuring the SNMPv2 protocol
To enable the SNMPv2 protocol with private (rw) community for read or write and send traps to server 172.22.1.252, the
following procedure can be used:
configure
set service snmp community private authorization rw
set service snmp trap-target 172.22.1.252
commit
save
The available commands for troubleshooting can be found in the topic Verifying SNMP.
3.3.2 Configuring the SNMPv3 protocol
The SNMP protocol follows a hierarchical tree, due this a view shows from which branch is possible to
access the OIDs. For example: If configured root(1).iso(3).org(6).internet(1) access will be allowed to all OIDs
starting with 1.3.6.1, in other words, all OIDs supported by the equipment.
The example below shows the SNMPv3 configuration with packet payload encrypted using AES and user userv3 plus
password user1234 encrypted using SHA. The views configured allow only access to IF-MIB (1.3.6.1.2.1.2.2.1) and SysName
(1.3.6.1.2.1.1.5.0). The SNMP Traps are sent to 172.22.1.252 server.
configure
set service snmp v3 engineid ’0x80001f8880243d9cbd000000005e5d04ce’
set service snmp v3 user userv3 mode ro
set service snmp v3 user userv3 auth plaintext-key user1234
set service snmp v3 user userv3 auth type ’sha’
set service snmp v3 user userv3 privacy plaintext-key pass1234
set service snmp v3 user userv3 privacy type ’aes’
set service snmp v3 view OidView oid 1.3.6.1.2.1.1.5.0
set service snmp v3 view OidView oid 1.3.6.1.2.1.2.2.1
set service snmp v3 group ReadOnlyGroupAuthPriv seclevel priv
set service snmp v3 group ReadOnlyGroupAuthPriv mode ro
set service snmp v3 group ReadOnlyGroupAuthPriv view OidView
set service snmp v3 user userv3 engineid ’0x80001f8880243d9cbd000000005e5d04ce’
set service snmp v3 user userv3 group ReadOnlyGroupAuthPriv
set service snmp v3 trap-target 172.22.1.252 auth plaintext-key ’user1234’
set service snmp v3 trap-target 172.22.1.252 auth type ’sha’

set service snmp v3 trap-target 172.22.1.252 engineid ’23’

set service snmp v3 trap-target 172.22.1.252 user ’userv3’
commit
save
3.3.3 SNMP Traps
The SNMP agent also has the function of generating alerts (Traps). To send a SNMP Trap is necessary to configure at least
one group as shown below:
configure
set service snmp trap-enable config
set service snmp trap-enable cpu-core
set service snmp trap-enable cpu-overall
set service snmp trap-enable dying-gasp
set service snmp trap-enable link-up
set service snmp trap-enable link-down
set service snmp trap-enable login
set service snmp trap-enable memory
set service snmp trap-enable temperature
commit
save
3.3.4 Verifying SNMP
show configuration | match snmp
3.4 Last reboot reason
The DM2500 reports the latest reason for the reboot. This information is notified via SNMP, CLI and system log.
3.4.1 Checking the last reboot reason
To check the latest reboot reason in the CLI, just execute the command below:
show system reboot

The information on the last reboot reason via SNMP can be consulted through the MIB DMOS-REBOOT-MIB in the object
rebootReason.
The example below shows that the last reboot occurred due to the firmware update.
DMOS-REBOOT-MIB::rebootReason.0 = STRING: firmware upgrade

DM2500 - Quick Configuration Guide 4 Connectivity Tools
4 Connectivity Tools
The DM2500 offers some tools to check the network connectivity as well as to access equipment as from DM2500 itself.
The user should use the keyword run before the command if it is in the config mode.
• Ping and Ping6
• Traceroute and Traceroute6
• SSH Client and Telnet Client
• Source Address Configuration
• Wake on Lan (Wol)
4.1 Ping and Ping6
The ping command is a common method to check the connectivity of the equipment with the other equipment or to test a
specific protocol.
To execute a ping with IPv4 address, follow the procedure below:
ping 5.178.41.1
PING 5.178.41.1 (5.178.41.1) 56(84) bytes of data.
64 bytes from 5.178.41.1: icmp_seq=1 ttl=61 time=2.15 ms
--- 5.178.41.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 2.065/2.139/2.272/0.074 ms
To execute a ping with IPv6 address, follow the procedure below:
ping6 2002:c0a8:fe05::6
PING 2002:c0a8:fe05::6(2002:c0a8:fe05::6) 56 data bytes
64 bytes from 2002:c0a8:fe05::6: icmp_seq=1 ttl=62 time=7.94 ms
--- 2002:c0a8:fe05::6 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 4.664/5.903/7.948/1.274 ms
4.2 Traceroute and Traceroute6
The traceroute command is a method to execute the network diagnosis informing the hop-by-hop connectivity through
which the pack is passing until the final destination.

To execute a traceroute with IPv4 address, follow the procedure below:
traceroute 5.178.41.1
traceroute to 5.178.41.1 (5.178.41.1), 30 hops max, 38 byte packets
1 192.168.48.3 (192.168.48.3) 2.029 ms 4.345 ms 1.751 ms
2 192.168.48.1 (192.168.48.1) 2.842 ms 2.488 ms 3.226 ms
3 192.168.254.22 (192.168.254.22) 3.582 ms 3.403 ms 3.622 ms
4 192.168.84.22 (192.168.84.22) 2.306 ms 1.802 ms 2.264 ms
5 5.178.41.1 (5.178.41.1) 2.219 ms 1.651 ms 54.376 ms
It is possible to specify an IP address as the source of the packets using the parameter source-address, as shown in the
following example.
traceroute 5.178.41.1 source-address 172.22.103.240
To execute a traceroute with IPv6 address, follow the procedure below:
traceroute6 2002:c0a8:fe05::6
traceroute to 2002:c0a8:fe05::6 (2002:c0a8:fe05::6) from 1997::c0a8:3002,
30 hops max, 16 byte packets
1 1997::c0a8:3001 (1997::c0a8:3001) 13.877 ms 2.298 ms 2.249 ms
2 2001::c0a8:3001 (2001::c0a8:3001) 3.64 ms 2.969 ms 2.869 ms
3 2002:c0a8:fe05::6 (2002:c0a8:fe05::6) 4.444 ms 3.624 ms 5.787 ms
It is possible to specify an IPv6 address as the source of the packets using the parameter source-address, as shown in the
following example.
traceroute 2002:c0a8:fe05::6 source-address 2020:ffff:ac16::67f0
4.3 SSH Client and Telnet Client
It is possible to access other equipment using SSH and TELNET protocols as from an equipment with DM2500.
To access an equipment with IPv4 192.168.1.254 address through the SSH, the user should use the command below,
specifying the user to be authenticated, in this example, the admin user:
ssh admin@192.168.1.254
It is possible to specify an IP address as the source of connection using the parameter source-address, as shown in the
following example.
ssh admin@192.168.1.254 source-address 172.22.103.240
To access an equipment with IPv4 192.168.1.254 address through the TELNET the user should use the command
mentioned below:
telnet 192.168.1.254

4.4 Source Address Configuration
It is possible to specify an IP address in the global configuration which will be used as the source address for the packets
generated by the applications configured.
The router will use the IP address of the most specific configuration as a precedence for the source address,
so if a command is executed or a protocol is configured with the source-address parameter, the request will
be sent with the specific IP address.
configure
set system ip source-address-global ’172.22.37.1/32’
set system ipv6 source-address-global ’2001:db8:37::1/128’
commit
Another possible form of configuration is to specify the source address that will be used by a given application.
IPv4 configuration.
configure
set system ip source-address copy-files ’172.22.37.1/32’
set system ip source-address dhcp-relay ’172.22.37.1/32’
set system ip source-address fw-upgrade ’172.22.37.1/32’
set system ip source-address ntp ’172.22.37.1/32’
set system ip source-address ssh ’172.22.37.1/32’
set system ip source-address telnet ’172.22.37.1/32’
set system ip source-address traceroute ’172.22.37.1/32’
commit
IPv6 configuration.
configure
set system ipv6 source-address copy-files ’2001:db8:37::1/128’
set system ipv6 source-address fw-upgrade ’2001:db8:37::1/128’
set system ipv6 source-address ntp ’2001:db8:37::1/128’
set system ipv6 source-address ssh ’2001:db8:37::1/128’
set system ipv6 source-address telnet ’2001:db8:37::1/128’
set system ipv6 source-address traceroute ’2001:db8:37::1/128’
commit
To persist the configuration after rebooting, the user must use the command save in the configuration mode.
Below the main command available to perform the verification of the global source-address. If the user is at the
configuration level, it is necessary to use the keyword run before the command.
show configuration | match source-address
It is possible to specify an IP address as the source of connection using the parameter source-address, as shown in the
following example.
telnet 192.168.1.254 source-address 172.22.103.240

4.5 Wake on Lan (Wol)
The Wake on Lan function is used to turn on or wake up a host in a sleep state by sending information through the network
interface. The device must support this functionality, so the configuration may change depending on the host.
Wake on Lan
Its operation is very simple, where basically a packet is sent to the interface and MAC of the host.
wake-on-lan interface eth4 host 50:e5:49:00:04:df

DM2500 - Quick Configuration Guide 5 OAM
5 OAM
This chapter shows a group of Operations, Administration and Maintenance (OAM) functionalities that provide indication of
network failure, fault location, performance information, data functions and diagnostic. It contains the following sections:
• NetFlow/IPFIX Configuration
• Macros and Watch
• TWAMP Configuration
• Tcpdump
• Dump
• Show tech-support
• Monitor Bandwidth Test
5.1 NetFlow/IPFIX Configuration
Flow monitoring service allows gathering information of IP flows. The Router supports NetFlow versions 5, 9 and 10, where
the last version is also known as IPFIX (IP Flow Information Export) which is based on the IETF (Internet Engineering Task
Force) standard. This standard defines how the information of the IP flow are formatted and transferred from exporter
to collector, gathering information of IPv4 flows, as shown in the figure below. The exporter periodically gathers the
information related to the packets that flow through the router to a record. Then the exporter sends the record in a UDP
packet to the collector.
NetFlow/IPFIX Scenario
Considering that the user would like to monitor the flow of the eth1 and eth2 interfaces and wishes to upload this
information to the 10.0.120.102 server through the 4739 port using version 10 of the Netflow. The procedure below will
show how to execute this configuration:

configure
set service netflow destination 10.0.120.102 port ’4739’
set service netflow version ’10’
set service netflow interface ’eth1’
ser service netflow interface ’eth2’
commit
It is possible configure NetFlow/IPFIX to provide a deterministic or random sampling for a subset of flow selecting only one
packet in a set of packets in a sequential order (n is parameter configurable by the user). It is said that the sampling is
deterministic if the user defines the sampling rate to 1 in each 100 packets, in this point the NetFlow/IPFIX will examine the
packets 1, 101, 201, 301 and so on. In the random sampling mode, the input packets are selected in a randomly order so that
one in each sequential n-packets is selected in average for its processing.
configure
! Sampling rate to 1 in each 100 packets
set service netflow sampling-rate 100
! Sampling mode
set service netflow sampling-rate 100 mode deterministic
commit
The available commands for troubleshooting can be found in the topic Verifying NetFlow/IPFIX.
5.1.1 Verifying NetFlow/IPFIX
show netflow configuration

show netflow export
show netflow interfaces
show netflow stats
show vrf <vrf-name> netflow configuration
show vrf <vrf-name> netflow export
show vrf <vrf-name> netflow interfaces
show vrf <vrf-name> netflow stats
5.2 Macros and Watch
This chapter introduces DM2500 tools for automating task execution, as well as the ability to create autorun scripts based
on the DM2500 feature status.
5.2.1 Macro
Macros are sets of CLI commands that can be executed by the user or through the Watch functionality of the DM2500.
Macro actions are performed in order, as if they were typed or performed by the operator.

The example below creates a macro to configure the NTP server:
set system macro 1 action 1 cli ’configure’

set system macro 1 action 2 cli ’set system ntp server 172.22.107.2’
set system macro 1 action 3 cli ’commit’
commit
To run the macro and configure the NTP server, use the command below:
system execute macro 1
The available commands for troubleshooting can be found in the topic Verifying Macro.
5.2.2 Verifying Macro
show configuration | match macro
5.2.3 Watch
Watch is a feature that allows the DM2500 to make decisions (macro executions) based on CLI command output. Watch
acts as an operator who executes commands on the equipment at predefined intervals, and from the output of these
commands proactively performs certain actions.
The example below performs a PING for an IPv4 every 10 seconds, looks for the 0 received expression on the command
return, and logs with the result of this operation.
set system watch 1 cli ’ping 10.0.120.96 count 1’

set system watch 1 interval ’10’
set system watch 1 match 1 regex ’0 received’
set system watch 1 ’log’
set system watch 1 ’enabled’
commit
The available commands for troubleshooting can be found in the topic Verifying Watch.
5.2.4 Performing an action with Watch
Once you have a Macro defined, you can run it using Watch. The steps below will demonstrate an application running via
Watch.

In the example below Watch will monitor the status of VRRP on the eth5 interface and will change the hostname of the
equipment for MASTER-ROUTER or BACKUP-ROUTER based on VRRP status.
Macro configuration:

set system macro 9 action 2 cli ’set system host-name MASTER-ROUTER’
set system macro 10 action 2 cli ’set system host-name BACKUP-ROUTER’
commit
Watch configuration:
set system watch 1 cli ’show vrrp interface eth5 group 1’

set system watch 1 ’log’
set system watch 1 match 1 regex ’MASTER’
set system watch 1 match 1 execute macro ’9’
set system watch 1 match 1 else execute macro ’10’
commit
Every 10 seconds the equipment will execute the command show vrrp interface eth5 and search for the keyword
MASTER. If the keyword is found, macro 9 will be executed, otherwise macro 10 will be executed.
The available commands for troubleshooting can be found in the topic Verifying Watch.
5.2.5 Verifying Watch
show configuration | match watch

show log watch
5.3 TWAMP Configuration
The TWAMP (Two-Way Active Measurement Protocol) protocol measures the network performance parameters as latency,
jitter and loss of packets. Implementation of the TWAMP server is based on the specifications described in the RFC 5357.
The server solution architecture in the TWAMP defines the following logical components:
• Session Reflector: Insert information to the test packets received and send them back.
• Server: Manages several TWAMP sessions.
The client solution architecture in the TWAMP defines the following logical components:
• Session Sender: Creates and sends TWAMP test packets to the Session-Reflector.

• Control Client: Sends requests to the TWAMP server in order to establish new sessions.
TWAMP Arquiteture
The TWAMP in the DM2500 has some restrictions as indicated in the note below:
• Up to 10 monitoring sessions are supported.
• No support to authentication/encryption exist.
• The reflector is capable to hear one single control port at each time.
The scenario below will be used to show the TWAMP configuration.
TWAMP Scenario
5.3.1 Setting the TWAMP Reflector
Considering that the user would like to configure a Sender and Reflector communicating through the 15000 port (default is
862). The procedure below will show how to execute this configuration:
configure
set service twamp reflector port 15000
commit
The available commands for troubleshooting can be found in the topic Verifying Twamp.

5.3.2 Setting the TWAMP Sender
configure
set service twamp sender session 1 port 15000
set service twamp sender session 1 destination-ip 20.20.20.250
set service twamp sender session 1 source-ip 10.10.10.250
set service twamp sender session 1 time-interval 10
set service twamp sender session 1 session-duration 120
set service twamp sender session 1 packet-size 1280
set service twamp sender session 1 enable
commit
In the sender it is possible to configure the option to have measurements in a unidirectional manner.
configure
set service twamp sender session 1 one-way-results
commit
It is possible to configure the TWAMP Sender as well as Reflector with support to IPv6, basically the change
in the configuration are the addresses that instead of being IPv4 will be IPv6.
5.3.3 Setting the TWAMP behind NAT
The source-ip and destination-ip fields respectively contain the sender and receiver addresses of the LAN path endpoints
over which a TWAMP test session is requested. They can be set to 0 (zero-address), where the IP addresses used for
messaging, source-ip or destination-ip, are behind NAT.
The scenario below is used to demonstrate setting up TWAMP Sender behind NAT.
Scenario Control-Client behind NAT
TWAMP Control-Client

configure
set service twamp sender session 1 zero-address enable
commit
If the TWAMP Reflector is behind NAT as in the scenario below, the destination address is changed to the WAN IP of the
DM2500.
Scenario Server TWAMP-Control behind NAT
TWAMP Control-Client
configure
set service twamp sender session 1 zero-address enable
commit
The available commands for NAT setting can be found in the topic Configuring the NAT.
5.3.4 IP SLA Object Tracking
TWAMP can act as a network monitor and generate path quality information between one or more routers. In conjunction
with the features Macros an Watch, it is possible to create an application to act as IP SLA on the network.

Scenario TWAMP IP SLA
Given the scenario in the figure above, imagine that the network administrator wants to monitor the latency of network
packets between R1 and R2, and network between R1 and R3. For this, two TWAMP sessions between R1 and R2 and
between R1 and R3.
Router 1 Configuration:
set service twamp sender session 1 ’enable’

set service twamp sender session 1 session-duration ’10’
set service twamp sender session 1 time-interval ’10’
set service twamp sender session 1 source-ip ’25.12.0.1’
set service twamp sender session 1 destination-ip ’25.12.0.2’
set service twamp sender session 2 ’enable’
set service twamp sender session 2 session-duration ’10’
set service twamp sender session 2 time-interval ’10’
set service twamp sender session 2 source-ip ’25.13.0.1’
set service twamp sender session 2 destination-ip ’25.13.0.3’
commit
In R2 and R3 just enable the reflector that will process to reflect packets back to R1:
set service twamp reflector

commit
To verify TWAMP operation on R1, use the following commands:
show twamp sender session 1

show twamp sender session 2
5.3.5 TWAMP Comparator
Given the previous scenario where R1 with IP 33.33.33.31 can reach R4 with IP 33.33.33.34 by two paths, one going through
R2 and the other going through R3. If R1 is running TWAMP by monitoring paths R1, R2, and R1, R3, Watch can force IP
33.33.33.31 traffic to pass through the best path according to TWAMP data results and metrics.
To simplify Watch rules its possible configure TWAMP session comparator on R1:

! Enables comparator 1 for TWAMP sections 1 and 2

set service twamp sender comparator 1 sessions ’1’
set service twamp sender comparator 1 sessions ’2’
! Assigns 100 (maximum) weight for packet loss
set service twamp sender comparator 1 weights loss ’100’
! Assigns weight 10 to delays
set service twamp sender comparator 1 weights max-delay ’10’
commit
Setting the weights parameter serves to prioritize the compared parameters.
The comparator fetches the results of the TWAMP 1 and 2 session and returns the (Best session):
show twamp sender comparator 1

Session 1
Status: Enabled/Running
Test: 4151
Max delay: 0.29 ms
Avg delay: 0.21 ms
Max jitter: 0.12 ms
Avg jitter: 0.02 ms
Loss ratio: 0.000000 % (weight: 100)
Calculated weight: 100
Session 2
Status: Enabled/Running
Test: 4170
Max delay: 0.27 ms (weight: 10)
Avg delay: 0.21 ms
Max jitter: 0.07 ms
Avg jitter: 0.03 ms
Loss ratio: 0.000000 % (weight: 100)
Calculated weight: 110
Best session: 2
With TWAMP configured and working in conjunction with the session comparator, the commands to configure Watch are:
set system watch 1 cli ’show twamp sender comparator 1’

! If you find ’Best session: 2’ run macro 2
set system watch 1 match 1 regex ’Best session: 2’
! If you find ’Best session: 1’ run macro 1
set system watch 1 match 2 regex ’Best session: 1’
commit
Every 10 seconds the equipment will execute show twamp sender comparator 1 and look for Best session: 2 or Best
session: 1 taking an action accordingly.
The action to force R1 traffic to go through the best way from the data and metrics of TWAMP results will change the
destination route metric for R1 to reach R2 using Macros.
Configuration of Macros that will be used to configure static routes in R1.
! Configure route for path R1, R2, and R4:

set system macro 1 action 2 cli ’set protocols static route 33.33.33.4/32next-hop 25.12.0.2 distance 1’
! Configure route for path R1, R3 and R4:

commit
5.3.6 Verifying Twamp
show twamp reflector

show twamp reflector clients
show twamp sender session [ <1-10> ]
show twamp sender session [ <1-10> ] details
show twamp sender session [ <1-10> ] details two-way
show twamp sender session [ <1-10> ] details far-end
show twamp sender session [ <1-10> ] details near-end
show twamp debug [ all | tail [ <number> ] ]
show vrf <vrf-name> twamp reflector
show vrf <vrf-name> twamp reflector clients
show vrf <vrf-name> twamp sender session [ <1-10> ]
show vrf <vrf-name> twamp sender session [ <1-10> ] details
show vrf <vrf-name> twamp sender session [ <1-10> ] details two-way
show vrf <vrf-name> twamp sender session [ <1-10> ] details far-end
show vrf <vrf-name> twamp sender session [ <1-10> ] details near-end
show vrf <vrf-name> twamp debug [ all | tail [ <number> ] ]
5.4 Tcpdump
The tcpdump is a packet capture resource that allows the network administrators to capture received and/or sent packets
by the equipment and analyze them locally or save them and export them for analysis using a tool such as the Wireshark.
To activate and capture packets, use the debug tcpdump command in the user mode.
dm2500:~$ debug tcpdump interface <interface> save-to-file count 100
The capture generated will be saved in the capture.pcap file and to export it to a TFTP server the user should use the
following command:
dm2500:~$ copy tcpdump-capture to tftp://172.22.107.11
5.5 Dump
The dump command is a diagnostic tool that generates an encrypted file requested by DATACOM support when the user
opens a ticket.
The user should use the dump command in the user mode.

dm2500:~$ dump
The command will generate a binary file with the date and time of the day, and the user can export it to a TFTP server.
DM2500:~$ copy dump ?

Possible completions:
dump_20181106092150.bin Copy from local dump file
DM2500:~$ copy dump dump_20181106092150.bin to tftp://172.22.107.11
######################################################################## 100.0%
5.6 Show tech-support
The show tech-support command is a diagnostic tool that provides several important information to debug problems that
occur in equipment operation.
The user should use the show tech-support command in the user mode.
dm2500:~$ show tech-support
The following show commands are automatically executed through the show tech-support command.
show firmware
show inventory
show environment
show psu
show config tree
show log dhcp
5.7 Monitor Bandwidth Test
The monitor bandwidth-test feature is a diagnostic tool which allow throughput test between client and server using
Iperf3 application. The DM2500 supports client and server modes using IPv4 and IPv6 addresses.
5.7.1 Configuring the server mode
The 5201 TCP port is used in server mode.
Only TCP Throughput test is supported.

The server supports IPv4 and IPv6 connections.
Configuring the DM2500 to wait for a client connection:
monitor bandwidth-test accept
Configuring the DM2500 to wait for a client connection in VRF:
monitor bandwidth-test vrf <vrf_name> accept
5.7.2 Configuring the client mode
The client supports IPv4 and IPv6 connections.
Configuring the DM2500 to connect to Iperf server:
monitor bandwidth-test initiate <ip_address>
Configuring the DM2500 to connect to Iperf server in VRF:
monitor bandwidth-test vrf <vrf_name> initiate <ip_address>

DM2500 - Quick Configuration Guide 6 Users Authentication
6 Users Authentication
Only one user account is configured by default in the DM2500. The user is the admin with the admin password and has the
admin privilege level.
• Change the default password
• Local Users Configuration
• TACACS+ Configuration
• RADIUS Configuration
6.1 Change the default password
For security reasons, it is highly recommended change the admin user default password of the equipment.
To change the admin user default password, follow the steps below:
configure
set system login user admin authentication plaintext-password new-password
commit
6.2 Local Users Configuration
The next steps will indicate how to configure a new user called “joao” with “joao1234” password and “admin” adminis-
trator privileges.
configure
set system login user joao authentication plaintext-password joao1234
set system login user joao level ’admin’
commit
It is also possible to create local users using upper letters.
configure
set system login user Joao authentication plaintext-password 1234joao
set system login user Joao level ’admin’
set system login user JOAO authentication plaintext-password jo1234ao
set system login user JOAO level ’admin’
commit
The next steps will show how to delete the user “joao”.

configure
delete system login user joao
commit
Below are the main commands available to check the equipment users. If the user is at the config level, use the keyword
show system login user
6.3 TACACS+ Configuration
The TACACS+ (Terminal Access Controller Access-Control System) is a protocol based on the AAA (Authentication, Authoriza-
tion and Accounting) template that provides the authentication, authorization and accounting services in a safe manner
with encryption of the entire packet. This encryption depends on a secret key shared in each device. The authentication
methods supported are PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol)
and ASCII (American Standard Code for Information Interchange).
The scenario below will be used to demonstrate TACACS+ configuration.
TACACS+
To configure the TACACS+, the user should specify the address of the server and the secret key to be used to authenticate
the users. It is recommended to write the secret key between simple quotation marks to allow usage of special characters.
Suppose the user wants to set up ascii authentication, authorization, and accounting with two TACACS+ servers, one IPv4
and one IPv6. The IPv4 server has the address 10.1.100.7 and the IPv6 server has the address 2019:1234::1, both with the
secret key pass1234.
The TACACS+ IPv4 server will have authentication priority over the TACACS+ IPv6 server if both are
configured.
The procedure below shows how to execute this configuration:

configure
set system login tacplus-server host 10.1.100.7 secret ’pass1234’
set system login tacplus-server host 2019:1234::1 secret ’pass1234’
set system login tacplus-server authentication-type ’ascii’
set system login tacplus-server authorization
set system login tacplus-server accounting
commit
After performing this configuration, authentication will take place on the basis of TACACS+. If authentication on the
TACACS+ server fails, authentication will occur on the local base.
The default TACACS+ timeout is 2 seconds to change to next authentication mode or next TACACS+ server configured. The
User can change this value using the following commands:
configure
set system login tacplus-server timeout 1
commit
It is not allowed to configure RADIUS and TACACS+ servers simultaneously.
The available commands for troubleshooting can be found in the topic Verifying TACACS+.
6.3.1 Verifying TACACS+
show tacacs
show log tacacs
show vrf <vrf-name> tacacs
6.4 RADIUS Configuration
The RADIUS (Remote Authentication Dial In User Service) is a protocol that protects the networks against unauthorized
access and is based on the AAA template that provides the authentication, authorization and accounting services. The
RADIUS client, in this case the DM2500, sends authentication requests to a central RADIUS server that contains all the
authentication information of the user and of access to the network service.
The scenario below will be used to demonstrate RADIUS configuration.

RADIUS
It is not possible to configure the RADIUS with IPv6 addressing.
To configure the RADIUS, the user should specify the address of the server and the secret key to be used to authenticate
the users. It is recommended to write the secret key between simple quotation marks to allow usage of special characters.
Let’s suppose that the user would like to configure the authentication, authorization and accounting of two RADIUS servers
that have 192.168.1.1 and 172.22.107.4 IPv4 addresses, both with the secret key pass1234. The procedure below shows how
to execute this configuration:
configure
set system login radius-server host 192.168.1.1 port ’1812’
set system login radius-server host 192.168.1.1 secret ’pass1234’
set system login radius-server host 192.168.1.1 timeout ’2’
set system login radius-server host 172.22.107.4 port ’1812’
set system login radius-server host 172.22.107.4 secret ’pass1234’
set system login radius-server host 172.22.107.4 timeout ’2’
commit
It is not allowed to configure RADIUS and TACACS+ servers simultaneously.
The available commands for troubleshooting can be found in the topic Verifying RADIUS.
6.4.1 Verifying RADIUS

show radius
show log radius
show vrf <vrf-name> radius

DM2500 - Quick Configuration Guide 7 Interfaces
7 Interfaces
This chapter shall indicate how to configure the interfaces available in the equipment.
When defining more than one IPv4/IPv6 address in the interface, it is recommended to use the address-
secondary parameter. Otherwise, the primary address (address that was defined with the address parameter)
will be overwritten.
• Ethernet Interface Configuration
• Loopback Interface Configuration
• Bridge Interface Configuration
• Bonding Interface (Aggregation) Configuration
7.1 Ethernet Interfaces Configuration
By default, all the Ethernet interfaces are deactivated, except the eth1 interface, that has the management
IP in the standard configuration.
To activate administratively an Ethernet interface, the user should use the procedure below.
configure
delete interfaces ethernet eth2 disable
commit
To deactivate administratively an Ethernet interface, the user should use the procedure below.
configure
set interfaces ethernet eth2 disable
commit
Interfaces that are not configured remain deactivated and do not appear in the show configuration. It is possible to remove
the entire configuration of an Ethernet interface through the following procedure:
configure
delete interfaces ethernet eth2
commit
The available commands for troubleshooting can be found in the topic Verifying Ethernet Interfaces.

7.1.1 Setting speed and duplex
In DM2500 all ethernet interfaces have auto-negotiation mode enabled by default. In this mode, the interface speed and
duplex negotiation occurs automatically, taking into account the remote link.
It is possible to change the configuration of the interface to work in forced mode. The procedure below shows how to
configure an interface to work in forced mode at a speed of 100 Mbps full-duplex.
Both sides of the link (local and remote) must be configured in the same way.
configure
set interfaces ethernet eth7 speed 100
set interfaces ethernet eth7 duplex full
commit
Following the example above, if the interface uses an optical link, the parameter 100fx.
configure
set interfaces ethernet eth7 speed 100fx
set interfaces ethernet eth7 duplex full
commit
The available commands for troubleshooting can be found in the topic Verifying Ethernet Interfaces.
7.1.2 Verifying Ethernet Interfaces
show interfaces ethernet

show interfaces ethernet detail
show interfaces counters
show vrf <vrf-name> interfaces ethernet
show vrf <vrf-name> interfaces ethernet detail
show vrf <vrf-name> interfaces counters
show interfaces utilization bandwidth
show interfaces utilization packets
7.2 Loopback Interface Configuration
A loopback interface is a virtual interface only for software that emulates a physical interface and allows the router to
“connect” to itself. The routed packets for the loopback interface are routed again to the router and processed locally. The
packets routed by the loopback interface, but not assigned to the loopback interface, are discarded.

It is possible to configure up to four loopback interfaces (lo1 to lo4)
Let’s suppose that the user would like to create two loopback interfaces, the lo1 and the lo2 with IPv4 and IPv6 addresses.
The procedure below indicates how to execute this configuration.
configure
set interfaces loopback lo1 address 192.168.255.105/32
set interfaces loopback lo1 address-secondary 192.168.254.105/32
set interfaces loopback lo2 address 2400:c0ca:beef::1/64
commit
To continue a configuration after an eventual reboot, the user should use the save command after the commit command.
The available commands for troubleshooting can be found in the topic Verifying Loopback Interfaces.
7.2.1 Verifying Loopback Interfaces
show interfaces
show interfaces loopback
show vrf <vrf-name> interfaces loopback
show vrf <vrf-name> interfaces loopback detail
7.3 Bridge Interface Configuration
Bridge configuration allows connection of several network segments (in general LAN segments) at level of layer 2 (switching).
As the Bridge occurs in layer 2 and the IP addresses are relevant only in layer 3 (routing, the network layer),
the IP addresses are not allowed in the interfaces that are being connected.
The Ethernet interface and the VLANs interfaces can be added directly to a Bridge

Let’s suppose that the user would like to create a bridge br1 with IPv4 and IPv6 addresses to connect the Ethernet eth2,
eth3 and eth4 interfaces. The procedure below shows how to execute this configuration.
configure
set interfaces bridge br1 address 192.168.10.2/24
set interfaces bridge br1 address 2018:c0ca:cafe::2/64
set interfaces ethernet eth2 bridge-group bridge br1
commit
The available commands for troubleshooting can be found in the topic Verifying Bridge Interfaces.
7.3.1 Verifying Bridge Interfaces
show bridge
show interfaces
show interfaces bridge
show vrf <vrf-name> interfaces bridge
show vrf <vrf-name> interfaces bridge detail
7.4 Bonding Interfaces (Aggregation) Configuration
IEEE 802.3ad Link Aggregation allows to create a logical interface containing one or more physical interfaces. Aggregating
multiple links or physical interfaces creates a single point-to-point logical link (LAG). LAG makes it possible to split flows
between physical interfaces, effectively increasing bandwidth. Another advantage of link aggregation is the increased
availability of the communication link between the two devices, if one of the physical interfaces fails, the LAG will continue
to carry traffic through the remaining interfaces.
Example of scenário with ling aggregation

As interfaces Bonding do DM2500 suportam três modos de balanceamento do tráfego de saída, chamados de Hash Policy:
The DM2500 Bonding interfaces support three outgoing traffic balancing modes, called Hash Policy:
• layer2: Use MAC addresses to generate the hash (802.3ad).
• layer2+3: Combine MAC address and IP address to make hash.
• layer3+4: Combine IP address and port to make hash.
7.4.1 Bonding Interface Static Mode
The next steps will demonstrate how to configure bonding interface in static mode using two (2) Ethernet interfaces,
totaling a possible bandwidth of 2Gbps.
configure
set interfaces bonding bond8 address ’192.168.53.1/24’
set interfaces bonding bond8 description ’INTF-BONDING’
set interfaces bonding bond8 hash-policy ’layer2’
! Setting static mode
set interfaces bonding bond8 mode ’xor-hash’
set interfaces ethernet eth7 bond-group ’bond8’
commit
The available commands for troubleshooting can be found in the topic Verifying Bonding Interfaces.
7.4.2 Bonding Interface Dynamic Mode (LACP)
Link Aggregation Control Protocol (LACP) is a protocol used to ensure end-to-end aggregate interface (LAG) connectivity. It
detects and protects the network against a variety of misconfigurations, ensuring that links are only aggregated into one
bundle if they are configured and wired consistently. LACP can be configured in two ways:
• Active Mode Ativo (Active): The device immediately sends LACP messages (LACP PDUs) when the interface is
activated.
• Passive Mode (Passive): Puts an interface into a passive negotiation state, where the interface waits for remote
PDUs to send to initiate Link Aggregation negotiation and establishment.
If at least one endpoint is set to active, the LAG can be formed assuming a successful negotiation of the other parameters.
The next steps will demonstrate how configure bonding interface in dynamic mode using two (2) Ethernet interfaces,
totaling a possible bandwidth of 2Gbps.
configure
set interfaces bonding bond8 address ’192.168.53.1/24’
set interfaces bonding bond8 description ’INTF-BONDING’
set interfaces bonding bond8 hash-policy ’layer2’
set interfaces bonding bond8 lacp-rate ’slow’
! Setting dinamic mode
set interfaces bonding bond8 mode ’802.3ad’


commit
The available commands for troubleshooting can be found in the topic Verifying Bonding Interfaces.
7.4.3 Verifying Bonding Interfaces
show interfaces bonding

show interfaces bonding <bondX>
show interfaces bonding <bondX> brief
show interfaces bonding <bondX> slaves
show interfaces bonding <bondX> status
show vrf <vrf-name> interfaces bonding
show vrf <vrf-name> interfaces bonding <bondX>
show vrf <vrf-name> interfaces bonding <bondX> brief
show vrf <vrf-name> interfaces bonding <bondX> slaves
show vrf <vrf-name> interfaces bonding <bondX> status

DM2500 - Quick Configuration Guide 8 LTE Connection
8 LTE Connection
This chapter shall indicate how to configure the LTE connection available in the equipment.
• LTE Connection
• LTE configuration using template
• Manual LTE Configuration
8.1 LTE Connection
Long-Term Evolution (LTE) is a standard for wireless broadband communication for mobile devices and data terminals,
based on the GSM/UMTS technologies. By using a wireless connection, companies can use LTE connection to replace or
back up wired WAN links.
The figure below shows a basic application, where, to configure an LTE connection on the DM2500, the following
requirements must be met:
• 4G LTE network coverage where the router is physically placed.
• A SIM CARD available for 4G LTE network with a service plan.
• Firmware version equal to or greater than 1.16.4 version installed in DM2500 4GT+LTE.
Scenario for LTE connect
8.2 LTE configuration using template
There are some templates already saved to configure default parameters of service providers. If your service provider is not
listed in the network command it will be necessary to configure the parameters user, password and apn, according to
example from the session Manual LTE Configuration. The network carrier command defines the dial strings of the service
provider.
Templates Network Carrier: ATT, CLARO, OI, SC1, TIM, VERIZON, VIVO.
You need to set the mode of authentication and protocol used by the service provider.

• Authentication mode: Connection mode used by the service provider. Acceptable parameters are:QMI or PPP.
• Protocol type: Specifies the IP version that will be configured: Acceptable parameters are: IPv4, IPv6 or BOTH.
configure
set interfaces wirelessmodem wlm0 network ’claro’
set interfaces wirelessmodem wlm0 mode ’ppp’
set interfaces wirelessmodem wlm0 protocol ’IPv4’
commit
The available commands for troubleshooting can be found in the topic Verifying LTE Connection.
8.3 Manual LTE Configuration
The configuration below will configure an LTE connection carrier. In this example, DATACOM4G carrier was used. If your
service provider is not listed on the templates or if you want to set another APN for test, you need to set APN, user and
password manually:
configure
set interfaces wirelessmodem wlm0 apn ’datacom4g.com.br’
set interfaces wirelessmodem wlm0 password ’user_pass’
set interfaces wirelessmodem wlm0 user ’user@datacom4g.lte.com.br’
commit
You need to set the type, mode of authentication and protocol used by the service provider.
• Authentication type: Specifies the authentication type. Acceptable parameters are: PAP, CHAP or BOTH.
• Authentication mode: Connection mode used by the service provider. Acceptable parameters are: QMI or PPP.
• Protocol type: Specifies the IP version that will be configured: Acceptable parameters are: IPv4, IPv6 or BOTH.
configure
set interfaces wirelessmodem wlm0 auth ’chap’
set interfaces wirelessmodem wlm0 mode ’ppp’
set interfaces wirelessmodem wlm0 ppp-options idle-disconnect ’60’
set interfaces wirelessmodem wlm0 ppp-options ’ondemand’
set interfaces wirelessmodem wlm0 protocol ’both’
commit
Both protocol is only supported for ppp mode.
IPv4 protocol is the default value and will be adopted if no value is configured.

When no dynamic routing protocol is associated with the wlm0 interface, a default route will be configured to forward all
traffic through the LTE interface wlm0.
configure
set protocols static interface-route 0.0.0.0/0 next-hop-interface ’wlm0’
commit
In the case of the configuration example below, the user can connect some equipment like a PC to eth1 of DM2500 to
test speed, status, signal strength, connection with the LTE network. In this example, a PC was connected to ETH1 in
192.168.0.0/24 network and performed NAT with the wlm0 interface to be able to forward LAN traffic to internet.
• PC: 192.168.0.100/24
• DM2500 ETH1: 192.168.0.25/24
configure
set interfaces ethernet eth1 address ’192.168.0.25/24’
set interfaces ethernet eth1 duplex ’auto’
set interfaces ethernet eth1 speed ’auto’
set interfaces ethernet eth1 description ’LAN’
set nat source rule 1 outbound-interface ’wlm0’
set nat source rule 1 source address ’192.168.0.0/24’
set nat source rule 1 translation address ’masquerade’
commit
The available commands for troubleshooting can be found in the topic Verifying LTE Connection.
8.4 Verifying LTE Connection
show interfaces wirelessmodem wlm0 card-status

show interfaces wirelessmodem wlm0 cell-location
show interfaces wirelessmodem wlm0 current-profile
show interfaces wirelessmodem wlm0 current-profile
show interfaces wirelessmodem wlm0 current-settings
show interfaces wirelessmodem wlm0 hardware
show interfaces wirelessmodem wlm0 home-network
show interfaces wirelessmodem wlm0 queue
show interfaces wirelessmodem wlm0 serving-system
show interfaces wirelessmodem wlm0 status
show log wirelessmodem
show log ppp
show log ppp wlm0

DM2500 - Quick Configuration Guide 9 IP Services
9 IP Services
Some internet access providers require the use of PPPoE (Point-to-Point Protocol over Ethernet) for connection to Internet.
They can also use the DHCP (Dynamic Host Configuration Protocol) protocol to execute the dynamic assignment of IP
addresses, DNS, gateway, among others. This chapter shall indicate how to configure these services in the DM2500.
This chapter contais this follow sections:
• DHCPv4 Server Configuration
• DHCPv6 Server Configuration
• DHCPv4 Relay Configuration
• DHCPv6 Relay Configuration
• DHCPv4 Client Configuration
• DHCPv6 Client Configuration
• PPPoE Client Configuration
9.1 DHCPv4 Server Configuration
The DM2500 offers the DHCPv4 server functionality. Through this resource the equipment can distribute in a dynamic
manner IPv4 addresses to other elements connected in the same sub-network.
Considering that the user would like to configure a DHCPv4 server in the 10.10.10.0/24 using the address range 10.10.10.5
through 10.10.20. Also it would like that a server identified by a specific MAC receives the 10.10.10.2 address and that the
validity of the IPs granted through the renewal process has a duration of 24 hours.
The next steps will indicate how to execute these configurations.
DNS server sent by DHCP server should be the same as you have in your network, in example below is used
the Google public DNS.
configure
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 lease 86400
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 dns-server
8.8.8.8
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 default-router
10.10.10.1
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 start 10.10.10.5
stop 10.10.10.20
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 domain-name
dhcp-internal
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 static-mapping
SERVER-10-2 ip-address 10.10.10.2
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 static-mapping
SERVER-10-2 mac-address 00:04:df:cc:3a:04
commit
To continue a configuration after an eventual reboot, the user must use the save command after the commit command.

The available commands for troubleshooting can be found in the topic Verifying DHCP Server.
9.1.1 Configuring DHCPv4 Server Options
The DM2500 support some DHCPv4 options predefined and configuration by code, allowing any DHCPv4 options to be
configured. For more information about codes and format accepted for each code, please see the RFC 2132. The next steps
will show some examples of how to execute these configurations:
SMTP server predefined option configuration:
configure
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 smtp-server
172.22.103.32
commit
LPR Server (code 9) configuration with a IPv4 address:
configure
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 option 9 ipv4
172.22.103.32
commit
LPR Server (code 9) configuration with two IPv4 addresses (172.22.103.32 and 172.22.103.40):
configure
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 option 9
hex ac:16:67:20:ac:16:67:28
commit
Hostname (code 12) configuration:
configure
set service dhcp-server shared-network-name DM2500-NETWORK subnet 10.10.10.0/24 option 12
ascii DM2500-6GT
commit
9.1.2 Verifying DHCP Server

show dhcp server leases

show dhcp server statistics
show vrf <vrf-name> dhcp server leases
show vrf <vrf-name> dhcp server statistics
show log dhcp
9.2 DHCPv6 Server Configuration
The DM2500 offers the DHCPv6 server functionality. Through this resource the equipment can distribute in a dynamic
manner IPv6 addresses to other elements connected in the same sub-network.
The next steps will show how to configure the service to provide IPv6 addresses in the 2001:C0A8:5600::/64 network with
validity of the addresses for renewal of 24 hours and a host identified by the UID receiving de 2001:c0a8:5600::10 address.
configure
set interfaces ethernet eth3 address ’2001:C0A8:5600::1/64’
set service dhcpv6-server shared-network-name systemTest subnet 2001:C0A8:5600::/64 address-range
prefix ’2001:C0A8:5600::/64’
set service dhcpv6-server shared-network-name systemTest subnet 2001:C0A8:5600::/64 domain-search
’dhcp-internal’
set service dhcpv6-server shared-network-name systemTest subnet 2001:C0A8:5600::/64 lease-time
default ’86400’
set service dhcpv6-server shared-network-name systemTest subnet 2001:C0A8:5600::/64 name-server
’2001::2’
set service dhcpv6-server shared-network-name systemTest subnet 2001:C0A8:5600::/64 static-mapping
teste identifier ’00:01:00:01:5b:cd:f6:b7:00:aa:00:00:00:0a’
set service dhcpv6-server shared-network-name systemTest subnet 2001:C0A8:5600::/64 static-mapping
teste ipv6-address ’2001:c0a8:5600::10’
commit
To continue a configuration after an eventual reboot, the user must use the save command after the commit command.
9.2.1 Verifying DHCP Server
show dhcpv6 server leases

show dhcpv6 server statistics
show vrf <vrf-name> dhcpv6 server leases
show vrf <vrf-name> dhcpv6 server statistics
show log dhcp
9.3 DHCPv4 Relay Configuration
The DM2500 offers the DHCPv4 Relay functionality to forward DHCP requests from a given network to a DHCP server
present in another network. Each interface involved in the DHCPv4 Relay should be configured. Thus, for example, if the
requests are incoming in the eth0 interface and the DHCPv4 server specified in the configuration is accessed through the

eth1 interface, the eth0 as well as the eth1 should be configured for the DHCP Relay.
Considering that the user would like to configure a DHCPv4 Relay to forward the DHCP requests from clients that are in the
10.10.10.0/24 network to the DHCPv4 server that is in another network with the 10.20.30.1/24 address. The next steps will
show how to execute these configurations.
configure
set service dhcp-relay interface ’eth1’
set service dhcp-relay interface ’eth0’
set service dhcp-relay server ’10.20.30.1’
set service dhcp-relay relay-options relay-agents-packets ’discard’
commit
Through the configuration below it is possible to specify a source address for the DHCP packet sent to the DHCP server. In
this case, the LAN IP will be used.
configure
set service dhcp-relay server ’10.20.30.1’ source-address ’10.10.10.1’
commit
The available commands for troubleshooting can be found in the topic Verifying DHCPv4 Relay.
9.3.1 Verifying DHCPv4 Relay
show configuration | match dhcp-relay

show log dhcp
9.4 DHCPv6 Relay Configuration
The DHCPv6 Relay receives the requests sent by DHCPv6 clients and forwards them to DHCPv6 servers. As the client
request packets and the retransmitted requests are transported in IPv6 multicast packets, the user must specify the
interfaces where the relay will receive the request and the interfaces in which it should retransmit these requests.
Considering that the user would like to configure a DHCPv6 Relay to forward the DHCP requests from clients that are in the
2605:ef80:240::1/64 network to a DHCPv6 server that is in another network with the 2600::c0a8:2d01 address. The next
steps will indicate how to execute these configurations.
configure
set interfaces ethernet eth0 address ’2605:ef80:240::1/64’
set interfaces ethernet eth1 ipv6 address eui64 ’2404:6800:4001::/64’
set service dhcpv6-relay listen-interface ’eth0’

set service dhcpv6-relay upstream-interface eth1 address ’2600::c0a8:2d01’

commit
As operation of DHCPv6 Relay is different from the DHCPv4 Relay, it is necessary configure the Router Advertisement in the
interface that is receiving the requests.
configure
set interfaces ethernet eth0 ipv6 router-advert managed-flag ’true’
set interfaces ethernet eth0 ipv6 router-advert other-config-flag ’true’
set interfaces ethernet eth0 ipv6 router-advert prefix 2605:ef80:240::/64 autonomous-flag ’true’
set interfaces ethernet eth0 ipv6 router-advert prefix 2605:ef80:240::/64 on-link-flag ’true’
set interfaces ethernet eth0 ipv6 router-advert send-advert ’true’
commit
The available commands for troubleshooting can be found in the topic Verifying DHCPv6 Relay.
9.4.1 Verifying DHCPv6 Relay
show configuration | match dhcpv6-relay

show log dhcp
9.5 DHCPv4 Client Configuration
It is possible to configure a DHCPv4 client linked to an Ethernet interface for the dynamic assignment of IPv4 address
according to determination of a DHCPv4 server.
Considering that the user would like to obtain the IPv4 address through the eth4 interface. The next steps will indicate how
to execute these configurations.
configure
set interfaces ethernet eth4 address dhcp
commit
To persist the configuration after an eventual reboot, the user must use the save command after the commit command.
The available commands for troubleshooting can be found in the topic Verifying DHCPv4 Client.

9.5.1 Verifying DHCPv4 Client
show dhcp client leases

show interfaces
show vrf <vrf-name> dhcp client leases
show vrf <vrf-name> interfaces
show log dhcp
9.6 DHCPv6 Client Configuration
It is possible to configure a DHCPv6 client in an Ethernet interface for dynamic assignment of IPv6 according to determination
of a DHCPv6 server.
Considering that the user would like that the IPv6 address of the eth4 Ethernet interface be assigned in a dynamic manner
as from a DHCPv6 server connected to it. The next steps will indicate how to execute these configurations.
configure
set interfaces ethernet eth4 address dhcpv6
commit
9.6.1 Verifying DHCPv6 Client
show dhcpv6 client leases

show dhcpv6 client identifiers
show interfaces
show vrf <vrf-name> dhcpv6 client leases
show vrf <vrf-name> dhcpv6 client identifiers
show vrf <vrf-name> interfaces
show log dhcp
9.7 PPPoE Client Configuration
The PPPoE (Point-to-Point Protocol over Ethernet) encapsulation for an Ethernet interface is defined in RFC2516. This type
of interface is used to connect itself to a point of the network with support to PPPoE. With the PPPoE encapsulation, the
local and remote IP addresses can be negotiated automatically instead of explicitly specified by the user. Per default, the
negotiation is carried out automatically if the addresses are not specified.

The PPPoE session can only be configured to operate with IPv4 addresses, and it is possible to configure up
to 15 PPPoE interfaces.
Considering that the user would like to establish a PPPoE session using the pppoe 15 interface which is associated with the
eth1 Ethernet interface. The next steps will indicate how to execute these configurations.
configure
set interfaces pppoe 15 user-id user1@datacom.com.br
set interfaces pppoe 15 password d4t4c0m
set interface ethernet eth1 pppoe 15
commit
The TCP MSS (Maximum Segment Size) is 1460 bytes on interfaces with 1500 bytes MTU (Maximum Transmission Unit).
The PPPoE needs 8 of 1460 bytes to encapsulate the data, due this the TCP packets with 1460 bytes are fragmented or
discarded in router. One way to fix this issue is to adjust the MSS using the commands below:
configure
set interfaces ethernet eth1 policy route ’MSS’
set policy route MSS description ’TCP_MSS’
set policy route MSS rule 1 protocol ’tcp’
set policy route MSS rule 1 set tcp-mss ’1452’
set policy route MSS rule 1 tcp flags ’SYN’
commit
The available commands for troubleshooting can be found in the topic Verifying PPPoE Client.
9.7.1 Verifying PPPoE Client
show interfaces pppoe

show interfaces pppoe <interface pppoe> log

DM2500 - Quick Configuration Guide 10 Routing
10 Routing
Routing is the process of forwarding packets to their destination using network address. Routing is executed by devices
capable of exchanging the required information in order to create tables containing path information to reach the
destination, using dynamic routing protocols or inputs assigned manually. The dynamic routing protocols, such as the
OSPF, have the required information from the neighboring devices in order to create their routing table, used to define the
location where the traffic will be sent. As alternatives to the dynamic methods, there are static routes. The static routes are
viable in routers that have few networks and fewer paths to destination. The information received through the routing
protocols are added in a table called RIB (Routing Information Base) which is the base for calculation of the best path. The
calculation of the route is the FIB (Forwarding Information Base) that contains the information that the devices use to
route the traffic.
• Routing Configuration
• PBR Configuration
• RIP Configuration
• RIPng Configuration
• OSPFv2 Configuration
• OSPFv3 Configuration
• BGP Configuration
• BFD Configuration
• VRRP Configuration
• PIM Configuration
• VRF Configuration
• ECMP Configuration
10.1 Routing Configuration
10.1.1 Static Routing
The static routing has as objective to forward packets between different networks with manual configuration of routes by
the network administrators. By default, different VLANs do not communicate between themselves, as they are in exclusive
broadcast domains. In order to execute communication between two VLANs, it is necessary to use a router.

10.1.2 Routing between VLANs
In order to communicate between two VLANs, a router or a form of routing must be used on the device itself. Routing
between VLANs enables this communication. The network associated with the interface is inserted into the routing table
and can be accessed by other networks.
The scenario below will be used to show configuration of static routing between VLANs.
Setting Static Routing and Routing Between VLANs
Considering that the user would like to allow routing between VLAN 100 and VLAN 200 in the eth1 Ethernet interface and
VLAN 2 in the eth2 interface to be used as default static route where the gateway has the IPv4 10.10.0.1/30 address. The next
steps will show how to execute these configurations.
configure
commit
The available commands for troubleshooting can be found in the topic Verifying Static Routing.
10.1.3 Enabling ECMP in static routes
ECMP is automatically enabled for static routes if it is enabled globally. There is no specific ECMP configuration for static
routes.
For more details on the ECMP load balancing modes, consult session Setting the ECMP.

The available commands for troubleshooting can be found in the topic Verifying Static Routing.
10.1.4 Verifying Static Routing
show ip route
show ip route static
show vrf <vrf-name> ip route
show vrf <vrf-name> ip route static
10.2 PBR Configuration
Policy-based routing PBR allows the user to use rules to classify the traffic based on its attributes and apply a processing
according to its classification and to route selectively the IP packets, for example for an alternative hop. All the packets
received in an interface are considered for policy based routing, as long as the interface is assigned to a routing policy.
When no routing policy is applied, the routing decisions are taken using the main routing table of the system. The PBR
policies can be applied to interfaces of the data plane for incoming traffic, but not to loopback, tunnel or bridge interfaces.
In the DM2500 the user cannot apply the PBR policies to packets locally generated. The scenario below will be used to
show configuration of the PBR.
Setting the PBR
Considering that the user would like to configure a PBR policy in VLANs 10 and 20 that are configured in the eth1 interface,
so that the traffic originated in 192.168.10.0/24 network can be forwarded by the next 192.168.100.1 hop which is reachable
through the eth2 interface, and also so that the traffic originated in the 192.168.20.0/24 network can be forwarded by the
next 192.168.200.1 hop which is reachable through the eth3 interface.

configure
set interface ethernet eth1 vif 10 address 192.168.10.1/24
set interface ethernet eth1 vif 20 address 192.168.20.1/24
set interface ethernet eth2 address 192.168.100.2/30
set interface ethernet eth3 address 192.168.200.2/30
set policy route PBR-LAN rule 10 destination address 0.0.0.0/0
set policy route PBR-LAN rule 10 source address 192.168.10.0/24
set policy route PBR-LAN rule 10 set table 10
set policy route PBR-LAN rule 20 destination address 0.0.0.0/0
set policy route PBR-LAN rule 20 source address 192.168.20.0/24
set policy route PBR-LAN rule 20 set table 20
set interfaces ethernet eth1 policy route PBR-LAN
set protocols static table 10 route 0.0.0.0/0 next-hop 192.168.100.1
set protocols static table 20 route 0.0.0.0/0 next-hop 192.168.200.1
commit
The available commands for troubleshooting can be found in the topic Verifying PBR Configuration.
10.2.1 Verifying PBR Configuration
show policy route

show ip route
show vrf <vrf-name> policy route
10.3 RIP Configuration
The RIP (Routing Information Protocol) is a dynamic routing protocol adequate for small size and homogeneous networks.
It is classified as an interior gateway protocol (IGP) and uses a distance vector algorithm. RIP defines the best path,
counting the hops until destination. The maximum number of hops is 15 (16 is considered an infinite distance), resulting in
RIP being not adequate for large size networks. The scenario below will be used to show configuration of the RIP.
Setting the RIP
Considering that the user would like to configure a RIP session through the eth2 interface and through the IPv4 10.0.40.1/30
address and also wishes to advertise the 10.0.30.0/24 network which is connected by eth4. The next steps will indicate how

to execute these configurations.
configure
set protocols rip network 10.0.30.0/24
set protocols rip interface eth2
commit
The available commands for troubleshooting can be found in the topic Verifying RIP Routing.
10.3.1 Verifying RIP Routing
show ip route
show ip route rip
show ip rip status
show ip rip
show log rip
debug rip
show vrf <vrf-name> ip route rip
show vrf <vrf-name> ip rip status
show vrf <vrf-name> ip rip
debug vrf <vrf-name> rip
10.4 RIPng Configuration
The RIPng (Routing Information Protocol next generation) is a dynamic routing protocol adequate for small size and
homogeneous IPV6 networks. It is classified as an interior gateway protocol (IGP) and uses a distance vector routing
algorithm. The RIPng defines the best path, counting hops until destination. The maximum number of hops is 15 (16 is
considered an infinite distance), resulting in RIPng not being adequate for large size networks. RIPng is an extension of the
RIP version 2 for IPv6. The scenario below will be used to show configuration of the RIPng.
Setting the RIPng
Considering that the user would like to configure a RIPng session through the eth2 interface and through the IPv6
2001:cafe:1::1/64 address and also wishes to advertise the 2001:cafe:4::/64 network which is connected by eth4. The next

steps will indicate how to execute these configurations.
configure
set interfaces ethernet eth2 address 2001:cafe:1::1/64
set interfaces ethernet eth4 address 2001:cafe:4::1/64
set protocols ripng network 2001:cafe:4::/64
set protocols ripng interface eth2
commit
The available commands for troubleshooting can be found in the topic Verifying RIPng Routing.
10.4.1 Verifying RIPng Routing
show ipv6 route

show ipv6 route ripng
show ipv6 ripng
show ipv6 ripng status
show log rip
debug ripng
show vrf <vrf-name> ipv6 route
show vrf <vrf-name> ipv6 route ripng
show vrf <vrf-name> ipv6 ripng
show vrf <vrf-name> ipv6 ripng status
debug vrf <vrf-name> ripng
10.5 OSPFv2 Configuration
The OSPFv2 (Open Shortest Path First version 2) is the IGP (Internal Gateway Protocol) described by RFC 2328 (version 2)
for routing of IPv4 addresses. This protocol is used within a same AS (Autonomous System), justifying its denomination as
Internal. It is based on the Dijkstra algorithm that calculates the shortest path to each destination based on the costs of
each link. The scenario below will be used to show configuration of the OSPFv2.
Setting the OSPFv2

It is recommended to use the loopback interface instead of physical interfaces due to the stability, as these
are always actives.
Considering that the user would like to execute an OSPF session in the 8048 area with network-type of the point-topoint
type through the following configurations: - DM2500: Interface eth1 in VLAN 503 with IPv4 192.168.72.5/30 address and
loopback interface with IPv4 192.168.255.41/32 being used as router-id in the OSPFv2 in the 0 area. The DM2500 shall also
advertise the 192.168.64.0/22 network in which it is connected by the eth3 interface:
configure
set interfaces loopback lo address 192.168.255.41/32
set interfaces ethernet eth1 vif 503 ip ospf network point-to-point
set protocols ospf area 8048 network 192.168.255.41/32
set protocols ospf log-adjacency-changes detail
set protocols ospf parameters abr-type standard
set protocols ospf parameters router-id 192.168.255.41
commit
The available commands for troubleshooting can be found in the topic Verifying OSPFv2 Routing.
10.5.1 Configuring a Virtual Link in OSPFv2
For an OSPF scenario to work correctly, all areas of protocol must be connected directly to Area 0 (backbone) of OSPF.
However, there are situations where the router of other OSPF areas can not connect physically to some Area Border
Router (ABR) of Area 0. To solve this problem, a virtual link can be configured between these routers simulating a direct
connection.
The scenario below will be used to show Virtual Link configuration in OSPFv2.
Configuring a Virtual Link in OSPFv2

Considering that the user would like to connect Area 20 to Area 0 through of Area 10. A Virtual Link will be configured
between the ABRs of Area 0 (DM25-1) and Area 20 (DM25-2).
DM25-1
configure
set interfaces loopback lo1 address ’1.1.1.1/32’
set protocols ospf area 0 network ’192.168.0.0/28’
set protocols ospf area 0 area-type ’normal’
set protocols ospf area 10 virtual-link ’2.2.2.2’
set protocols ospf log-adjacency-changes ’detail’
set protocols ospf parameters abr-type ’standard’
set protocols ospf parameters router-id ’1.1.1.1’
commit
DM25-2
configure
set interfaces loopback lo1 address ’2.2.2.2/32’
set protocols ospf area 10 virtual-link ’1.1.1.1’
set protocols ospf parameters abr-type ’standard’
commit
10.5.2 Enabling ECMP in OSPFv2
ECMP is automatically enabled in OSPFv2 if it is enabled globally. There is no specific ECMP configuration for OSPF.
10.5.3 Setting LSA filtering
The LSA filtering extends the capacity of an ABR that is executing the OSPFv2 protocol to filter LSAs of type 3 between
different OSPF areas. This resource allows that only specified prefixes are sent from an area to another area and restricts
all the other prefixes. This type of filtering per area can be applied out of a specific area, in a specific area, or within and out
of OSPF areas at the same time. The following cases show the user how to configure filtering of LSAs in different manners:

10.5.4 Filtering of LSAs announced for other areas
Considering that the user would like to filter LSAs of type 3 (Summary) which are advertised to other areas of intra-area
routes. The following configuration with a short explanation shows how this type of filtering can be executed.
configure
set policy access-list 5 rule 1 action ’permit’
set policy access-list 5 rule 1 source inverse-mask ’0.0.255.255’
set policy access-list 5 rule 1 source network ’10.10.0.0’
set protocols ospf area 5 export-list 5
commit
In the example above, any intra-area route of area 5 and of the 10.10.0.0/16 range (for example, 10.10.1.0/24 and
10.10.2.128/30) will be advertised for other areas as a LSA Summary, of Type 3 but any others (for example, 10.11.0.0/16 or
10.128.30.16/30) no. This configuration is relevant only if the router is an ABR for the specified area.
10.5.5 Filtering of LSAs announced for the specified area
Considering that the user would like to filter LSAs of type 3 (Summary) being advertised to within the specified area. The
following configuration with a short explanation shows how this type of filtering can be executed.
configure
set policy access-list 5 rule 1 action ’permit’
set policy access-list 5 rule 1 source inverse-mask ’0.0.255.255’
set policy access-list 5 rule 1 source network ’10.20.0.0’
set protocols ospf area 5 import-list 5
commit
In the example above, any route advertised within the area 5 and of the 10.20.0.0/16 range will be advertised in the area as
LSAs of type 3, but any other no. This configuration is relevant only if the router is an ABR for the specified area.
10.5.6 Filtering of LSAs using prefix-list
Filtering of LSAs of type 3 (Summary) can be also configured as in the previous examples, but using the prefix-lists and
specifying the direction of filtering (inbound or outbound). The following configuration shows how this type of filtering can
be executed.

configure
set policy prefix-list Deny-Route-192 rule 1 action ’deny’
set policy prefix-list Deny-Route-192 rule 1 le ’32’
set policy prefix-list Deny-Route-192 rule 1 prefix ’192.168.20.0/24’
set policy prefix-list Deny-Route-192 rule 2 action ’permit’
set policy prefix-list Deny-Route-192 rule 2 le ’32’
set policy prefix-list Deny-Route-192 rule 2 prefix ’0.0.0.0/0’
set protocols ospf area 5 filter-list out ’Deny-Route-192’
commit
The example above allows filtering of a route with prefix 192.168.20.0/24 which is being propagated in area 5, but which
currently is being passed over for all OSPF domains. For this reason, a filter-list is configured in the ABR with area 5 and
with the help of the prefix-list the user will be able to execute blocking of 192.168.20.0/24 prefix.
10.5.7 Verifying OSPFv2 Routing
show ip ospf
show ip ospf neighbors
show ip ospf database
show ip route
show ip route ospf
show log ospf
debug ospf
show vrf <vrf-name> ip ospf
show vrf <vrf-name> ip ospf neighbors
show vrf <vrf-name> ip ospf database
show vrf <vrf-name> ip route ospf
debug vrf <vrf-name> ospf
10.6 OSPFv3 Configuration
The OSPFv3 (Open Shortest Path First version 3) is the IGP (Internal Gateway Protocol) described by RFC 5340 for routing of
IPv6 addresses. As it is an IGP, it is a protocol used within a same AS (Autonomous System). It is based on the Dijkstra
algorithm, which calculates the shortest path to each destination based on the costs of each link. The scenario below will
be used to show configuration of the OSPFv3.

Setting the OSPFv3
In the example below, a neighbor IPv6 of the point-to-point type in eth1.150 interface will be configured. The loopback of
the DM2500 will have the IPv6 2001:db8:ffff::1/128 address and also the IPv4 177.66.5.1/32 address. The IPv4 address of
the loopback will be used as router-id of the OSPFv3. The loopback lo1 interface will be configured as passive, as the
adjacencies through it shall not be formed. The eth2 interface will have the IPv6 2001:db8:100::1/64 address and shall not
form any OSPFv3 adjacency. Its network will be redistributed to the OSPFv3 through the redistribute connected command.
configure
set interfaces loopback lo1 address 2001:db8:ffff::1/128
set interfaces loopback lo1 ipv6 ospfv3 passive
set interfaces ethernet eth1 vif 150 address 2001:db8::1/64
set interfaces ethernet eth1 vif 150 ipv6 ospfv3 network point-to-point
set interfaces ethernet eth2 address 2001:db8:100::1/64
set protocols ospfv3 parameters router-id 177.66.5.1
set protocols ospfv3 area 0 interface lo1
set protocols ospfv3 area 0 interface eth1.150
set protocols ospfv3 redistribute connected
commit
10.6.1 Enabling ECMP in OSPFv3
ECMP is automatically enabled in OSPFv3 if it is enabled globally. There is no specific ECMP configuration for OSPF.
10.6.2 LSA filtering
In the scenario below, the DM2500 has interfaces in two different OSPFv3 areas. Interface eth1 is in area 0 and interface
eth2 is in area 1. Considering both areas are normal areas, LSAs received in area 0 are advertised to area 1. In this scenario,
there is no LSA filtering. LSAs are advertised from one area to another area.

OSPFv3 scenario without LSA filtering
configure
set interfaces loopback lo1 address 2001:db8::1/128
set interfaces loopback lo1 ipv6 ospfv3 passive
set interfaces ethernet eth1 2001:db8:100::1/64
set interfaces ethernet eth1 ipv6 ospfv3 network point-to-point
set interfaces ethernet eth2 address 2001:db8:200::1/64
set protocols ospfv3 area 0 interface eth1
commit
In case it is no desired that all LSAs in area 0 are advertised to area 1, it is possible to configure import or export lists in the
areas.
The equipment must be a ABR (area border router) to be able to filter LSAs.
One way to filter LSAs is to configure an import-list in area 1. In the example below, an IPv6 access-list is configured
rejecting any networks within the prefix 2001:db8:ffff::/48. That ACL is applied as import-list in area 1, making that LSAs
containing those networks are not imported to the area.
LSA filtering
configure
set policy access-list6 reject-lsas rule 10 action ’deny’
set policy access-list6 reject-lsas rule 10 source network ’2001:db8:ffff::/48’
set policy access-list6 reject-lsas rule 100 action ’permit’

set policy access-list6 reject-lsas rule 100 source ’any’

set protocols ospfv3 area 1 import-list reject-lsas
commit
Another way to filter LSAs is to configure a export-list in area 0. LSAs received in area 0 will not be advertised to any other
areas.
configure
set protocols ospfv3 area 0 export-list reject-lsas
commit
To persist the configuration after a reboot, the user should use the save command in the configuration mode.
10.6.3 Verifying OSPFv3 Routing
show ipv6 ospf

show ipv6 ospf neighbors
show ipv6 ospf database
show ipv6 route
show ipv6 route ospf
show log ospfv3
debug ospfv3
show vrf <vrf-name> ipv6 ospf
show vrf <vrf-name> ipv6 ospf neighbors
show vrf <vrf-name> ipv6 ospf database
show vrf <vrf-name> ipv6 route
show vrf <vrf-name> ipv6 route ospf
debug vrf <vrf-name> ospfv3
10.7 BGP Configuration
BGP (Border Gateway Protocol) is used for routing information exchange between AS’s (Autonomous Systems) in the
Internet. When a session is established with a different AS, the session is called eBGP (external BGP). When the session is
established with the same AS, it is called iBGP (internal BGP).
10.7.1 iBGP IPv4 neighbor configuration
The following topology will be used to show the BGP configuration with both neighbors in the same AS. In that case, it is a
iBGP (internal BGP) session. An iBGP session should be established between the loopback interfaces of both equipment.
An IGP like OSPF is needed for the equipment to have connectivity to each other’s loopback address.

iBGP IPv4 neighbor configuration
The following configuration parameters will be used:
• AS number: 27686
• Loopback 192.168.0.1/32
• Interface eth5, VLAN 377, IPv4 address 192.168.84.1/30
• Interface eth2, IPv4 address 150.185.128.1/19
• Connected routes redistribution

configure
set interfaces loopback address 192.168.0.1/32
set protocols bgp 27686 neighbor 192.168.0.2 nexthop-self
set protocols bgp 27686 neighbor 192.168.0.2 soft-reconfiguration inbound
set protocols bgp 27686 neighbor 192.168.0.2 remote-as 27686
set protocols bgp 27686 neighbor 192.168.0.2 update-source 192.168.0.1
set protocols bgp 27686 redistribute connected
set protocols bgp 27686 parameters log-neighbor-changes
commit
The available commands for troubleshooting can be found in the topic Verifying BGP IPv4 Routing.
10.7.2 eBGP IPv4 neighbor configuration
The following topology will be used to show the BGP configuration with neighbors in different AS’s. In that case, it is a eBGP
(external BGP) session. For eBGP sessions, usually it is used the physical interface addresses for neighbor establishment
and not the loopback addresses, as in iBGP configuration.

eBGP IPv4 neighbor configuration
• Local AS number: 27686
• Remote AS number: 232318

configure
commit
10.7.3 eBGP IPv4 neighbor configuration with loopbacks
The following topology will be used to show the BGP configuration with neighbors in different AS’s. In that case, it is a
eBGP (external BGP) session.
In this example, the BGP session is established between the loopback interfaces. For the equipment be able to reach the
neighbor’s loopback interface, it is necessary to configure a static route.
Since the session establishment does not happen on directly connected interfaces, the ebgp-multihop parameter must be
set. In this example, ebgp-multihop is set to 2, meaning that the packets are passing through two routing domains to reach
the neighbor IP address.

eBGP IPv4 neighbor configuration with loopbacks
• Loopback: 192.168.0.1/32
• Neighbor loopback: 192.168.0.2/32
configure
set interfaces loopback address 192.168.0.1/32
set protocols bgp 27686 neighbor 192.168.0.2 ebgp-multihop 2
commit
10.7.4 Verifying BGP IPv4 Routing
show ip bgp
show ip bgp summary
show ip bgp neighbors
show ip route
show ip route bgp
debug bgp
show log bgp
show vrf <vrf-name> ip bgp
show vrf <vrf-name> ip bgp summary

show vrf <vrf-name> ip bgp neighbors

show vrf <vrf-name> ip route bgp
debug vrf <vrf-name> bgp
10.7.5 iBGP IPv6 neighbor configuration
The following topology will be used to show the BGP configuration with both neighbors in the same AS. In that case, it is a
iBGP (internal BGP) session. An iBGP session should be established between the loopback interfaces of both equipment.
An IGP like OSPFv3 is needed for the equipment to have connectivity to each other’s loopback address.
iBGP IPv6 neighbor configuration
• AS number: 27686
• Loopback: 2001:db8::1/128
• Neighbor loopback: 2001:db8::2/128
• Interface eth5, VLAN 377, IPv6 address 2001::1/64
• Interface eth2, IPv6 address 2001:cafe::1/48

configure
set interfaces loopback address 2001:db8::1/128
set interfaces ethernet eth2 address 2001:cafe::1/48
set interfaces ethernet eth5 vif 377 address 2001::1/64
set protocols ospfv3 area 0 interface eth2.101
set protocols ospfv3 area 0 interface loopback
set protocols bgp 27686 neighbor 2001:db8::2 address-family ipv6-unicast soft-reconfiguration’inbound’
set protocols bgp 27686 neighbor 2001:db8::2 remote-as 27686
set protocols bgp 27686 neighbor 2001:db8::2 update-source 2001:db8::1
set protocols bgp 27686 address-family ipv6-unicast redistribute connected
commit

10.7.6 eBGP IPv6 neighbor configuration
The following topology will be used to show the BGP configuration with neighbors in different AS’s. In that case, it is a eBGP
(external BGP) session. For eBGP sessions, usually it is used the physical interface addresses for neighbor establishment
and not the loopback addresses, as in iBGP configuration.
eBGP IPv6 neighbor configuration

configure
set protocols bgp 27686 neighbor 2001::2 address-family ipv6-unicast soft-reconfiguration ’inbound’
set protocols bgp 27686 neighbor 2001::2 remote-as 232318
set protocols bgp 27686 neighbor 2001::2 update-source 2001::1
set protocols bgp 27686 address-family ipv6-unicast redistribute connected
commit
10.7.7 eBGP IPv6 neighbor configuration with loopback
The following topology will be used to show the BGP configuration with neighbors in different AS’s. In that case, it is a
eBGP (external BGP) session.
In this example, the BGP session is established between the loopback interfaces. For the equipment be able to reach the
neighbor’s loopback interface, it is necessary to configure a static route.

The ebgp-multihop parameter is used to allow a BGP session to be established between routers that are more than one
hop away from each other. The ebgp-multihop default value is 1. That means it is possible to establish a session only
between routers that are directly connected.
In this case, despite the routers being directly connected, DM2500 demands that the ebgp-multihop parameter be
configured with a value greater than 1 to allow the eBGP session established between loopbacks.
eBGP IPv6 neighbor configuration with loopbacks
• Loopback: 2001:db8::1/128
• Neighbor loopback: 2001:db8::2/128
configure
set interfaces loopback address 2001:db8::1/128
set protocols bgp 27686 neighbor 2001:db8::2 address-family ipv6-unicast soft-reconfiguration ’inbound’
set protocols bgp 27686 neighbor 2001:db8::2 remote-as 232318
set protocols bgp 27686 neighbor 2001:db8::2 update-source 2001:db8::1
set protocols bgp 27686 neighbor 2001:db8::2 ebgp-multihop 2
set protocol static route6 2001:db8::2/128 next-hop 2001::2
commit
10.7.8 Communities configuration
The topology below will be used to show how to configure BGP communities.

Communities configuration
configure
commit
The received prefixes from ASN 3549 are readvertised to ASN 232318. Prefix 203.0.0.13/24 is marked with community
3549:1000 before being readvertised.
set policy prefix-list asn3549-203_0_0_13 rule 1 action ’permit’

set policy prefix-list asn3549-203_0_0_13 rule 1 prefix ’203.0.0.13/24’
set policy route-map adv-to-asn232318 rule 10 action ’permit’
set policy route-map adv-to-asn232318 rule 10 match ip address prefix-list ’asn3549-203_0_0_13’
set policy route-map adv-to-asn232318 rule 10 set community ’3549:1000’
set protocols bgp 27686 neighbor 192.168.84.2 route-map export ’adv-to-asn232318’
Two prefixes are received from ASN 232318. One of the prefixes, 198.51.100.0/24, it received with community 27686:501.
DM2500 is configured in a way that prefixes with that community are readvertised with 2 ASNs prepend.
set policy community-list 1 rule 1 action ’permit’

set policy community-list 1 rule 1 regex ’27686:501’
set policy route-map adv-to-asn3549 rule 10 match community community-list 1
set policy route-map adv-to-asn3549 rule 10 set as-path-prepend ’27686 27686’
set protocols bgp 27686 neighbor 192.168.84.6 route-map export ’adv-to-asn3549’
10.7.9 Enabling ECMP in BGP
ECMP can be enabled in BGP defining the maximum number of equal cost paths for the same destination that can be used.
In the configuration below, four maximum paths are defined for iBGP and eBGP. That means BGP can install up to fours
different routes for the same destination if they have the same cost.

configure
set protocols bgp 27686 maximum-paths ebgp 4
set protocols bgp 27686 maximum-paths ibgp 4
10.7.10 AS-Override configuration
The AS-Override feature is used to overwrite the AS in the AS_PATH attribute of a prefix, preventing this prefix from being
dropped by the BGP loop detection mechanism. The scenario below will be used to demonstrate configuring AS-Override
to serve a customer that has different access points in the same provider.
AS-Override Configuration
CE1
configure
commit
CE2
configure


commit
PE1
configure
set protocols bgp 200 neighbor 10.0.1.2 as-override
commit
PE2
configure
set protocols bgp 200 neighbor 10.0.2.2 as-override
commit
10.7.11 Verifying BGP IPv6 Routing
show ip bgp
show ip bgp summary
show ip bgp neighbors
show ipv6 route
show ipv6 route bgp
debug bgp
show log bgp
show vrf <vrf-name> ip bgp
show vrf <vrf-name> ip bgp summary
show vrf <vrf-name> ip bgp neighbors
show vrf <vrf-name> ip route bgp
debug vrf <vrf-name> bgp
10.8 BFD Configuration
The BFD (Bidirectional Forwarding Detection) is a protocol for link continuity failure detection between two equipment. It
can be enabled for static routes, BGP or OSPF protocols. It enables that the referred protocols converge quickly when a
failure occurs in the link path between the equipment.
For each link or path that is monitored by the BFD, a session is created.
The following BFD parameters can be configured for each interface:
• Minrx (Desired Minimum Receive Interval) It is the minimum interval in microseconds, between BFD control
packets received that the system needs at the current moment.

• Mintx (Required Minimum Transmit Interval) – It is the minimum interval in microseconds, between BFD control
packets transmitted that the system would like to use at the current moment.
• Multipler (Detection Multiplier) – The interval negotiated covering transmission of control packet, multiplied by
this variable, this will be the detection time for the BFD session.
set protocols bfd interface <interface> mintx <100-10000>

set protocols bfd interface <interface> minrx <100-10000>
set protocols bfd interface <interface> multiplier <3-255>
These configurations are global per interface, this means, all the sessions created in a given interface will be
configured with the values input in this interface.
The BFD sessions operate only in the single-hop mode.
There is no support for the “Echo mode” and “Demand Mode” modes
10.8.1 BFD in static routes
The BFD can be configured in the static routes for all the interfaces, a specific interface or only for a static route.
It is only possible to enable the BFD in a static route if an interface with IP exists in the same network of the
IP configured as “next-hop” of the Static Route.
To activate the BFD in all the static routes and in all the interfaces, the user should execute the following procedure:
configure
set protocols static bfd all-interfaces
commit
To activate the BFD only in the static routes of a specific interface, the user should execute the following procedure:
configure
set protocols static bfd interface <interface>
commit
To activate the BFD only in one specific static route, the user should execute the following procedure:

configure
set protocols static route <network/mask> next-hop <next-hop-ip> bfd
commit
The scenario below will be used to show configuration of the BFD enabled in static routes.
Static route with BFD
Assuming the scenario above, the next steps will show how to configure the BFD in static routes:
configure
! Configuration DM25_1
set protocols static route 20.20.20.0/24 next-hop 1.1.1.2 bfd
set protocols static route 10.10.10.0/24 next-hop 1.1.1.2 bfd
commit
The available commands for troubleshooting can be found in the topic Verifying BFD Session.
10.8.2 BFD in OSPF
The BFD can be configured in the OSPFv2 for all the interfaces or for a specific interface. To activate the BFD in all the
interfaces participant of the OSPF, the user should execute the following configuration:
configure
set protocols ospf bfd all-interfaces
commit
To activate the BFD in only one interface participant of the OSPF, the user should execute the following configuration:
configure
set protocols ospf bfd interface <interface>
commit
The scenario below will be used to show configuration of the BFD with OSPF.

OSPF with BFD
Below is an example of BFD configuration with OSPF based on the scenario mentioned above:
configure
set interfaces loopback lo address ’10.0.0.1/32’
set protocols ospf bfd interface eth1
set interfaces loopback lo address ’10.0.0.2/32’
set protocols ospf bfd interface eth1
commit
10.8.3 BFD in OSPFv3
The BFD can be configured in the OSPFv3 protocol for all interfaces or for a specific interface. To activate the BFD in all the
interfaces participant of the OSPFv3 protocol, the user should execute the following configuration:
configure
set protocols ospfv3 bfd all-interfaces
commit
To activate the BFD in only one interface participant of the OSPFv3, the user should execute the following configuration:
configure
set protocols ospfv3 bfd interface <interface>
commit
The scenario below will be used to show the BFD with OSPFv3 configuration.

OSPFv3 with BFD
Below is an example of BFD configuration with OSPFv3 based on the above scenario:
configure
! Configuration in DM25_1
set interfaces ethernet eth1 address ’2001:db8:ff::1/64’
set interfaces loopback lo1 address ’2001:db8::1/128’
set protocols ospfv3 bfd interface eth1
! Configuration in DM25_2
set interfaces ethernet eth1 address ’2001:db8:ff::2/64’
set interfaces loopback lo1 address ’2001:db8::2/128’
set protocols ospfv3 bfd interface eth1
commit
10.8.4 BFD in BGP
The BFD can be configured by a neighbor BGP through the “fall-over” command according to the procedure described
below:
configure
set protocols bgp <bgp_id> neighbor <neighbor_ip> fall-over bfd
commit
The scenario below will be used to show configuration of the BFD enabled with BGP.
BGP in BFD
Below is an example of BFD configuration with BGP based on the scenario mentioned above:

configure
set protocols bgp 1 neighbor 1.1.1.2 fall-over bfd
set protocols bgp 2 neighbor 1.1.1.1 fall-over bfd
commit
It is possible to use BFD with BGP IPv4 and IPv6 neighbors as well.
10.8.5 Verifying BFD Session
show bfd
show bfd session
show bfd session detail
show log bfd
show vrf <vrf-name> bfd
show vrf <vrf-name> bfd session
show vrf <vrf-name> bfd session detail
10.9 VRRP Configuration
The Virtual Router Redundancy Protocol (VRRP) works for Gateway redundancy in a network, with the objective of two or
more routers sharing the same virtual IP in active/backup mode (by default).
For other devices on the network, VRRP allows the gateway to be viewed as a single device.
VRRP is quite simple in its basic function: a Router is elected the Master and is responsible for routing network traffic to
devices that have Virtual IP as their gateway. The second router called Backup only monitors bus VRRP packets. When the
Master equipment ceases to function, the Backup equipment assumes its functions as Master.
On the DM2500, VRRP is supported on both physical interfaces and VLAN interfaces.

The router configured with a higher priority will be elected initially as Master. If all the routers have the
same priority, the router with the highest IP address will be elected as Master.
It is recommended to enable the preemption function that will allow that the router that was master prior
to the failure, upon returning from the failure, assumes again the master position.
10.9.1 Setting the VRRPv2
The DM2500 has support for the VRRPv2 version with IPv4 addressing, described by the RFCs 2338 and 3768.
The scenario below will be used to show configuration of the VRRP.
VRRPv2
Assuming the scenario according to the diagram above, we have the following example to configure the VRRP Master:
configure
set interfaces ethernet eth2 vrrp vrrp-group 254 authentication password ’d4t4c0m’
set interfaces ethernet eth2 vrrp vrrp-group 254 authentication type ’ah’
set interfaces ethernet eth2 vrrp vrrp-group 254 preempt ’true’
set interfaces ethernet eth2 vrrp vrrp-group 254 priority ’200’
set interfaces ethernet eth2 vrrp vrrp-group 254 virtual-address ’192.168.253.41’
set interfaces ethernet eth4 vif 4056 address ’192.168.45.105/24’
set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 authentication password ’d4t4c0m’
set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 authentication type ’ah’
set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 preempt ’true’
set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 priority ’200’
set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 virtual-address ’192.168.45.1’
commit
Assuming the scenario according to the diagram above, we have the following example to configure the VRRP Backup:
configure
set interfaces ethernet eth2 vrrp vrrp-group 254 version 2
set interfaces ethernet eth2 vrrp vrrp-group 254 authentication password ’d4t4c0m’
set interfaces ethernet eth2 vrrp vrrp-group 254 authentication type ’ah’


set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 version 2
set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 authentication password ’d4t4c0m’
set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 authentication type ’ah’
set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 virtual-address ’192.168.45.1’
commit
The next example is based on the previous example, including all the interfaces in a synchronization group so that, if one of
the interfaces in the Master fails in any of the VRRP groups, all the interfaces that control the Master become interfaces in a
backup router.
Master
configure
set interfaces ethernet eth2 vrrp vrrp-group 254 sync-group ’DATACOM_SYNC’
set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 sync-group ’DATACOM_SYNC’
commit
Backup
configure
set interfaces ethernet eth2 vrrp vrrp-group 254 sync-group ’DATACOM_SYNC’
set interfaces ethernet eth4 vif 4056 vrrp vrrp-group 255 sync-group ’DATACOM_SYNC’
commit
The available commands for troubleshooting can be found in the topic Verifying VRRP.
10.9.2 Setting the VRRPv3
The VRRP protocol version 3 (v3) offers support to IPv4 and IPv6 addresses described by the RFC 5798, while the VRRP
version 2 (v2) supports only IPv4 addresses.
On the DM2500, VRRPv3 is supported on physical interfaces, and VLAN interfaces.
Version 3 of the VRRP has no support to authentication.
The scenario below will be used to show configuration of the VRRPv3.

VRRPv3
Configuration of VRRP version 3 protocol will be shown using as base the scenario above.
Master
configure
set interfaces ethernet eth2 address ’2018::2/64’
set interfaces ethernet eth2 vrrp vrrp-group 21 version ’3’
set interfaces ethernet eth2 vrrp vrrp-group 21 virtual-address ’2018::1’
set interfaces ethernet eth2 vrrp vrrp-group 21 virtual-link-local ’auto-configuration’
set interfaces ethernet eth4 vif 2477 address ’2477::2/64’
set interfaces ethernet eth4 vif 2477 vrrp vrrp-group 22 version ’3’
set interfaces ethernet eth4 vif 2477 vrrp vrrp-group 22 virtual-address ’2477::1’
set interfaces ethernet eth4 vif 2477 vrrp vrrp-group 22 virtual-link-local ’auto-configuration’
commit
Backup
configure
set interfaces ethernet eth2 address ’2018::3/64’
set interfaces ethernet eth2 vrrp vrrp-group 21 version ’3’
set interfaces ethernet eth2 vrrp vrrp-group 21 virtual-address ’2018::1’
set interfaces ethernet eth2 vrrp vrrp-group 21 virtual-link-local ’auto-configuration’
set interfaces ethernet eth4 vif 2477 address ’2477::3/64’
set interfaces ethernet eth4 vif 2477 vrrp vrrp-group 22 version ’3’
set interfaces ethernet eth4 vif 2477 vrrp vrrp-group 22 virtual-address ’2477::1’
set interfaces ethernet eth4 vif 2477 vrrp vrrp-group 22 virtual-link-local ’auto-configuration’
commit
The next example is based on the previous example, including all the interfaces in a synchronization group so that, if one of
the interfaces in the Master fails in any of the VRRP groups, all the interfaces that control the Master become interfaces in a
backup router.
Master
configure
set interfaces ethernet eth2 vrrp vrrp-group 21 sync-group ’DTC_SYNC’
set interfaces ethernet eth4 vif 2477 vrrp vrrp-group 22 sync-group ’DTC_SYNC’
commit

Backup
configure
set interfaces ethernet eth2 vrrp vrrp-group 21 sync-group ’DTC_SYNC’
set interfaces ethernet eth4 vif 2477 vrrp vrrp-group 22 sync-group ’DTC_SYNC’
commit
10.9.3 Setting the VRRP Track Interface
There are scenarios where the VRRP Master router is still active, but cannot forward packets because the outgoing interface
(such as the Internet for example) goes down. The DM2500 allows to configure the track for the VRRP process to monitor
any object, which may be the state of the interface (Up/Down) or to monitor the state of a route, thus reducing the VRRP
priority based on one condition.
The VRRP Track Interface monitors the interface state (Up/Down) and reduces the priority of the VRRP router if the interface
changes its state to down.
VRRP Track Interface is supported for both IPv4 and IPv6.
If the router is the IP address owner (the address configured in interface is the same as the virtual address),
the priority will be always 255 and it will not be decremented by tracking.
The scenario below will be used to demonstrate the configuration of the VRRP Track Interface.
VRRP Track Interface

The setting below will be used to demonstrate the reduction of the Master Router VRRP priority so that when the output
link configured with track interface drops, the Backup Router will become the Master.
Master
configure
! Setting the track-interface on failure will reduce the VRRP priority to 150
set interfaces ethernet eth4 vrrp vrrp-group 254 track-interface eth2 weight ’50’
commit
Backup
configure
commit
When the Master Router eth2 interface fails, the VRRP track will identify the fault and thus reduce the Master Router VRRP
priority, thus the Backup Router will become the Master.
10.9.4 Setting the VRRP Track Route
VRRP Track Route monitors the state of any route and reduces the priority of the VRRP router if the route is no longer
reachable.
VRRP Track Interface is supported for IPv4 only
The scenario below will be used to demonstrate the VRRP Track Route configuration.

VRRP Track Route
The setting below will be used to demonstrate reducing the Master Router VRRP priority so that when route 8.8.8.8 is not
reached, the Backup Router will become the Master.
Master
configure
! Setting the track-route on failure will reduce the VRRP priority to 150
set interfaces ethernet eth4 vrrp vrrp-group 254 track-route IPv4 target ’8.8.8.8’
set interfaces ethernet eth4 vrrp vrrp-group 254 track-route IPv4 weight ’50’
commit
10.9.5 Setting the VRRP Transition Scripts
Transition scripts can help you implement various adjustments, such as starting and stopping services, or even modifying
the DM2500 configuration in the VRRP transition. This setting will cause the VRRP process to call a script that will execute
as configured during VRRP transitions.
VRRP Transition Scripts only support actions on IPSec tunnels.
The VRRP states that are monitored to trigger scripts are:
• backup: VRRP state transition action for backup.
• fault: VRRP state transition action for fault.
• master: State transition action from VRRP to master.
The actions that scripts can perform based on VRRP states are:

• ipsec-start: Starts IPSec on VRRP state transition.
• ipsec-restart: Restarts IPSec on VRRP state transition.
• ipsec-stop: Stop IPSec on VRRP state transition.
The configuration below will be used to demonstrate IPSec tunnel process stop after the VRRP state changes to backup and
IPSec tunnel process starts when VRRP change to master.
Master:
configure
! Configuring transition-scripts in case the state changes to backup will stop IPSec
set interfaces ethernet eth4 vrrp vrrp-group 254 run-transition-scripts
backup ’ipsec-stop’
! Configuring transition-scripts, in case the state changes to master will start IPSec
set interfaces ethernet eth4 vrrp vrrp-group 254 run-transition-scripts
master ’ipsec-start’
commit
10.9.6 Verifying VRRP
show vrrp
show vrrp detail
show vrrp interfaces <interface>
show vrrp statistics
show vrrp sync-group
show log vrrp
show vrf <vrf-name> vrrp
show vrf <vrf-name> vrrp detail
show vrf <vrf-name> vrrp interfaces <interface>
show vrf <vrf-name> vrrp statistics
show vrf <vrf-name> vrrp sync-group
10.10 PIM Configuration
PIM (Protocol Independent Multicast) is a family of protocols with objective to support forwarding of multicast packets.
These protocols use the routes learned to create a multicast flow path, no depending of any specific routing protocol.
There are some PIM family protocols, like: PIM SM (Sparse Mode), PIM SSM (Source-Specific Multicast), PIM DM (Dense
Mode) and Bidirectional PIM. These protocols basically differentiated in the path construction mode of multicast flow.

Only are supported the PIM SM and PIM SSM modes.
The scenario below will be used to shows the configuration of PIM SM with static RP, PIM SSM and OSPF.
PIM
The configuration of the PIM protocol will be demonstrated using the scenario above.
EQUIPMENT-A
configure
set protocols ospf log-adjacency-changes
set protocols pim rp-address 20.20.20.20
set interfaces loopback lo1 multicast enable
set interfaces loopback lo1 ip pim enable
set interfaces ethernet eth1 ip ospf network broadcast
set interfaces ethernet eth1 ip pim enable
commit
EQUIPMENT-B
configure
set protocols ospf log-adjacency-changes
set protocols pim rp-address 20.20.20.20
set interfaces loopback lo1 multicast enable
set interfaces loopback lo1 ip pim enable
set interfaces ethernet eth1 ip ospf network broadcast
commit

The available commands for troubleshooting can be found in the topic Verifying PIM.
10.10.1 Setting IGMP version
IGMP version 3 is the default configuration of this equipment, but if necessary it is possible change the IGMP version using
the commands bellow.
IGMP version 3 supports PIM SM and PIM SSM and IGMP version 2 supports only PIM SM.
Change IGMP protocol version to 2:
configure
set interfaces ethernet eth1 ip pim igmp v2
commit
Change IGMP protocol version to 3:
configure
set interfaces ethernet eth1 ip pim igmp v3
commit
The available commands for troubleshooting can be found in the topic Verifying PIM.
10.10.2 Verifying PIM
show pim
show pim route-cache
show pim statistics
show log pim
10.11 VRF Configuration
VRF (Virtual Routing and Forwarding) is a feature that allows different routing instances in the same equipment.

Only are supported the creation of seven VRFs in the product.
Some features are not supported in VRFs. For more details on unsupported features, see the document
DM2500 Release Notes.
10.11.1 Setting the VRF lite
VRF lite is a basic version of VRF and does not support MPLS signaling.
The scenario below will be used to illustrate the configuration of the VRF lite.
Traffic isolation between customers with VRFs
There must not be communication between clients 1 and 2. Therefore, two VRFs will be configured to isolate the routing
tables and the traffic between them. The following specifications will be used:
VRF CLI1
• Interface in VLAN 10 with IPv4 address 192.168.10.1/24
VRF CLI2

configure
set vrf CLI1 interfaces ethernet eth1 vif 10 address 192.168.10.1/24
commit
The scenario below will be used to demonstrate the configuration of equipment management outside a VRF and a service
VRF with IP address overlapping.
VRF with overlapping IP address
There is no communication between the management network on the eth1 interface and the CLI1 data VRF on the eth6
interface. Both interfaces use the same IP address.
The following specifications will be used:
MANAGEMENT
• eth1 interface with IPv4 address 192.168.0.1/24
VRF CLI1
• eth6 interface with IPv4 address 192.168.0.1/24
configure
set vrf CLI1 interfaces ethernet eth6 address 192.168.0.1/24
commit
The available commands for troubleshooting can be found in the topic Verifying VRF.
10.11.2 Verifying VRF

show vrf <vrf name> interfaces

show vrf <vrf name> ip route
10.12 ECMP Configuration
ECMP (Equal Cost Multi-Path) allows that flows or packets to the same destination can be transmitted across multiple
paths of equal cost.
The load balance can be realized per packets or per flow.
10.12.1 Load balance per packet
In packet mode, load-balance does not take into account flows. Packets are load-balanced in a round-robin way between
the available next-hops.
Configuration for IPv4:
configure
set system ip ecmp packets
commit
configure
set system ipv6 ecmp packets
commit
10.12.2 Load balance per flow
The flow load balancing can be realized in two ways: ports-unaware and ports-aware.
In ports-unaware mode, TCP/UDP ports are not taked into account when identifying the flow.
configure
set system ip ecmp ports-unaware
commit
configure
set system ipv6 ecmp ports-unaware
commit
In ports-aware mode, TCP/UDP ports are taken into account in the flow identification.

configure
set system ip ecmp ports-aware
commit
configure
set system ipv6 ecmp ports-aware
commit
10.12.3 Disabling ECMP
To disable the ECMP, follow the configuration below.
configure
set system ip ecmp disabled
commit
configure
set system ipv6 ecmp disabled
commit
ECMP confirmation can also be performed in VRFs. The previously shown configuration commands can be
executed in the VRF context, as in set vrf <vrf-name> system ip ecmp ... or set vrf <vrf-name> system
ipv6 ecmp ...
Consult the specific protocol sessions to check on how to enable ECMP on it.

DM2500 - Quick Configuration Guide 11 Tunneling
11 Tunneling
Tunneling consists in encapsulation of a protocol within another protocol to allow transparency and higher security during
data flowing the unsafe public networks or even in private networks.
• GRE tunnels Configuration
• IPSec tunnels Configuration
11.1 GRE tunnels Configuration
The GRE (Generic Routing Encapsulation) is an IP packets encapsulation method through the IP infrastructure with the
objective to interconnect networks that communicate between themselves through a public infrastructure (in general the
Internet).
11.1.1 IPv4 Tunnel
The scenario below will be used to describe how to configure a GRE tunnel.
GRE Tunnel Setup
Let’s suppose that the user would like to create a point-to-point GRE tunnel in the 35.35.35.0/ 31 network between the R1
and R2 equipment, both connected to the Internet with assigned fixed IPv4 addresses and different internal network
learned by OSPF. The procedure below indicates how to execute this configuration:
Router 1 (R1)
configure
set interfaces tunnel tun0 address 35.35.35.1/31
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 local-ip 209.165.201.15
set interfaces tunnel tun0 remote-ip 201.122.120.3
commit

Router 2 (R2)
configure
set interfaces tunnel tun0 address 35.35.35.2/31
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 local-ip 201.122.120.3
set interfaces tunnel tun0 remote-ip 209.165.201.15
commit
The available commands for troubleshooting can be found in the topic Verifying GRE.
11.1.2 IPv6 Tunnel
The GRE also can be used with IPv6 addressing in DM2500. The scenario below will be used to describe how to configure
an IPv6 GRE tunnel.
IPv6 GRE Tunnel Setup
Let’s suppose that the user would like to create a point-to-point IPv6 GRE tunnel in the fd01::1/64 network between the R1
and R2 equipment, both connected to the Internet with assigned fixed IPv6 addresses and different internal network
reached via static routes. The procedure below indicates how to execute this configuration:
Router 1 (R1)
configure
set interfaces ethernet eth1 address ’fd00:1::1/64’
set interfaces ethernet eth8 address ’2001:1290:1::6/64’
set interfaces tunnel tun0 address ’fd01::1/64’
set interfaces tunnel tun0 encapsulation ’gre6’
set interfaces tunnel tun0 local-ip ’2001:1290:1::6’
set interfaces tunnel tun0 mtu ’2000’
set interfaces tunnel tun0 remote-ip ’2001:1290:1:5::2’
set protocols static route6 ::/0 next-hop ’2001:1290:1::1’
commit

Router 2 (R2)
configure
set interfaces ethernet eth1 address ’fd00::1/64’
set interfaces ethernet eth8 address ’2001:1290:1:5::2/64’
set interfaces tunnel tun0 address ’fd01::2/64’
set interfaces tunnel tun0 encapsulation ’gre6’
set interfaces tunnel tun0 local-ip ’2001:1290:1:5::2’
set interfaces tunnel tun0 mtu ’2000’
set interfaces tunnel tun0 remote-ip ’2001:1290:1::6’
set protocols static route6 ::/0 next-hop ’2001:1290:1:5::1’
commit
The available commands for troubleshooting can be found in the topic Verifying GRE.
11.1.3 GRE IPV4 Tunnel with IPsec
The GRE tunnels are not encrypted and do not provide any security due to use a simple key in clear text in our packets. This
means that the GRE tunnels, do not provide an adequate security to networks. At the same time, IPsec policy-based
tunnels cannot carry routing protocols, non-IP traffic such as Internetwork Packet Exchange (IPX) or multicast, the IPsec
also has limitations from the view of the operation. Use of tunnel interfaces together with IPsec VPN provides connections
of routable tunnels between gateways. For safe routable tunnels, the interfaces of GRE tunnel should be used together
with an IPsec connection, so that the IP tunnel can be protected by the IPsec tunnel. The scenario below will be used to
show configuration of the GRE tunnel protection with IPsec.
Scenario Túnel GRE with IPsec
Considering that the user would like to configure a GRE tunnel between two DM2500 securely using IPsec protection
between the same endpoints. The procedure below indicates how to execute this configuration:
Router 1 (DM2500 4GT)
configure
set interfaces tunnel tun1 remote-ip ’192.168.72.6’
set interfaces tunnel tun1 multicast ’enable’
set interfaces tunnel tun1 address ’192.168.191.1/30’
set interfaces tunnel tun1 local-ip ’192.168.254.41’
set interfaces tunnel tun1 encapsulation ’gre’
set vpn ipsec ike-group IKE-CLINK-BRM key-exchange ’ikev2’
set vpn ipsec ike-group IKE-CLINK-BRM lifetime ’3600’
set vpn ipsec ike-group IKE-CLINK-BRM proposal 10 hash ’sha1’
set vpn ipsec ike-group IKE-CLINK-BRM proposal 10 dh-group ’14’
set vpn ipsec ike-group IKE-CLINK-BRM proposal 10 encryption ’aes256’

set vpn ipsec esp-group ESP-CLINK-BRM lifetime ’1800’

set vpn ipsec esp-group ESP-CLINK-BRM pfs ’enable’
set vpn ipsec esp-group ESP-CLINK-BRM proposal 10 hash ’sha1’
set vpn ipsec esp-group ESP-CLINK-BRM proposal 10 encryption ’aes128’
set vpn ipsec esp-group ESP-CLINK-BRM mode ’transport’
set vpn ipsec site-to-site peer 192.168.72.6 authentication pre-shared-secret ’d4t4c0m’
set vpn ipsec site-to-site peer 192.168.72.6 authentication mode ’pre-shared-secret’
set vpn ipsec site-to-site peer 192.168.72.6 ike-group ’IKE-CLINK-BRM’
set vpn ipsec site-to-site peer 192.168.72.6 tunnel 2018 protocol ’gre’
set vpn ipsec site-to-site peer 192.168.72.6 tunnel 2018 esp-group ’ESP-CLINK-BRM’
set vpn ipsec site-to-site peer 192.168.72.6 local-address ’192.168.254.41’
set vpn ipsec site-to-site peer 192.168.72.6 connection-type ’initiate’
set vpn ipsec ipsec-interfaces interface ’eth2’
set protocols static route 192.168.64.0/22 next-hop ’192.168.191.2’
commit
configure
set interfaces tunnel tun1 remote-ip ’192.168.254.41’
set vpn ipsec ike-group IKE-CLINK-BRM key-exchange ’ikev2’
set vpn ipsec ike-group IKE-CLINK-BRM lifetime ’3600’
set vpn ipsec ike-group IKE-CLINK-BRM proposal 10 hash ’sha1’
set vpn ipsec ike-group IKE-CLINK-BRM proposal 10 dh-group ’14’
set vpn ipsec ike-group IKE-CLINK-BRM proposal 10 encryption ’aes256’
set vpn ipsec esp-group ESP-CLINK-BRM lifetime ’1800’
set vpn ipsec esp-group ESP-CLINK-BRM pfs ’enable’
set vpn ipsec esp-group ESP-CLINK-BRM proposal 10 hash ’sha1’
set vpn ipsec esp-group ESP-CLINK-BRM proposal 10 encryption ’aes128’
set vpn ipsec esp-group ESP-CLINK-BRM mode ’transport’
set vpn ipsec site-to-site peer 192.168.254.41 authentication pre-shared-secret ’d4t4c0m’
set vpn ipsec site-to-site peer 192.168.254.41 ike-group ’IKE-CLINK-BRM’
set vpn ipsec site-to-site peer 192.168.254.41 tunnel 2018 protocol ’gre’
set vpn ipsec site-to-site peer 192.168.254.41 tunnel 2018 esp-group ’ESP-CLINK-BRM’
set vpn ipsec ipsec-interfaces interface ’eth1.503’
set protocols static route 192.168.45.0/24 next-hop ’192.168.191.1’
commit
The available commands for troubleshooting can be found in the topic Verifying GRE Tunnel with IPsec.
Verifying GRE
show interfaces tunnel

show interfaces tunnel detail
show vrf <vrf-name> interfaces tunnel
show vrf <vrf-name> interfaces tunnel detail

Verifying GRE Tunnel with IPsec
show interfaces tunnel

show interfaces tunnel detail
show vpn ipsec status
show vpn ipsec sa
show vpn ipsec sa detail
show vpn debug
show vpn debug detail
show vpn debug peer <IP Address>
show log vpn ipsec
show vrf <vrf-name> interfaces tunnel
show vrf <vrf-name> interfaces tunnel detail
show vrf <vrf-name> vpn ipsec status
show vrf <vrf-name> vpn ipsec sa
show vrf <vrf-name> vpn ipsec sa detail
show vrf <vrf-name> vpn ike sa
show vrf <vrf-name> vpn debug
show vrf <vrf-name> vpn debug detail
show vrf <vrf-name> vpn debug peer <IP Address>
11.2 IPSec tunnels Configuration
The IPsec (Internet Protocol Security) is a set of protocols defined by the IETF to assure a safe change of IPv4 packets
through unsafe networks (Internet). The protocol has mechanisms for checking of data integrity, assuring that it has not
been modified by an unauthorized individual, in addition of assuring the confidentiality, where only the authorized peers
can see the data, adopting encryption methods and control of access.
By default the DM2500 uses IKE (Internet Key Exchange) version 1 for automatic key management for
encryption.
11.2.1 Site-to-site IPsec IPv4 Tunnel
The scenario below will be used to show configuration of the VPN IPsec.
VPN IPsec Setup

The DM2500 routers have LAN with IP addressing as shown in the figure above. IP addressing of the WAN routers is shown
in the following configurations, as well as all the parameters used by the IPsec. The procedure below indicates how to
execute this configuration:
configure
set vpn ipsec ike-group ike-grp-1 proposal 1 hash ’sha1’
set vpn ipsec ike-group ike-grp-1 proposal 1 dh-group ’14’
set vpn ipsec ike-group ike-grp-1 proposal 1 encryption ’aes256’
set vpn ipsec esp-group esp-grp-1 pfs ’dh-group14’
set vpn ipsec esp-group esp-grp-1 proposal 1 hash ’sha1’
set vpn ipsec esp-group esp-grp-1 proposal 1 encryption ’aes256’
set vpn ipsec site-to-site peer 80.80.80.1 authentication pre-shared-secret ’datacom123’
set vpn ipsec site-to-site peer 80.80.80.1 ike-group ’ike-grp-1’
set vpn ipsec site-to-site peer 80.80.80.1 default-esp-group ’esp-grp-1’
set vpn ipsec site-to-site peer 80.80.80.1 tunnel 1 local prefix ’192.168.10.0/24’
set vpn ipsec site-to-site peer 80.80.80.1 tunnel 1 remote prefix ’192.168.6.0/24’
commit
configure
set vpn ipsec esp-group esp-grp-1 pfs dh-group14
set vpn ipsec esp-group esp-grp-1 proposal 1 hash sha1
set vpn ipsec esp-group esp-grp-1 proposal 1 encryption aes256
set vpn ipsec site-to-site peer 80.80.80.2 tunnel 1 local prefix 192.168.6.0/24
set vpn ipsec site-to-site peer 80.80.80.2 tunnel 1 remote prefix 192.168.10.0/24
commit
The available commands for troubleshooting can be found in the topic Verifying IPsec.
11.2.2 Site-to-site IPsec IPv6 Tunnel
The scenario below will be used to show configuration of the VPN IPsec with IPv6.

VPN IPsec IPv6 Setup
The DM2500 routers have LAN with IPv6 addressing as shown in the figure above. IPv6 addressing of the WAN routers is
shown in the following configurations, as well as all the parameters used by the IPsec. The procedure below indicates how
to execute this configuration:
configure
set interfaces ethernet eth1 vif 104 address ’2804:130c::2/64’
set interfaces ethernet eth2 vif 101 address ’fd00::1/64’
set vpn ipsec site-to-site peer 2804:130c::1 authentication mode ’pre-shared-secret’
set vpn ipsec site-to-site peer 2804:130c::1 authentication pre-shared-secret ’d4t4c4m’
set vpn ipsec site-to-site peer 2804:130c::1 connection-type ’respond’
set vpn ipsec site-to-site peer 2804:130c::1 default-esp-group ’esp-grp-1’
set vpn ipsec site-to-site peer 2804:130c::1 ike-group ’ike-grp-1’
set vpn ipsec site-to-site peer 2804:130c::1 local-address ’2804:130c::2’
set vpn ipsec site-to-site peer 2804:130c::1 tunnel 1 id ’@respondTun1’
set vpn ipsec site-to-site peer 2804:130c::1 tunnel 1 allow-nat-networks ’disable’
set vpn ipsec site-to-site peer 2804:130c::1 tunnel 1 allow-public-networks ’disable’
set vpn ipsec site-to-site peer 2804:130c::1 tunnel 1 local prefix ’fd00::/64’
set vpn ipsec site-to-site peer 2804:130c::1 tunnel 1 remote prefix ’fd00:1::/64’
set vpn ipsec site-to-site peer 2804:130c::1 tunnel 1 remote-id ’@initiatorTun1’
set protocols static interface-route6 fd00:1::/64 next-hop-interface ’eth1.104’
commit
configure
set interfaces ethernet eth1 vif 104 address ’2804:130c::1/64’
set interfaces ethernet eth2 vif 101 address ’fd00:1::1/64’
set vpn ipsec site-to-site peer 2804:130c::2 authentication mode ’pre-shared-secret’
set vpn ipsec site-to-site peer 2804:130c::2 authentication pre-shared-secret ’d4t4c4m’
set vpn ipsec site-to-site peer 2804:130c::2 default-esp-group ’esp-grp-1’
set vpn ipsec site-to-site peer 2804:130c::2 ike-group ’ike-grp-1’
set vpn ipsec site-to-site peer 2804:130c::2 local-address ’2804:130c::1’
set vpn ipsec site-to-site peer 2804:130c::2 tunnel 1 id ’@initiatorTun1’
set vpn ipsec site-to-site peer 2804:130c::2 tunnel 1 allow-nat-networks ’disable’
set vpn ipsec site-to-site peer 2804:130c::2 tunnel 1 allow-public-networks ’disable’
set vpn ipsec site-to-site peer 2804:130c::2 tunnel 1 local prefix ’fd00:1::/64’
set vpn ipsec site-to-site peer 2804:130c::2 tunnel 1 remote prefix ’fd00::/64’

set vpn ipsec site-to-site peer 2804:130c::2 tunnel 1 remote-id ’@respondTun1’

set protocols static interface-route6 fd00::/64 next-hop-interface ’eth1.104’
commit
11.2.3 Site-to-site tunnel IPsec with NAT Traversal
The native IPsec packets are encapsulated using the ESP (Encapsulated Security Payload). In these packets, the IP
addresses are incorporated in the encapsulated packet. This causes problems when the IPsec packets should pass through
a device that makes NAT. When the NAT (Network Address Translation) occurs, the NAT device changes its own source IP
address (and sometimes the port number) to other IP address in the output packets. The NAT device hears a response and,
a response packet is received, the NAT device reverses the translation so that the input packet can reach the correct
destination. This allows that IP addresses within a private network are “hidden” to external networks. The NAT does
not operate well with the IPsec, because the IP addresses are incorporated in the encapsulated packet payload. Due to
several reasons, this means that the IPsec peer cannot be located behind a NAT device. The IPsec has a feature called NAT
Traversal (NAT-T, RFCs 3947 and 3948) that allows that each IPsec packet can be re-encapsulated in a UDP packet, which
can be handled correctly by the device configured with NAT. The NAT-T is executed on the IPsec. To support the NAT-T, the
device that makes NAT and has a firewall should be configured to allow the following configuration: - IKE through UDP
500 port - IPsec NAT-T through UDP 4500 port - ESP Some NAT devices are already provided pre-configured with all this
in a resource called “IPsec Passthrough”. However, the IPsec Passthrough is incompatible with the NAT traversal. The
devices with IPsec Passthrough recognize the IPsec UDP packets and try in an incorrect manner to forward the packets.
This corrupts the packets in such a manner that the NAT-T no longer operates. The scenario below will be used to show
configuration of the VPN IPsec. with NAT-T
Scenario VPN IPsec with NAT-Traversal
The procedure below shows how the proposed scenarios can be configured:
Configuração – DM2500 4GT
configure


set vpn ipsec site-to-site peer 0.0.0.0 tunnel 1 local prefix ’192.168.10.0/24’
set vpn ipsec site-to-site peer 0.0.0.0 tunnel 1 remote prefix ’192.168.60.0/24’
set vpn ipsec nat-traversal enable
set vpn ipsec nat-networks allowed-network 192.168.0.0/16 exclude 192.168.10.0/24
commit
An important change in this configuration is the peer address. It is defined as 0.0.0.0 to represent “any” IP address. As the
peer IP address is practically unknown, the DM2500 4GT shall not initiate the connections with the peer, it will only receive
connections from the peer.
Configuração – DM2500 6GT
configure
set vpn ipsec esp-group esp-grp-1 pfs dh-group14
set vpn ipsec esp-group esp-grp-1 proposal 1 hash sha1
set vpn ipsec esp-group esp-grp-1 proposal 1 encryption aes256
set vpn ipsec site-to-site peer 190.100.10.210 tunnel 1 local prefix 192.168.60.0/24
set vpn ipsec site-to-site peer 190.100.10.210 tunnel 1 remote prefix 192.168.10.0/24
set vpn ipsec nat-traversal enable
set vpn ipsec nat-networks allowed-network 192.168.0.0/16 exclude 192.168.60.0/24
commit
11.2.4 IPsec Tunnel with Virtual Tunnel Interface
IPsec with Virtual Tunnel Interfaces (VTIs) provide a routable interface type for establishing IPsec tunnels and an easy way
to define protection between sites to form an overlay network. IPsec VTIs simplify configuration of IPsec for protection of
remote links and simplify network management.
In the DM2500 there is no support for scenarios with high availablility or load balancing using tunnels with
VTI.

Scenario IPsec with VTI
Note that in an IPsec scenario with VTI, the local tunnel X and tunnel X remote configuration is not used within the
IPsec peer. The vti bind configuration is used inside the peer and the traffic to be encrypted must be forwarded to a VTI
interface that is associated with IPSec.
VTI interfaces have the IP address config, but this does not perform any type of encapsulation in the packet (different from
GRE). The IPsec peer address and the local-address must be the addresses of physical interfaces (WANs), not the addresses
of VTIs.
Suppose the user wants to configure a tunnel with 1400 bytes MTU (Maximum Transmission Unit) using VTI interfaces
between two DM2500s with IPsec protection. The following procedure demonstrates how to perform this configuration.
The MTU of the VTI interface must be less than the MTU of the physical interface through which the encrypted
packets will be sent. In the example below, VTI has MTU of 1400 and eth4 has MTU of 1500. In this case there
is a difference of 100 bytes, enough for the overhead that IPsec adds and to avoid fragmentation on the eth2
interface.
Router R1 (DM2500)
configure
set interfaces ethernet eth4 mtu ’1500’
set interfaces vti vti1 address ’11.11.11.1/30’
set interfaces vti vti1 description ’IPsec-IPv4’
set interfaces vti vti1 mtu ’1400’
set protocols static interface-route 192.167.0.0/16 next-hop-interface ’vti1’
set vpn ipsec esp-group esp-grp-1 compression ’disable’
set vpn ipsec esp-group esp-grp-1 lifetime ’28800’
set vpn ipsec esp-group esp-grp-1 mode ’tunnel’
set vpn ipsec esp-group esp-grp-1 pfs ’enable’
set vpn ipsec ike-group ike-grp-1 dead-peer-detection action ’hold’
set vpn ipsec ike-group ike-grp-1 dead-peer-detection interval ’30’
set vpn ipsec ike-group ike-grp-1 dead-peer-detection timeout ’120’
set vpn ipsec ike-group ike-grp-1 key-exchange ’ikev2’
set vpn ipsec ike-group ike-grp-1 lifetime ’28800’
set vpn ipsec site-to-site peer 192.168.3.2 authentication pre-shared-secret ’mysecret123’
set vpn ipsec site-to-site peer 192.168.3.2 connection-type ’respond’


set vpn ipsec site-to-site peer 192.168.3.2 vti bind ’vti1’
set vpn ipsec site-to-site peer 192.168.3.2 vti esp-group ’esp-grp-1’
commit
save
Router R2 (DM2500)
configure
set interfaces ethernet eth4 mtu ’1500’
set interfaces vti vti1 address ’11.11.11.2/30’
set interfaces vti vti1 mtu ’1400’
set protocols static interface-route 192.168.0.0/16 next-hop-interface ’vti1’
set vpn ipsec site-to-site peer 192.168.3.1 authentication pre-shared-secret ’mysecret123’
set vpn ipsec site-to-site peer 192.168.3.1 vti bind ’vti1’
set vpn ipsec site-to-site peer 192.168.3.1 vti esp-group ’esp-grp-1’
commit
save
Alternatively to IPv4, the IPsec can be configured with IPv6 addressing.
The scenario below will be used to show configuration of the VPN IPSec with IPv6 using VTI interface.
Scenario IPsec with VTI
The procedure below indicates how to execute this configuration:
Router R1 (DM2500)

configure
set interfaces ethernet eth3 address ’2001:f0ca::1/64’
set interfaces ethernet eth4 address ’2001:b0ca::1/64’
set interfaces vti vti2 address ’fc00:1111::1/126’
set protocols static interface-route6 2001:f0ca::/64 next-hop-interface ’vti2’
set vpn ipsec site-to-site peer 2001:b0ca::2 authentication mode ’pre-shared-secret’
set vpn ipsec site-to-site peer 2001:b0ca::2 authentication pre-shared-secret ’mysecret123’
set vpn ipsec site-to-site peer 2001:b0ca::2 connection-type ’respond’
set vpn ipsec site-to-site peer 2001:b0ca::2 default-esp-group ’esp-grp-1’
set vpn ipsec site-to-site peer 2001:b0ca::2 ike-group ’ike-grp-1’
set vpn ipsec site-to-site peer 2001:b0ca::2 local-address ’2001:b0ca::1’
set vpn ipsec site-to-site peer 2001:b0ca::2 vti bind ’vti2’
set vpn ipsec site-to-site peer 2001:b0ca::2 vti esp-group ’esp-grp-1’
commit
save
Router R2 (DM2500)
configure
set interfaces ethernet eth3 address ’2001:ba1a::1/64’
set interfaces ethernet eth4 address ’2001:b0ca::2/64’
set interfaces vti vti2 address ’fc00:1111::2/126’
set protocols static interface-route6 2001:ba1a::/64 next-hop-interface ’vti2’
set vpn ipsec site-to-site peer 2001:b0ca::1 authentication mode ’pre-shared-secret’
set vpn ipsec site-to-site peer 2001:b0ca::1 authentication pre-shared-secret ’mysecret123’
set vpn ipsec site-to-site peer 2001:b0ca::1 connection-type ’initiate’
set vpn ipsec site-to-site peer 2001:b0ca::1 default-esp-group ’esp-grp-1’
set vpn ipsec site-to-site peer 2001:b0ca::1 ike-group ’ike-grp-1’
set vpn ipsec site-to-site peer 2001:b0ca::1 local-address ’2001:b0ca::2’
set vpn ipsec site-to-site peer 2001:b0ca::1 vti bind ’vti2’
set vpn ipsec site-to-site peer 2001:b0ca::1 vti esp-group ’esp-grp-1’
commit
save
The available commands for troubleshooting can be found in the topic Verifying IPsec with VTI.

11.2.5 IPsec Tunnel via LTE Interface
On DM2500 4GT+LTE devices, it is possible to configure the IPSec IPv4 VPN or IPSec IPv4 VPN with Virtual Tunnel Interface
via LTE interface. With the WAN connection configured through the LTE interface, below are the configuration lines to use
the LTE interface as the WAN of the IPSec VPN. The other VPN settings can be used as shown in the previous chapter. In this
case, command line set vpn ipsec site-to-site peer <REMOTE-IP> local-address <LOCAL-IP> it’s not necessary.
Router R1 (DM2500)
configure
set vpn ipsec ipsec-interfaces interface ’wlm0’
set vpn ipsec site-to-site peer 191.247.197.3 wirelessmodem-interface ’wlm0’
commit
Router R2 (DM2500)
configure
set vpn ipsec ipsec-interfaces interface ’wlm0’
set vpn ipsec site-to-site peer 187.71.241.187 wirelessmodem-interface ’wlm0’
commit
The available commands for troubleshooting can be found in the topic Verifying IPsec with VTI.
11.2.6 Dynamic Multipoint IPsec VPNs (DMVPN) Tunnel
DMVPN functionality is the set of Multipoint Generic Routing Encapsulation (mGRE), Next Hop Resolution Protocol (NHRP)
and IPsec (Internet Protocol Security) protocols. The solution uses IPsec to encapsulate mGRE traffic, which in turn is used
to transport data and communicate routing protocols through GRE tunnels. Using these protocols, the hub-and-spoke
topology is created where the hub, or main router, has connection to all spokes and the spokes has only to the hub. The
purpose of the DMVPN is to create dynamic tunnels between the spokes, ensuring encrypted traffic between all elements
of the topology without going through the hub. In the DM2500, phases 2 and 3 are implemented. The difference between
them is that in phase 3 both the tunnels and the routing table will be on demand. This way the spoke will overwrite the
next-hop of the packet and ignore the default route, if any (which could point to the hub).
The scenario below will be used to demonstrate the configuration of a DMVPN phase 2 between a hub and two spokes.

Scenario DMVPN.
DM25-R1
configure
set interfaces ethernet eth3 description ’LAN-R1’
set interfaces ethernet eth1 description ’WAN-INTERNET-R1’
set interfaces tunnel tun0 description ’DMVPN-Tunnel-GRE-R1’
set interfaces tunnel tun0 parameters ip key ’1’
set protocols memory-limit ’100’
set protocols nhrp tunnel tun0 cisco-authentication ’P@ssw0rd’
set protocols nhrp tunnel tun0 holding-time ’90’
set protocols nhrp tunnel tun0 multicast ’dynamic’
set vpn ipsec esp-group ESP-DMVPN compression ’disable’
set vpn ipsec esp-group ESP-DMVPN lifetime ’3600’
set vpn ipsec esp-group ESP-DMVPN mode ’tunnel’
set vpn ipsec esp-group ESP-DMVPN pfs ’disable’
set vpn ipsec esp-group ESP-DMVPN proposal 1 encryption ’aes256’
set vpn ipsec esp-group ESP-DMVPN proposal 1 hash ’sha1’
set vpn ipsec ike-group IKE-DMVPN key-exchange ’ikev1’
set vpn ipsec ike-group IKE-DMVPN lifetime ’28800’
set vpn ipsec ike-group IKE-DMVPN proposal 1 dh-group ’24’
set vpn ipsec ike-group IKE-DMVPN proposal 1 encryption ’aes256’
set vpn ipsec ike-group IKE-DMVPN proposal 1 hash ’sha1’
set vpn ipsec profile NHRPVPN authentication mode ’pre-shared-secret’
set vpn ipsec profile NHRPVPN authentication pre-shared-secret ’P@ssw0rd’
set vpn ipsec profile NHRPVPN bind tunnel ’tun0’
set vpn ipsec profile NHRPVPN esp-group ’ESP-DMVPN’
set vpn ipsec profile NHRPVPN ike-group ’IKE-DMVPN’
commit
DM25-R2
configure

set protocols nhrp tunnel tun0 map 10.0.0.1/16 nbma-address ’200.18.241.10’

set protocols nhrp tunnel tun0 map 10.0.0.1/16 ’register’
set protocols nhrp tunnel tun0 multicast ’nhs’
set vpn ipsec ike-group IKE-DMVPN dead-peer-detection action restart
set vpn ipsec ike-group IKE-DMVPN dead-peer-detection timeout 30
set vpn ipsec ike-group IKE-DMVPN dead-peer-detection interval 15
commit
DM25-R3
configure
commit
To configure the DMVPN phase 3, simply add the configuration line below.
DM25-R1
configure
set protocols nhrp tunnel tun0 redirect
commit

DM25-R2 and DM25-R3
configure
set protocols nhrp tunnel tun0 shortcut
commit
In this way it is possible to establish RIP, OSPF and BGP connections, in addition to configuring static routes between the
hub and the spokes.
DM25-R1
configure
set interfaces tunnel tun0 ip ospf network broadcast
set interfaces tunnel tun0 ip ospf priority 2
commit
DM25-R2
configure
commit
DM25-R3
configure
commit
The available commands for troubleshooting can be found in the topic Verifying DMVPN.
DMVPN with Dynamic Addresses Supporting on Spokes Configuration
DMVPN can be configured so that the spoke WAN interface receives an IP address from a DHCP server. The scenario below
will be used to show this configuration.

DMVPN scenario with DHCP.
DM25-R1
configure
set interfaces ethernet eth3 description ’DMVPN-REDE-LOCAL’
set interfaces ethernet eth1 description ’DMVPN-HUB-UPLINK’
set interfaces tunnel tun0 description ’DMVPN-Tunnel-GRE’
set protocols nhrp tunnel tun0 cisco-authentication ’123abc!@#’
set protocols nhrp tunnel tun0 multicast ’dynamic’
set service dhcp-server disabled ’false’
set service dhcp-server shared-network-name DMVPN-HUB authoritative ’disable’
set service dhcp-server shared-network-name DMVPN-HUB subnet 172.16.0.0/24 lease ’86400’
set service dhcp-server shared-network-name DMVPN-HUB subnet 172.16.0.0/24 start 172.16.0.1 stop ’172.16.0.253’
set vpn ipsec esp-group ESP-DMVPN proposal 1 encryption ’3des’
set vpn ipsec ike-group IKE-DMVPN proposal 1 encryption ’3des’
set vpn ipsec profile NHRP-DMVPN authentication mode ’pre-shared-secret’
set vpn ipsec profile NHRP-DMVPN authentication pre-shared-secret ’123abc!@#’
set vpn ipsec profile NHRP-DMVPN bind tunnel ’tun0’
set vpn ipsec profile NHRP-DMVPN esp-group ’ESP-DMVPN’
set vpn ipsec profile NHRP-DMVPN ike-group ’IKE-DMVPN’
commit
DM25-R2
configure
set interfaces ethernet eth1 address ’dhcp’


set protocols nhrp tunnel tun0 dhcp interface ’eth1’
commit
DM25-R3
configure
set interfaces ethernet eth1 address ’dhcp’
set protocols nhrp tunnel tun0 dhcp interface ’eth1’
commit

The available commands for troubleshooting can be found in the topic Verifying DMVPN.
Verifying IPsec

show vpn ipsec sa
show vpn ipsec sa detail
show vpn ike sa
show vpn ike status
show vpn debug
show log vpn ipsec
show vrf <vrf-name> vpn ipsec sa detail
show vrf <vrf-name> vpn ike sa
Verifying IPsec with VTI
show interfaces vti

show vpn ipsec sa
show vpn debug
show log vpn ipsec

Verifying DMVPN
show vpn ipsec sa

show vpn ipsec state
show vpn debug
show nhrp interface
show nhrp tunnel
show log vpn ipsec
show log nhrp
show vrf <vrf-name> vpn ipsec state
show vrf <vrf-name> nhrp interface
show vrf <vrf-name> nhrp tunnel

DM2500 - Quick Configuration Guide 12 QoS
12 QoS
QoS (Quality of Service) is a set of mechanisms and algorithms used to classify and prioritize traffic. The main objective is
to assure that services that require transmission quality in the network (latency, jitter and bandwidth), for example, voice
over IP (VoIP) and multicast, operate as expected.
This chapter contais the follow sections:
• Rate Limit Configuration
• Classification, priorization and remarking of egress traffic Configuration
• DSCP remarking of ingress traffic Configuration
12.1 Rate Limit Configuration
The Rate limit is the functionality that limits the maximum rate of traffic that an interface or VLAN can sent (out) or received
(in).
The use of Rate Limit is not recommended for bandwidth control with TCP traffic. In this case, the use of
the traffic-policy shaper is recommended, according to examples from the session Traffic classification,
prioritization and remarking.
The scenario below will be used to show configuration of the Rate Limit.
Scenario Rate Limit
The next steps will show how to configure the access to Internet with traffic limited at the input and at the output through
the DM2500 band control mechanisms with asymmetric characteristic from the point of view of user. Considering that the
user would like to obtain the download rate of 50 Mbps and upload of 10 Mbps, using the eth1 interface for the access and
the o uplink in the eth2 Internet with the VLAN 300.
configure
set traffic-policy rate-control WAN_OUT bandwidth 10mbit
set interfaces ethernet eth2 vif 300 traffic-policy out WAN_OUT
set traffic-policy limiter WAN_IN default bandwidth 50mbit
set interfaces ethernet eth2 vif 300 traffic-policy in WAN_IN
commit
A limiter by default does not take into account L2 overhead in traffic limiting. To consider L2 overhead in traffic limiting for
single tagged packets, configure as shown below.

configure
set traffic-policy limiter WAN_IN default bandwidth 50mbit
set traffic-policy limiter WAN_IN default account-layer2-overhead single-tagged
commit
12.2 Classification, priorization and remarking of egress traffic Configuration
12.2.1 Classification and priorization
The classification and prioritization of outgoing traffic are useful to assure that given types of traffic are prioritized to the
detriment of others in situations in which a traffic jam occurs in the outgoing traffic. The scenario below will be used to
show configuration of these mechanisms.
Classification and prioritization
The following configuration classifies packets in four categories, as described below. The packets are routed to eth2 uplink
interface, which is a 10Mbps Internet link.
• Class 2 to control packets and VoIP signaling (SIP). IPv4 packets coming from the eth3 interface with DSCP 26 will
have a reserve of 10% of the bandwidth.
• Class 3 to VoIP media packets (RTP). IPv4 packets coming from the eth3 interface with DSCP 46 will have a reserve of
35% of the bandwidth and maximum of 35% of the bandwidth.
• Class 4 to streaming data. Packets coming from the eth1 interface through the IPv4 10.0.0.25 will have a reserve of
30% of the bandwidth.
• Class default to internet data and other types of traffic. Exceeding packets will be remarked with DSCP 0 (default).
queue-limit parameter defines the buffer size of the shaper class, which can be in either packets or bytes depending
on the type of the queue. The queue size must be properly set according to the service class’ ceiling rate and traffic
characteristics (like packet size, bursty, rate adaptive) to achieve a good latency, and avoid dropping too many packets and

re-transmissions. This value shall be increased as the bandwidth and ceiling are increased. If a service class is not reaching
the configured bandwidth, then it is a good sign to increase the queue size.
The default configuration of queue-type drop-tail has queue-limit 1 in order to prioritize the latency.
priority parameter sets the priority over the shaper classes in relation to the exceeding rate, which is between the bandwidth
and the ceiling. In the following example because all classes are at the same priority the excess traffic will be equality
distributed among the classes.
configure
set traffic-policy shaper WAN_SHAPER bandwidth 10mbit
set traffic-policy shaper WAN_SHAPER class 2 description SIP Traffic
set traffic-policy shaper WAN_SHAPER class 2 match SIP ip dscp 26
set traffic-policy shaper WAN_SHAPER class 2 bandwidth 10%
set traffic-policy shaper WAN_SHAPER class 2 ceiling 100%
set traffic-policy shaper WAN_SHAPER class 2 priority 1
set traffic-policy shaper WAN_SHAPER class 2 queue-type drop-tail
set traffic-policy shaper WAN_SHAPER class 2 queue-limit 100
set traffic-policy shaper WAN_SHAPER class 3 description RTP Traffic

set traffic-policy shaper WAN_SHAPER class 3 match RTP ip dscp 46
set traffic-policy shaper WAN_SHAPER class 3 queue-type drop-tail
set traffic-policy shaper WAN_SHAPER class 3 queue-limit 100
set traffic-policy shaper WAN_SHAPER class 4 description Streaming

set traffic-policy shaper WAN_SHAPER class 4 match IP25 ip source address 10.0.0.25/27
set traffic-policy shaper WAN_SHAPER class 4 queue-type fair-queue
set traffic-policy shaper WAN_SHAPER default description Internet
set traffic-policy shaper WAN_SHAPER default bandwidth 25%
set traffic-policy shaper WAN_SHAPER default ceiling 100%
set traffic-policy shaper WAN_SHAPER default priority 1
set traffic-policy shaper WAN_SHAPER default queue-type fair-queue
set traffic-policy shaper WAN_SHAPER default set-dscp default
set traffic-policy shaper WAN_SHAPER default set-dscp-excess default
set interfaces ethernet eth2 traffic-policy out WAN_SHAPER
commit
The DM2500 does not consider the FCS of the frames as part of the total frame size. Therefore, QoS also does not consider
it during rate calculation. This is important because traffic generators can consider FCS as part of the L2 frame, and a rate
that the generators calculate will be different from the rate configured on a shaper. For the shaper to also consider the FCS,
it is necessary to configure the account-layer2-overhead with the value 4 (Bytes).
configure
set traffic-policy shaper WAN_SHAPER account-layer2-overhead 4
commit
12.2.2 Remarking
It is also possible to remark the DSCP values of the output packet. In the example below, class 3 packets have DSCP
remarked.

set traffic-policy shaper WAN_SHAPER class 3 set-dscp EF
12.2.3 Classifying locally generated packets
To classify and remark packets generated by the DM2500 itself, it is needed to configure a policy to mark the packet with a
tag. In the shaper, a match in that tag is made so the locally generated packet can be classified and remarked. Locally
generated packets include ICMP, ARP, protocol control packets and others.
In the configuration below, packets generated by the DM2500 are marked with tag 5 through the policy local-route. In the
shaper, it is performed a match in mark 5 and the packet DSCP is remarked with value 48 (CS6).
To do not check other policy route rules after a rule has been matched, it is necessary use the mode stop.
set policy route mypolicyroute rule 10 set mark 5

set policy route mypolicyroute rule 10 set mode stop
set traffic-policy shaper WAN_SHAPER class 5 match mypolicyroute mark 5
set traffic-policy shaper WAN_SHAPER class 5 set-dscp cs6
set interfaces ethernet eth2 policy local-route mypolicyroute
12.2.4 Classifying by address or port range
It is possible to classify packets by an address range or port range. Before classification, the packets in the specified ranges
must be marked by a policer in the ingress interface. After that, a shaper can classify the packets in the egress interface.
In to previously presented topology, packets with source address between 10.0.0.1 and 10.0.0.5, and ports between 1000
and 1400 are marked with tag 1 by a policer and then, are classified by a shaper.
set policy route myrange rule 10 source address 10.0.0.1-10.0.0.5

set policy route myrange rule 10 source port 1000-1400
set policy route myrange rule 10 set mark 1
set policy route myrange rule 10 set mode stop
set interface ethernet eth1 policy route myrange
set traffic-policy shaper WAN_SHAPER class 5 match myrange mark 1
set traffic-policy shaper WAN_SHAPER class 5 queue-type fair-queue
Below is the main command available to check the shaper applied in the interfaces. If the user is at configuration level, it is

necessary to use the keyword run before the command.
show queueing
show queueing ethernet <interface>
12.3 DSCP remarking of ingress traffic Configuration
The DSCP markdown of the packets allows the equipment to define a new DSCP priority value based on criteria such as IP
address, transportation protocol (UDP/TCP) or MAC address. This resource can be used to assure that the packet receives
the adequate handling by other network elements after being forwarded by the router.
Considering that the user would like to mark the DSCP 18 (AF21) of the Telnet, SSH and Syslog type packets that ingress in
the eth1 interface through VLAN 200. The procedure below shows how to execute this configuration:
configure
set policy route DSCP-REMARK rule 1 set dscp 18
set policy route DSCP-REMARK rule 1 destination port syslog
set policy route DSCP-REMARK rule 1 protocol udp
set policy route DSCP-REMARK rule 1 set mode stop
set policy route DSCP-REMARK rule 2 destination port telnet
set policy route DSCP-REMARK rule 2 protocol tcp
set policy route DSCP-REMARK rule 3 destination port ssh
set policy route DSCP-REMARK rule 3 protocol tcp_udp
set interfaces ethernet eth1 vif 200 policy route DSCP-REMARK
commit
Below are the main commands available to check the DSCP markdown. If the user is at configuration level, it is necessary
to use the keyword run before the command.
show policy route

show policy route statistics
12.3.1 Configuring the shaper on ingress traffic
To limit ingress traffic with a shaper, it is recommended to use the redirect to the ifb interface on the ethernet interface and
apply the shaper on the input ifb interface.
Suppose the user has already configured a shaper with the name SHAPPER-IN and wants to perform the shaper on the eth1
interface input. The following procedure demonstrates how to perform this configuration:
Shaper association to IFB as Ingress:

set interfaces input ifb1 traffic-policy in SHAPER-IN
Redirection of traffic from an interface to the IFB:

set interfaces ethernet eth1 redirect ifb1
Below is the main command available to check the shaper applied in the interfaces. If the user is at configuration level, it is
necessary to use the keyword run before the command.
show queueing
show queueing input ifb<id>

DM2500 - Quick Configuration Guide 13 Security
13 Security
Maintain the security in the network consists in adopting access policies, monitoring of resources and protection of the
equipment in order to avoid attacks.
This chapter describes how to configure some security functionalities and resources available in the DM2500.
• Configuring the NAT
• Configuring the Firewall
• Verifying Open Sockets
13.1 Configuring the NAT
The NAT (Network Address Translation) has as objective the translation of the internal addresses of a local network for a
public network. In addition of providing security upon hiding details of the stations and devices connected to the internal
network, it also has as objective to mitigate the exhaustion of public IPv4 addresses through reuse of internal addresses.
Configuring the NAT
NAT rules do not act on loopback interfaces.
13.1.1 Source NAT (SNAT)
The SNAT (Source NAT) is the most common form to use the NAT. This functionality changes the source IP address (and
optionally also the TCP/UDP port) of a packet that is routed in the DM2500. The change of IP address occurs after the
decision about the packet routing that has already been executed.
The scenario below will be used to show configuration of the SNAT.

Configuring the SNAT
Considering that the user would like to change the address of a packet of the 10.0.0.0/8 network to a public address
90.80.70.60 and which destination is the eth2 interface.
configure
set nat source rule 10 source address 10.10.0.0/8
set nat source rule 10 translation address 90.80.70.60
set nat source rule 10 outbound-interface eth2
commit
It is possible to use the Symmetric NAT feature that changes the origin TCP/UDP port to a random one. To utilize the
Symmetric NAT feature, use the "translation port" command ass shown below:
configure
set nat source rule 10 translation address 90.80.70.60
set nat source rule 10 translation port ’random’
commit
In an alternative manner, if the public network address is defined dynamically it is possible to use the masquerade
parameter for the translation address. Thus, the NAT will use the eth2 interface address as source address:
configure
set nat source rule 10 translation address masquerade
commit
The available commands for troubleshooting can be found in the topic Verifying NAT.
13.1.2 Destination NAT (DNAT)
The DNAT (Destination NAT), also known as Port Forwarding is a translation mechanism of IP addresses and destination
ports, which has as objective to redirect packets with destination of the public network of an address and port specific for
an internal network. The change of destination address occurs before it is routed internally by the equipment.
The scenario below will be used to show configuration of the DNAT.

Configuring the DNAT
Considering that the user wishes to change the address and destination port of TCP or UDP packets of public network with
90.80.70.60 address and port 80 to the 10.10.10.3 internal address and port 8080 and which source is the eth2 interface.
configure
set nat destination rule 10 destination address 90.80.70.60
set nat destination rule 10 destination port 80
set nat destination rule 10 protocol tcp_udp
set nat destination rule 10 translation address 10.10.0.3
set nat destination rule 10 translation port 8080
set nat destination rule 10 inbound-interface eth2
commit
The available commands for troubleshooting can be found in the topic Verifying NAT.
13.1.3 Verifying NAT
show nat source rules

show nat source statistics
show nat source translations
show nat destination rules
show nat destination statistics
show nat destination translations
clear nat source counters
clear nat destination counters
show vrf <vrf-name> nat source rules
show vrf <vrf-name> nat source statistics
show vrf <vrf-name> nat source translations
show vrf <vrf-name> nat destination rules
show vrf <vrf-name> nat destination statistics
show vrf <vrf-name> nat destination translations
clear vrf <vrf-name> nat source counters
clear vrf <vrf-name> nat destination counters
13.2 Configuring the Firewall
This chapter shows the ACL Firewall and stateful Firewall configuration.

13.2.1 Configuring ACL Firewall
The ACL (Access Control List) Firewall is stateless, in other words, do not consider the TCP state or ICMP and UDP sessions.
ACL Firewall support IPv4 and IPv6 address, also is supported in VRF.
The example of ACL Firewall configuration have a LAN (Local Area Network) or Inside interface and WAN (Wide Area
Network) or Outside interface.
ACL Firewall
The ACL Firewall support three packets direction:
• in: Input packets in interface
• out: Output packets in interface
• local: Packets destined to router
Each interface can have only one rule set in each direction for IPv4 or IPv6 packets.
The available commands for troubleshooting can be found in the topic Verifying Firewall.

Configuring ACL between LAN and WAN
To deny LAN and WAN services should use the in to filter input packets in interface and out to filter output packets in
interface.
Example to deny SMTP and SMTPs services from WAN by any IPv4 or IPv6 address, other services are allowed:
configure
set firewall name BLOCK_IPV4_SERVICES default-action accept
set firewall name BLOCK_IPV4_SERVICES rule 1 action drop
set firewall name BLOCK_IPV4_SERVICES rule 1 destination port smtp
set firewall name BLOCK_IPV4_SERVICES rule 1 protocol tcp
set firewall name BLOCK_IPV4_SERVICES rule 2 action drop
set firewall name BLOCK_IPV4_SERVICES rule 2 destination port smtps
set firewall name BLOCK_IPV4_SERVICES rule 2 protocol tcp
set firewall ipv6-name BLOCK_IPV6_SERVICES default-action accept
set firewall ipv6-name BLOCK_IPV6_SERVICES rule 1 action drop
set firewall ipv6-name BLOCK_IPV6_SERVICES rule 1 destination port smtp
set firewall ipv6-name BLOCK_IPV6_SERVICES rule 1 protocol tcp
set firewall ipv6-name BLOCK_IPV6_SERVICES rule 2 action drop
set firewall ipv6-name BLOCK_IPV6_SERVICES rule 2 destination port smtps
set firewall ipv6-name BLOCK_IPV6_SERVICES rule 2 protocol tcp
commit
To apply the IPv4 and IPv6 rule set in WAN interface (eth4) use the commands below:
configure
set interfaces ethernet eth4 firewall in name BLOCK_IPV4_SERVICES
set interfaces ethernet eth4 firewall in ipv6-name BLOCK_IPV6_SERVICES
commit
Below are the main commands available to check this feature. If the user is at configuration level, it is necessary to use the
keyword run before the command.
show firewall summary

show firewall statistics
Configuring the management ACL
To deny packets destined to router will be used the local direction. The management services or routing protocols are
examples of services filtered by local.
Example to allow access to services below from LAN and WAN, other services are denied:
• SNMP: rule 1 to allow packets for get/set SNMP OIDs.
• Telnet: rule 2 to allow Telnet packets.
• SSH: rule 3 to allow SSH packets.

• Tacacs: rule 4 to allow Tacacs packets.
• OSPF: rule 5 to allow OSPF packets.
• SNMP Traps: It is not necessary create a rule due not exists packet destined to the equipment.
• Syslog: It is not necessary create a rule due not exists packet destined to the equipment.
configure
set firewall name IPV4_MGMT default-action drop
set firewall name IPV4_MGMT rule 1 action accept
set firewall name IPV4_MGMT rule 1 destination port snmp
set firewall name IPV4_MGMT rule 1 protocol udp
set firewall name IPV4_MGMT rule 2 destination port telnet
set firewall name IPV4_MGMT rule 2 protocol tcp
set firewall name IPV4_MGMT rule 3 destination port ssh
set firewall name IPV4_MGMT rule 3 protocol tcp
set firewall name IPV4_MGMT rule 4 action ’accept’
set firewall name IPV4_MGMT rule 4 protocol ’tcp’
set firewall name IPV4_MGMT rule 4 source port ’tacacs’
set firewall name IPV4_MGMT rule 5 action ’accept’
set firewall name IPV4_MGMT rule 5 protocol ’ospf’
set firewall ipv6-name IPV6_MGMT default-action drop
set firewall ipv6-name IPV6_MGMT rule 1 action accept
set firewall ipv6-name IPV6_MGMT rule 1 destination port snmp
set firewall ipv6-name IPV6_MGMT rule 1 protocol udp
set firewall ipv6-name IPV6_MGMT rule 2 destination port telnet
set firewall ipv6-name IPV6_MGMT rule 2 protocol tcp
set firewall ipv6-name IPV6_MGMT rule 3 destination port ssh
set firewall ipv6-name IPV6_MGMT rule 3 protocol tcp
set firewall ipv6-name IPV6_MGMT rule 4 action ’accept’
set firewall ipv6-name IPV6_MGMT rule 4 protocol ’tcp’
set firewall ipv6-name IPV6_MGMT rule 4 source port ’tacacs’
set firewall ipv6-name IPV6_MGMT rule 5 action ’accept’
set firewall ipv6-name IPV6_MGMT rule 5 protocol ’ospf’
commit
To apply the MGMT rule set in LAN interface (eth1) and Wan interface (eth4) use the commands below:
configure
set interfaces ethernet eth1 firewall local name IPV4_MGMT
set interfaces ethernet eth4 firewall local name IPV4_MGMT
set interfaces ethernet eth1 firewall local ipv6-name IPV6_MGMT
set interfaces ethernet eth4 firewall local ipv6-name IPV6_MGMT
commit
Configuring ACLs by groups
The ACL Firewall supports the creation of groups eliminating the need to create a rule for each network, address or ports
making the configuration simple. Using the groups to manipulate these informations the configuration is done in groups

and not more in rules.
Using the Configuring the management ACL session as example is possible to change the rules to allow services only from
LAN networks in rules 1 to 4 and from WAN network in rule 5.
configure
set firewall group network-group IPV4_LAN_NETWORK network ’192.168.0.0/24’
set firewall group network-group IPV4_LAN_NETWORK network ’172.22.0.0/16’
set firewall group network-group IPV4_WAN_NETWORK network ’1.0.0.0/30’
set firewall name IPV4_MGMT rule 1 source group network-group ’IPV4_LAN_NETWORK’
set firewall name IPV4_MGMT rule 5 source group network-group ’IPV4_WAN_NETWORK’
set firewall group ipv6-network-group IPV6_LAN_NETWORK network ’2001:db8:AAAA::/64’
set firewall group ipv6-network-group IPV6_LAN_NETWORK network ’2001:db8:BBBB::/64’
set firewall group ipv6-network-group IPV6_WAN_NETWORK network ’2001::1/64’
set firewall ipv6-name IPV6_MGMT rule 1 source group ipv6-network-group ’IPV6_LAN_NETWORK’
set firewall ipv6-name IPV6_MGMT rule 5 source group ipv6-network-group ’IPV6_WAN_NETWORK’
commit
13.2.2 Configuring the stateful Firewall
Stateful Firewall supports IPv4 and IPv6 address, also is supported in VRFs.
To do the same configuration showed in this chapter for IPv6 address it is necessary change the name to
ipv6-name in all configurations.
The example of stateful Firewall configuration have three tipical zones, LAN (Local Area Network) or Inside, WAN (Wide Area
Network) or Outside and DMZ (Demilitarized Zone).

Stateful Firewall
The stateful firewall use the TCP connection state to take an action over packets. The established are connections
previously established, for example an answer packet. The related are packets related to an existent connection, for
example: an ICMP IPv4 that is related to a connection, but it is not part of TCP connection, and invalid state are related to
invalid TCP connections, for example: an ICMP IPv4 related to inexistent connections.
The stateful Firewall also consider ICMP and UDP sessions althought they are connectionless protocols. Upon receiving a
first packet, a new connection is considered and after a timeout the connection is considered closed.
Configuring the Zone-Based Firewall
The configuration below apply the default action to drop in three zones. All the traffic flowing between the three zones will
be silent discarded.
configure
set firewall name DMZ-TO-LAN default-action ’drop’
set firewall name DMZ-TO-WAN default-action ’drop’
set firewall name LAN-TO-DMZ default-action ’drop’
set firewall name LAN-TO-WAN default-action ’drop’
set firewall name WAN-TO-DMZ default-action ’drop’
set firewall name WAN-TO-LAN default-action ’drop’
set zone-policy zone DMZ default-action ’drop’
set zone-policy zone DMZ from LAN firewall name ’LAN-TO-DMZ’
set zone-policy zone DMZ from WAN firewall name ’WAN-TO-DMZ’
set zone-policy zone DMZ interface ’eth2’
set zone-policy zone LAN default-action ’drop’
set zone-policy zone LAN from DMZ firewall name ’DMZ-TO-LAN’
set zone-policy zone LAN from WAN firewall name ’WAN-TO-LAN’
set zone-policy zone LAN interface ’eth1’
set zone-policy zone WAN default-action ’drop’
set zone-policy zone WAN from DMZ firewall name ’DMZ-TO-WAN’
set zone-policy zone WAN from LAN firewall name ’LAN-TO-WAN’
set zone-policy zone WAN interface ’eth4’
commit

Allowing services in the Zone-Based Firewall
Example to allow access the Web (HTTPs) and E-mail (POP3 and SMTP) services in DMZ servers from LAN and WAN:
Due to configuring the zones default action to drop, any packets related to other services will be discarded.
configure
set firewall name LAN-TO-DMZ rule 1 action ’accept’
set firewall name LAN-TO-DMZ rule 1 state ’established enable’
set firewall name LAN-TO-DMZ rule 1 state ’related enable’
set firewall name LAN-TO-DMZ rule 2 action ’drop’
set firewall name LAN-TO-DMZ rule 2 state ’invalid enable’
set firewall name LAN-TO-DMZ rule 3 state ’new enable’
set firewall name LAN-TO-DMZ rule 3 destination port ’https’
set firewall name LAN-TO-DMZ rule 3 protocol ’tcp’
set firewall name LAN-TO-DMZ rule 4 destination port ’pop3s’
set firewall name LAN-TO-DMZ rule 5 destination port ’smtps’
set firewall name DMZ-TO-LAN rule 1 action ’accept’
set firewall name DMZ-TO-LAN rule 1 state ’established enable’
set firewall name DMZ-TO-LAN rule 1 state ’related enable’
set firewall name DMZ-TO-LAN rule 2 action ’drop’
set firewall name DMZ-TO-LAN rule 2 state ’invalid enable’
set firewall name WAN-TO-DMZ rule 1 action ’accept’
set firewall name WAN-TO-DMZ rule 1 state ’established enable’
set firewall name WAN-TO-DMZ rule 1 state ’related enable’
set firewall name WAN-TO-DMZ rule 2 action ’drop’
set firewall name WAN-TO-DMZ rule 2 state ’invalid enable’
set firewall name WAN-TO-DMZ rule 3 state ’new enable’
set firewall name WAN-TO-DMZ rule 3 destination port ’https’
set firewall name WAN-TO-DMZ rule 3 protocol ’tcp’
set firewall name WAN-TO-DMZ rule 4 destination port ’pop3s’
set firewall name WAN-TO-DMZ rule 5 destination port ’smtps’
set firewall name DMZ-TO-WAN rule 1 action ’accept’
set firewall name DMZ-TO-WAN rule 1 state ’established enable’
set firewall name DMZ-TO-WAN rule 1 state ’related enable’
set firewall name DMZ-TO-WAN rule 2 action ’drop’
set firewall name DMZ-TO-WAN rule 2 state ’invalid enable’
commit
Example to allow access the Web (HTTP and HTTPs) services in WAN "Internet" from LAN:
configure
set firewall name LAN-TO-WAN rule 1 action ’accept’
set firewall name LAN-TO-WAN rule 1 state ’established enable’
set firewall name LAN-TO-WAN rule 1 state ’related enable’
set firewall name LAN-TO-WAN rule 2 action ’drop’
set firewall name LAN-TO-WAN rule 2 state ’invalid enable’
set firewall name LAN-TO-WAN rule 3 state ’new enable’

set firewall name LAN-TO-WAN rule 3 destination port ’http’

set firewall name LAN-TO-WAN rule 3 protocol ’tcp’
set firewall name LAN-TO-WAN rule 4 state ’new enable’
set firewall name LAN-TO-WAN rule 4 destination port ’https’
set firewall name LAN-TO-WAN rule 4 protocol ’tcp’
set firewall name WAN-TO-LAN rule 1 action ’accept’
set firewall name WAN-TO-LAN rule 1 state ’established enable’
set firewall name WAN-TO-LAN rule 1 state ’related enable’
set firewall name WAN-TO-LAN rule 2 action ’drop’
set firewall name WAN-TO-LAN rule 2 state ’invalid enable’
commit
Configuring the Firewall in management
To protect the management traffic, i.e. the packets that are sent by or received by the DM2500 it is necessary to create a
zone with local-zone option.
In the example below is used the MGMT (management) zone with local-zone option:
configure
set zone-policy zone MGMT default-action ’drop’
set zone-policy zone MGMT local-zone
set zone-policy zone MGMT from LAN firewall name ’LAN-TO-MGMT’
set zone-policy zone MGMT from WAN firewall name ’WAN-TO-MGMT’
set zone-policy zone MGMT from DMZ firewall name ’DMZ-TO-MGMT’
commit
Allowing services in MGMT zone
Example to allow acess to the equipment management by SSH from any LAN IP address and OSPF from any WAN IP
address:
configure
set firewall name LAN-TO-MGMT rule 1 action ’accept’
set firewall name LAN-TO-MGMT rule 1 state ’established enable’
set firewall name LAN-TO-MGMT rule 1 state ’related enable’
set firewall name LAN-TO-MGMT rule 2 action ’drop’
set firewall name LAN-TO-MGMT rule 2 state ’invalid enable’
set firewall name LAN-TO-MGMT rule 3 action ’accept’
set firewall name LAN-TO-MGMT rule 3 state ’new enable’
set firewall name LAN-TO-MGMT rule 3 destination port ’ssh’
set firewall name LAN-TO-MGMT rule 3 protocol ’tcp’

set firewall name WAN-TO-MGMT rule 1 action ’accept’

set firewall name WAN-TO-MGMT rule 1 state ’established enable’
set firewall name WAN-TO-MGMT rule 1 state ’related enable’
set firewall name WAN-TO-MGMT rule 2 action ’drop’
set firewall name WAN-TO-MGMT rule 2 state ’invalid enable’
set firewall name WAN-TO-MGMT rule 3 action ’accept’
set firewall name WAN-TO-MGMT rule 3 state ’new enable’
set firewall name WAN-TO-MGMT rule 3 protocol ’ospf’
set firewall name DMZ-TO-MGMT rule 1 action ’accept’
set firewall name DMZ-TO-MGMT rule 1 state ’established enable’
set firewall name DMZ-TO-MGMT rule 1 state ’related enable’
set firewall name DMZ-TO-MGMT rule 2 action ’drop’
set firewall name DMZ-TO-MGMT rule 2 state ’invalid enable’
commit
13.2.3 Firewall protections
The Firewall support some global protections, that is, the action is valid to all configured zones.
By default only ICMP IPv4 send redirects are enabled, but it is possible to enable other protections if
necessary.
ICMP IPv4 Ping broadcast
To answer ICMP (Internet Control Message Protocol) IPv4 broadcast packets received:
configure
set firewall broadcast-ping enable
commit
To not answer the ICMP IPv4 broadcast received:

configure
set firewall broadcast-ping disable
commit
ICMP IPv4 redirect
To enable processing of IPv4 ICMP redirect received:
configure
set firewall receive-redirects enable
commit
To disable processing of IPv4 ICMP redirect received:

configure
set firewall receive-redirects disable
commit
To enable sending IPv4 ICMP redirect:
configure
set firewall send-redirects enable
commit
To disable sending IPv4 ICMP redirect:
configure
set firewall send-redirects disable
commit
IPv4 Source Routing
The IPv4 packet has an option to carry information about the path that it must follow to its destination.
To enable the processing of IPv4 packets that contains source-routing options:
configure
set firewall ip-src-route enable
commit
To disable the processing of IPv4 packets that contains source-routing options:
configure
set firewall ip-src-route disable
commit
RPF
The RPF (Reverse Patch Forwarding) is defined in RFC3074. The strict mode check if the equipment has a route to the
source IP address of the received packet through the same interface were the packet was received. If not the packet is
discarded:
configure
set firewall source-validation strict
commit
The RPF in loose mode check if source IP address received has a route in equipment. If not the packet is discarded:
configure
set firewall source-validation loose
commit
It is possible disable the RPF checking:
configure
set firewall source-validation disable
commit

13.2.4 Verifying Firewall
show firewall summary

show firewall statistics
show firewall group
show zone-policy
show conntrack table ipv4
show conntrack table ipv6
clear firewall
clear firewall ipv6-name
clear firewall name
show vrf <vrf-name> firewall summary
show vrf <vrf-name> firewall statistics
show vrf <vrf-name> firewall group
show vrf <vrf-name> zone-policy
show vrf <vrf-name> conntrack table ipv4
show vrf <vrf-name> conntrack table ipv6
clear vrf <vrf-name> firewall
clear vrf <vrf-name> firewall ipv6-name
clear vrf <vrf-name> firewall name
13.3 Verifying Open Sockets
The command show tcp brief prints information about open sockets in the DM2500.
dm2500:~$ show tcp brief

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 :::23 :::* LISTEN
dm2500:~$
13.4 802.1X Configuration
The IEEE 802.1X (dot1x) standard aims to control port-based device authentication and authorization. Thus avoiding
unauthorized access to the network. The basics steps for configuring starts with defining a RADIUS server for authentication.
Support for configuring 2 RADIUS servers for autentication.
configure
set system dot1x server 1 authentication address 192.168.1.1
set system dot1x server 1 authentication secret pass123
commit
Port authorization via dot1x can be applied to a physical interface, bonding or a logical bridge interface.

13.4.1 Enabling dot1x on ethernet/bonding interfaces
To enable dot1x on a Ethernet interface, follow the steps below:
configure
set interfaces ethernet eth1 ’dot1x’
set interfaces ethernet eth1 dot1x max-users 10
commit
To enable dot1x on a bonding interface, follow the steps below:
configure
set interfaces bonding bond8 ’dot1x’
set interfaces bonding bond8 dot1x max-users 10
commit
For the creation of the bonding interface, check the section Bonding Interface (Aggregation) Configuration.
The command set interfaces ethernet eth1 dot1x max-users 10 is used to define how many simultaneous authenticated
users are accepted on the interface. The same applies to bonding and bridge interfaces.
The available commands for troubleshooting can be found in the topic Verifying dot1x
13.4.2 Enabling dot1x on bridge interfaces
For the creation of the bridged interface, check the section Bridge Interface Configuration
To enable dot1x on a bridged interface, follow the steps below:
configure
set interfaces bridge br1 ’dot1x’
set interfaces bridge br1 group-forward-mask eap
set interfaces bridge br1 dot1x max-users 10
commit
The command set interfaces bridge br1 dot1x max-users 10 is used to define how many simultaneous authenticated
users are accepted on the interface.
The available commands for troubleshooting can be found in the topic Verifying dot1x

13.4.3 Verifying dot1x
Below are the main commands available to check the dot1x feature. If the user is at the config level, the usage of the
keyword run before the command is required.
show log dot1x

show log dot1x all
show log dot1x tail

DM2500 - Quick Configuration Guide Legal Note
Legal Note
In spite the fact that all the precautions were taken in development of the present document, DATACOM shall not be held
responsible for eventual errors or omissions as well as no obligation is assumed due to damages resulting from the use of
the information included in this guide. The specifications provided in this manual shall be subject to changes with no prior
notification and are not acknowledged as any type of contract.
© 2023 DATACOM - All rights reserved.
Warranty
DATACOM’s products are covered by a warranty against manufacturing defects during a minimum period of 12 (twelve)
months including the legal term of 90 days, as from the date of issue of the supply Nota Fiscal (Invoice).
Our warranty is standard counter warranty, this means, for exercise of the warranty, the customer should send the product
to DATACOM Authorized Technical Assistance with paid freight. The return freight of the equipment will be DATACOM
responsibility.
To obtain additional information, see our warranty policy in https://www.datacom.com.br/en.
Telephone Number: +55 51 3933-3094

Datacom 2500

Uploaded by

Copyright:

Available Formats

Datacom 2500

Uploaded by

Document Information

Original Description:

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

Datacom 2500

Uploaded by

Copyright:

Available Formats

ACCESS ROUTERS

QUICK CONFIGURATION GUIDE

204.4305.14 - February 17, 2023

Access to the DmSupport can be made through link: https://supportcenter.datacom.com.br

Telephone Number: +55 51 3933-3122

Rua América, 1000

92990-000 - Eldorado do Sul - RS - Brazil

DATACOM 204.4305.14 - February 17, 2023 2

• Datasheet - Provides the Hardware and Software technical characteristics of product

• Installation Guide - Provides instructions on the procedures covering product installation

DATACOM 204.4305.14 - February 17, 2023 3

Introduction to the document

About this Document

Icon Type Description

DATACOM 204.4305.14 - February 17, 2023 4

Icon Type Description

Warning Non-ionizing radiation emission.

Indicates that equipment, or a part is ESDS (Electrostatic Discharge Sensitive). It should

DATACOM 204.4305.14 - February 17, 2023 5

Introduction to the document 4

DATACOM 204.4305.14 - February 17, 2023 6

2.6 Summertime Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

DATACOM 204.4305.14 - February 17, 2023 7

DATACOM 204.4305.14 - February 17, 2023 8

9.3 DHCPv4 Relay Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

DATACOM 204.4305.14 - February 17, 2023 9

10.7.4 Verifying BGP IPv4 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

DATACOM 204.4305.14 - February 17, 2023 10

11.2.2 Site-to-site IPsec IPv6 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Legal Note 152

DATACOM 204.4305.14 - February 17, 2023 11

1.1 First Login

1.1.1 Installing and energizing the equipment

Please check the detailed instructions in the equipment Installation Guide.

1.1.2 Accessing the equipment using the console port

Accessing the equipment using the console port

1.1.3 Accessing the equipment using a ethernet port

Accessing the equipment using an Ethernet port

DATACOM 204.4305.14 - February 17, 2023 12

1.1.4 Accessing the equipment for the first time

dm2500 login: admin

1.2 Firmware Management

1.2.1 Firmware Update

dm2500:~$ show firmware

firmware add tftp://172.22.107.11/pd3701-1.4.4.swu

DATACOM 204.4305.14 - February 17, 2023 13

An automatic reboot will occur after the firmware update procedure.

1.3 CLI Overview

DM2500 CLI supports the configuration and operational.

1.3.1 Operational Mode

show inventory Show equipment inventory

show environment Shows value of temperature sensors

show psu Shows power supply status

DATACOM 204.4305.14 - February 17, 2023 14

show firmware Shows firmware version

show configuration Shows current configuration of the equipment

show system cpu-utilization Shows CPU utilization

show system memory Shows memory usage

show system uptime Shows equipment uptime