Big Switch Installation

BIG SWITCH NETWORKS
VENDOR INTEGRATION SERIES

BIG MONITORING FABRIC (BMF)
VERSION 1.0
Table of Contents
Executive Summary......................................................................................................................... 2
Big Monitoring Fabric (BMF) Overview .......................................................................................... 3
Basic BMF Installation Steps ........................................................................................................... 3
1. Install BMF Controller .......................................................................................................... 3
2. Configure IPAM on BMF Controller ..................................................................................... 5
3. Configure BMF Switch Details on the BMF Controller ......................................................... 5
4. Install BMF Switch ................................................................................................................ 5
5. Verify BMF Switch Config ..................................................................................................... 7
DefensePro Overview ..................................................................................................................... 8
DefenseFlow Overview ................................................................................................................... 9
Server Custom Operations (SCO) Overview.................................................................................... 9
Use Cases ...................................................................................................................................... 14
Use Case 1: BMF Inline DefensePro SMARTap L2 diversion ............................................... 14
©2019 Radware Ltd. All rights reserved. Radware and all other Radware product and service names are registered
trademarks or trademarks of Radware in the U.S. and other countries. All other trademarks and names are property of
their respective owners. The Radware products and solutions mentioned in this document are protected by trademarks,
patents and pending patent applications. For more details please see: https://www.radware.com/LegalNotice/
BIG SWITCH NETWORKS
VERSION 1.0
Executive Summary
As the industry shifts to Software Defined Networking (SDN), the need for security solutions to
integrate into SDN environments has become more prevalent. This document will cover several
use cases on how to integrate the Radware Security Stack with Big Switch Networks Big
Monitoring Fabric (BMF) SDN environment.
This document will cover several use cases for BMF integration with the Radware Security
Stack. However, this document will NOT cover technical deployment options such as BMF High
Availability, LAGs, Tunnels, Controller VIPs, etc. For those and other specific deployment
options, please refer to the BMF Deployment Guide.
This document assumes the reader has a basic understanding of all the Radware components
and how to install them and thus will NOT cover the basic deployment of the Radware solution
elements. This document will cover specific configuration requirements of each component for
each use case. Please refer to the appropriate Radware Deployment Guides for basic
installation.
• DefensePro Installation Guide
• DefenseFlow Installation Guide
• APSolute Vision Installation Guide
BIG SWITCH NETWORKS
VERSION 1.0
Big Monitoring Fabric (BMF) Overview

BMF Inline deployments provide the centralizing fabric needed for organizations to rollout a
consistent, organization-wide DMZ security posture. Security teams now have a single pane
interface to build and manage security tool chains. Multiple active tools can be deployed
logically inline, in defined sequence, and receive only the traffic of interest to each. Other non-
security tools, such as web-proxies, can also take advantage of BMF Inline for rapid, non-
intrusive inline deployment.
Big Mon Out-of-Band offers the functionality of a traditional Network Packet Broker (NPB) –
receiving traffic from TAPs and SPAN ports and delivering to tools – with the added capabilities
and advantages of a true software-defined networking (SDN) architecture. All traffic delivery
rules, including packet aggregation and filtering, advanced packet handling, and flow
generation are programmed through the controller. Tools can be centrally located, policies can
be uniformly rolled out, and troubleshooting can be done with a few clicks. No need to
manually map traffic to each tool. Tool policies set at the controller automatically map the right
traffic to the right tool at the right time.
All service chaining rules, including filtering, tool delivery sequence, and terabit-scale blocking,
are programmed through the controller. Change management is simplified, as tool
configuration changes can be made in software, without impacting network uptime.
Basic BMF Installation Steps
This document will outline the basic steps to install a BMF Controller in the same broadcast
domain as the BMF Switch to allow for Zero Touch Fabric installation of the BMF Switches that
reside in the that same L2 domain as the BMF Controller. For L3 deployment or other
installation options please refer to the BMF installation Guide referred to above.
1. Install BMF Controller
The BMF controller can be deployed as a hardware appliance, a one-RU hardware device
containing pre-loaded software, or as a Virtual Machine (VM). This guide will cover
deployment as a VM. Please refer to the BMF Deployment Guide for VM minimum
requirements.
When you power on the VM for the BMF Controller
• Connect to the VM console
• Press Enter to begin the installation of the “First Boot Script”
• Login as admin (no password)
BIG SWITCH NETWORKS
VERSION 1.0
• Accept EULA
• Set recovery password
• Choose IP Forwarding mode
• Set IP Method to Manual

• Specify Management IP and optional information
• Specify Controller Name, Description and set the password. Select 1 for the active
controller
• Specify NTP servers
• The system completes the installation and displays the menu. Select 1 to apply the
settings
• Verify Controller State by entering “show controller details” at the CLI
BIG SWITCH NETWORKS
VERSION 1.0
2. Configure IPAM on BMF Controller

Configure IPAM on the BMF Controller for the BMF Switches, deployed on the same broadcast
domain, to obtain an IP Address and a configuration file from the BMF Controller via ZTF
3. Configure BMF Switch Details on the BMF Controller

Configure each BMF Switch Name and Mac address on the BMF Controller. This is how the
BMF Controller will “know” how to communicate and push OS Lite and a configuration file to
the BMF Switches through ZTF
4. Install BMF Switch

Fabric switch installation can be completed in one of the following two modes.
BIG SWITCH NETWORKS
VERSION 1.0
Zero Touch Fabric (ZTF) Layer 2 (Auto-discovery switch deployment mode): In this mode, which
is the default, ZTF automatically downloads and installs the appropriate Switch Light OS image
from the BMF controller. This method of installation requires that all the fabric switches and
the BMF controller are in the same Layer 2 network (IP subnet). Also, if the fabric switches
require IPv4 addresses to communicate with SNMP or other external services, you must
configure IPAM, which provides the controller with a range of IPv4 addresses to allocate to the
fabric switches.
Layer 3 (Preconfigured switch deployment mode): This mode allows fabric switches to be in a
different Layer 2 network than the controller. ZTF cannot be used, and you must log in to each
switch individually to either manually install the correct Switch Light OS for your controller or
use DHCP to automatically download the software to each controller. This mode requires that
communication between the controller and the fabric switches occurs using IPv4 addresses,
and no IPAM configuration is required.
NOTE: All the fabric switches in a single fabric must be installed using the same mode. If you
have any fabric switches in a different IP subnet than the controller, you must use Layer 3 mode
for installing all the switches, even those in the same Layer 2 network as the controller.
Installing switches in mixed mode, with some switches using ZTF in the same Layer 2 network as
the controller, while other switches in a different subnet are installed manually or using DHCP is
unsupported.
ZTF Installation
When using ZTF, the BMF controllers and fabric switches use IPv6 for communication. However,
to SSH to the switch directly, you must configure IP address management (IPAM), which assigns
an IPv4 address to the switch from the pool of addresses you assign. Also, regardless of how the
switch is installed, IPAM is required to allocate IPv4 addresses to fabric switches for
communicating with external services that may not support IPv6, including NTP, SNMP, and
syslog. To allocate a pool of IPv4 addresses and configure the DNS server and default gateway,
complete the following steps
• Connect to the BMF Switch Console port
• Power ON or Restart the BMF Switch
• On the GNU GRUB Menu select ONIE
NOTE: To get to the ONIE mode, during the reboot countdown, press any key when you see
the prompt: “Hit any key to stop autoboot: 0”. The following command takes you to the
ONIE install mode:
BIG SWITCH NETWORKS
VERSION 1.0
• Select ONIE. This puts the BMF switch into the installer mode, and the rest of the process is
performed automatically.
• The BMF Controller will upgrade the OS Lite software, assign an IP address as well as other
configuration details to the BMF switch via ZTF.
5. Verify BMF Switch Config
You can verify the BMF Switch Config from either the BMF Controller or BMF switch.
Verify from the BMF Controller
• Show switch <switch name> details
• Show switch <switch name> zerotouch
Verify from the BMF Switch

You can log in to the BMF switch and enter the show command to display the switch status,
when you see the following prompt
BIG SWITCH NETWORKS
VERSION 1.0
DefensePro Overview
DefensePro is part of Radware’s Attack Mitigation Solution and is an award-winning, real-time,
perimeter attack mitigation device that secures organizations against emerging network and
applications threats. DefensePro protects the infrastructure against network and application
downtime (or slow time), application vulnerability exploitation, malware spread, network
anomalies, information theft and other types of attacks.
DefensePro provides the industry’s most advanced, automated protection from fast-moving
threats, including from recent IoT-based attacks such as Mirai. It is uniquely built to overcome
both the complexity and scale of today’s sophisticated IoT-based botnets. DefensePro also
helps organizations win the ongoing security battle against availability attacks, by detecting and
mitigating known and zero-day DoS/DDoS attacks in real-time. It protects against other security
threats that are usually undetected by traditional DDoS mitigation tools such as burst attacks,
DNS attacks, encrypted flood attacks, attacks on login pages and attacks behind CDNs.
DefensePro includes a comprehensive set of essential security modules – Anti DDoS, network
behavioral analysis (NBA), intrusion prevention system (IPS), access control, rate-limiters,
keyless encrypted attack protection and Threat Intelligence - to fully protect the infrastructure
against known and emerging network security attacks. It employs multiple detection and
mitigation modules, including adaptive behavioral analysis, challenge response technologies
and signature detection.
• Behavioral Analysis engine dynamically learns traffic patterns and automatically mitigates
attacks in real-time such as BURTS ATTACKS and DNS AMPLIFICATION ATTACKS such as the
Mirai Bot Net
• Challenge & Response mechanisms validates the good guys from the bad guys through a
series of escalated challenges in order to further weed out false positives. Think of this as
your countermeasures.
• Access Controls are well known security measures DefensePro employs to perform such
actions as rate limiting, connection limits, white lists and blacklists.
• Known Vulnerabilities – The DefensePro carries a local IPS signature database to prevent
against well-known attacks
• Threat Intelligence – DefensePro receives real-time threat intelligence from Radware’s
Cloud Infrastructure and Deception Network which was built from the ground up.
Effectively the DefensePro receives a feed on the bad actors that are attacking at that
moment in time so the DefensePro can block them immediately.
For more information on DefensePro please refer to the following webpage
https://www.radware.com/products/defensepro
BIG SWITCH NETWORKS
VERSION 1.0
DefenseFlow Overview
DefenseFlow is a software product that sits in the control plane and acts as a cyber security
gateway. DefenseFlow can consume/relay control & telemetry protocols such as BGP,
FlowSpec, NetFlow, syslogs, REST and so on.
DefenseFlow is an orchestration system which unifies the Radware mitigation ecosystem
through automation, custom operations and workflows.
DefenseFlow uses automated workflows to perform a workflow of security actions specific to
business SLAs. DefenseFlow can receive an alert or trigger from any detector. Once
DefenseFlow consumes a trigger it will perform any action that you define. This action could be
a custom action or predefined list of actions embedded in the system. DefenseFlow can
perform multiple operations as well whenever a set or custom condition is met such as divert
via BGP, RTBH or Flowspec.
To integrate other vendor environments into the Radware mitigation ecosystem, DefenseFlow
implements the concept of Custom Operations. Custom Operations are capable of triggering
events externally to DefenseFlow. Custom Operations can be written in any programming
language therefore allowing the integration of virtually any 3rd party vendor to be controlled
programmatically via DefenseFlow.
For more information on DefenseFlow please refer to the following webpage
https://www.radware.com/products/defenseflow
Server Custom Operations (SCO) Overview

SCO is a custom http server developed by Radware. The SCO application enables the extension
of the Radware ecosystem into SDN and 3rd party vendor solutions. SCO can be deployed
independently or installed directly on DefenseFlow. For this use case SCO will be installed
directly on DefenseFlow. SCO translates a JSON object from a DefenseFlow Custom Operation
into a REST API call to the BigSwitch controller. The REST API call updates the BMF controller to
remove attack traffic from the copy port of the BMF Switch thus preventing duplication of
traffic.
The SCO application is written in PHP and can be deployed to any host that supports PHP. Both
the webserver and its REST API connection with BigSwitch are written in PHP. As stated
previously for the sake of the following use cases SCO will be installed directly on to
DefenseFlow.
SCO Features
BIG SWITCH NETWORKS
VERSION 1.0
• Supports API calls to multiple BMF controllers

• Supports API calls to multiple Vision servers
• Status messages relayed to the Vision message console as events occur
• Supports syslog to multiple syslog listeners as events occur
• Stores Vision, DefenseFlow and BMF credentials in encrypted format
• Implements a watchdog which keeps SCO alive and reports eventual failures
• Implements a scotag* control to prevent triggering of the wrong Custom Operation
• Can be implemented inside the DefenseFlow host machine
SCO High Availability

SCO supports DefenseFlow HA deployments by having a copy of SCO installed on each
DefenseFlow host. Only the active DefenseFlow instance will use SCO to communicate to the
active BMF Controller until there is a fail over.
SCO supports BMF HA by periodically checking the role of the BigSwitch controller thus
delivering control rules only to the active BMF controller.
Installing SCO
SCO can be deployed either on the DefenseFlow host or any external Linux VM. This document
will outline the installation of SCO on the DefenseFlow host.
• Create folder named SCO.
o md /root/SCO
• Change to the SCO directory
o cd root/SCO
• Extract tar inside of the SCO folder
o tar -xvf SCO_113.tar
• Change to the Server directory
o cd server
• Edit sco_config.json accordingly
Edit SCO JSON

• Ensure debug, emulation and log_unused are set to false for production use.
• Ensure the listen IP and Port are set respectively to 127.0.0.1 and 8080.
• Verify that the policy field matches the policy name created on the BigSwitch controller.
• Verify that both usetag and vision_syslog are set to false (not available on this version).
BIG SWITCH NETWORKS
VERSION 1.0
• Set the local_hostname field to a name that will appear on syslog messages identifying this
DefenseFlow/SCO.
• Fill the bigswitch_controllers with a comma separated list of IP:port for the BigSwitch
controllers.
Example:
"bigswitch_controllers": [
"192.168.1.1:8443",
"10.25.209.174:8443"
],
• SCO will attempt to deliver the rule to each BigSwitch controller one by one, stopping the
first that accepts it.
• Fill the vision_servers with a comma separated list of IP for the Vision servers to use for
messaging.
Example:
"vision_servers": [
"192.168.1.106"
],
• SCO will deliver log messages to each one of the Vision servers, reporting if any is
unreachable.
• Fill the syslog_servers with a comma separated list of IP:port for the Syslog servers to use
for messaging.
Example:
"syslog_servers": [
"192.168.1.52:514"
],
• SCO will deliver log messages to each one of the Syslog servers.
• Execute the encrypt.php and follow its instructions carefully, as it will request credentials
for each BigSwitch controller one by one.
• Passwords entered onto the encryptor (therefore set on the DF and BigSwitch) must not
contain the colon ':' character.
• Once the encrypt.php finishes, the authentication data is added to each respective
BigSwitch entry in the configuration file.
SCO Support Scripts

SCO adds a few support scripts which facilitate its operation.
• ./check.php - Verifies the json configuration syntax and dumps its contents to the screen.
• ./status.sh - Verifies if there's a SCO copy running. Removes the /tmp/sco.run file if not.
• ./start.sh - Starts a SCO copy in the background.
BIG SWITCH NETWORKS
VERSION 1.0
• ./stop.sh - Stops any running SCO copy and removes the /tmp/sco.run file.
• ./watchdog - Verifies if SCO is running and attempts to restart it if not. (runs from crond
every minute)
• ./encrypt.php - Creates the encrypted credentials inside the configuration file.
SCO Execution
SCO is executed automatically on boot by adding the start.sh script to the device’s rc.local.
To execute SCO manually just run: ./SCO_server.php from inside the “Server” folder.
All the .php scripts provided are self-executable and can have their execution bits turned on
(chmod 775 <file>). There is no need to use php -f <script name>.
SCO Watchdog
The SCO Watchdog script runs every minute as a cron job, verifying the SCO presence and
attempting to restart it. If SCO is found inoperant, the watchdog reports this situation via
Vision message console and syslog. This message should be treated as high priority.
SCO Troubleshooting
• SCO sends messages to Vision and Syslog servers.
• Extra information if recorded to the log file, which by default is located on the /tmp folder.
This file is called SCO.log.
• The file /tmp/sco.run contains the process id of the currently running SCO copy. This file is
kept if SCO crashes. It can be removed by the provided .sh support scripts.
• In order to increase the amount of data logged by SCO, set the "debug" field on the
configuration file to true.
SCO Version
• The current version doesn't have the ability to collect syslog servers from Vision yet.
• The current version doesn't have the scotag check functionality implemented yet. (*)
• The current version doesn't enforce the sender's list yet.
SCO Error Messages
The following list of error messages are sent by SCO to Vision and syslog. These messages can
be parsed and prioritized by 3rd party applications to trigger alert tickers based on their
identification numbers. The values starting with $ are replaced by the message sender
accordingly.
• [SCO00001] SCO version $version Loaded.
• [SCO00002] Configuration file config.json not found.
BIG SWITCH NETWORKS
VERSION 1.0
• [SCO00003] Error $error while validating JSON configuration file.

• [SCO00004] Bigswitch controllers not defined.
• [SCO00005] Unable to communicate with any BigSwitch controller.
• [SCO00006] Send path not defined.
• [SCO00007] Error when obtaining operation data from DefenseFlow.
• [SCO00008] Authentication data is invalid.
• [SCO00010] Watchdog: SCO is running.
• [SCO00011] SCO not present/failed, restarting.
• [SCO00012] Error when obtaining authentication token from $send_ip.
• [SCO00013] Unable to obtain authentication token from $send_ip.
• [SCO00014] Unable to create authentication token request on $send_ip.
• [SCO00015] Error when obtaining next available rule from policy $configData->policy on
$send_ip.
• [SCO00016] Error when obtaining list of rules from policy $configData->policy on $send_ip.
• [SCO00017] Error when adding new rule to policy $configData->policy on $send_ip.
• [SCO00018] Error when deleting rule from policy $configData->policy on $send_ip.
• [SCO00019] Rule for $ipaddr has been added to BigSwitch $send_ip.
• [SCO00020] Rule for $ipaddr has been deleted from BigSwitch $send_ip.
• [SCO00021] Policy $configData->policy doesn't exist on $send_ip.
• [SCO00022] Error when obtaining device role from $send_ip.
• [SCO00023] Rule for $ipaddr has NOT been added to BigSwitch $send_ip.
• [SCO00024] Rule for $ipaddr has NOT been deleted from BigSwitch $send_ip.
• [SCO00025] Device $send_ip is not in active mode.
• [SCO00026] Device $send_ip returned error code $code.
BIG SWITCH NETWORKS
VERSION 1.0
Use Cases
Use Case 1: BMF Inline DefensePro SMARTap L2 diversion
BMF Switch deployed inline. DefensePro is deployed as SMARTap in Transparent Mode. BMF
Switch provides a copy of the traffic to DefensePro via a dedicated port/s. DefenseFlow writes
a policy to the DefensePro which is used to detect attacks. The policy is an always-on policy.
Once DefensePro detects an attack, DefenseFlow will perform a custom operation and send a
JSON object to the SCO module embedded on DefenseFlow. The SCO module will make a REST
API call to the BMF Controller providing the IP under attack. The BMF Controller updates the
filters on the BMF Switch to exclude the attack traffic from the COPY port and provide L2
diversion of the attack to the DefensePro for mitigation. The attack traffic is sent to the
DefensePro on a dedicated port pair where it is scrubbed and returned to the BMF Switch for
delivery to the destination.
This architecture is favored when diversion is preferred to be controlled programmatically via
the BMF controller @ L2 as opposed by BGP. Diversion via BGP is NOT desired and there is no
desire for DefenseFlow to peer with the routers.
Reference Architecture
The following diagrams will be used as a reference point for the configuration details. Keep in
mind these details will change per your environment (e.g. port numbers, policy names, VRFs,
etc).
Reference Diagram Data Plane
Edge Access
25 26
CLEAN
25 26
BMF Switch
11 9 10
SCRUBBED
DIRTY
COPY
11 9 10
DefensePro®
CLEAN
DIRTY
COPY
SCRUBBED
Diagram: Data Plane

BIG SWITCH NETWORKS
VERSION 1.0
Reference Diagram Control Plane

EDGE ACCESS
CLEAN
DIRTY
BMF Switch
SCRUBBED
DIRTY
COPY
DefensePro®
POLICY UPDATE
POLICY
ALERT
DefenseFlow®
SCO
BMF Controller
CONTROL PLANE
Diagram: Control Plane
DefensePro Configuration
DefensePro will be the detection and mitigation device. DefensePro should be configured in
Transparent Mode (default) with a management IP. A single port will be dedicated for receiving
a copy of all inbound traffic from the BMF Switch. A separate port pair will be dedicated for
scrubbing the attack traffic. Cable the DefensePro accordingly per your environment. Policy
configuration is handled by DefenseFlow.
DefenseFlow Configuration
DefenseFlow Mitigation Devices
Go to Configuration-->Network-->Mitigation Devices and click +
• Enabled = Checked
• Name = <Select Name of DefensePro>
• Managed Device = Checked
• Click Submit
BIG SWITCH NETWORKS
VERSION 1.0
DefenseFlow Detection
Go to Configuration-->Security Settings-->Detection click +
• Name = DPaaD
• Description = DefensePro as a Detector
BIG SWITCH NETWORKS
VERSION 1.0
• Click + to add a Detector

• Type = DefensePro as a Detector
• DefensePro to use as a Detector = <DefensePro Name>
• Click Submit
• Click Submit
BIG SWITCH NETWORKS
VERSION 1.0
DefenseFlow Operations
Two Operations will need to be created for this use case. One operation for Detection
and another operation for Diversion.
Detection Operation
This operation will create a pre-defined policy on the DefensePro used to detect attacks
Go to Configuration-->Security Settings-->Operations and click +
• Name = BMF-Operation-Detection
• Operation Type* = Mitigation
• Security Template = Basic
• Mitigation Group = ODS-MR
BIG SWITCH NETWORKS
VERSION 1.0
• Click Submit
Diversion Operation
This operation will use the SCO module to automatically update the BMF filter rules via
REST API in order to exclude attack from copy port and divert attack traffic to the
DefensePro to be scrubbed.
Go to Configuration-->Security Settings-->Operations and click +
• Name = BMF-Operation-L2-Diversion
• Operation Type* = Custom
• Custom URL = http://127.0.0.1:8080/
BIG SWITCH NETWORKS
VERSION 1.0
• Remote server authentication use = <BMF Admin User>

• Remote server authentication password = <BMF Admin Password>
• Click Submit
DefenseFlow Workflows
Go to Configuration-->Security Settings-->Workflows and click +

• Name = BMF-Workflow
• Detection = DPaaD
• Provisioning = BMF-Operation-Detection
Click + to add a WORKFLOW RULE

• Enter Criteria = AttackStart
• Enter Criteria User Action Mode = Automatic
BIG SWITCH NETWORKS
VERSION 1.0
• Exit Criteria = AttackStop

• Exit Criteria User Action Mode = Automatic
• Operation = BMF-Operation-L2-Diversion
• Click Submit
DefenseFlow Protected Object
Go to Configuration-->Security Settings-->Protected Objects--> and click +

• Name = BMF-PO-CustomerF
Click + to add a Protected Network CIDR

• Use any network address* = Unchecked
• Network Address* = 4.4.5.0/25
• Click Submit
BIG SWITCH NETWORKS
VERSION 1.0
Click Security Settings

• Policy Precedence = None
• Peak Traffic Bandwidth = 50000000
o NOTE: Set to peak legitimate traffic level for prefix CIDR being monitored
in your environment.
• Workflow = BMF-Workflow
• Policy = Default Policy Templates
• Click Submit
BIG SWITCH NETWORKS
VERSION 1.0
BIG SWITCH NETWORKS
VERSION 1.0
BMF Controller
Four Policies will need to be configured on the BMF Switch
• Inbound Traffic Policy
o NOTE: This policy will also be used to send COPY traffic to the DefensePro
• Clean Traffic Return Policy
• Dirty Traffic Policy
• Scrubbed Traffic Policy
BMF Policy Inbound-Traffic
This Policy will put the BMF Switch inline of the traffic path
Inbound-Traffic Info
Go to Big Tap-->Policies--> and click +
• Name = Inbound-Traffic
• Description = Optional
• Priority = 100
• Forward = selected
• Active = selected
• Start Policy = At Time
• Run Policy = Always
Inbound-Traffic Rules (FILTER CRITERIA)

Go to Rules and click +
• Sequence = 1
• Match All Traffic = Checked
• Click Append
BIG SWITCH NETWORKS
VERSION 1.0
Inbound-Traffic Feeds (SOURCE INTERFACE)

Go to Feeds and click +
• Select BS25--EdgeRouter25. This is the source interface of the inbound traffic
• Click APPEND SELECTED
Inbound-Traffic Tools (DELIVERY INTERFACE)

Go to Tools and click +
• Select BS26-->EdgeRouter26. This will send traffic to the Edge Router
• Select BS11-->DP11. This will send a COPY of the traffic to the DefensePro for
inspection.
Inbound-Traffic Summary
Go to Summary. Validate defined parameters.
• Validate Name = Inbound-Traffic
BIG SWITCH NETWORKS
VERSION 1.0
• Validate Action = forward

• Validate Priority = 100
• Validate Rules = match any
• Validate Filter Interfaces = BS25--EdgeRouter25
• Validate Delivery Interfaces = BS26--EdgeRouter26 and BS11--DP11 (COPY)
• Click Save
BMF Policy Clean-Traffic-Return

Clean-Traffic-Return Info
• Name = Clean-Traffic-Return
• Priority = 100
BIG SWITCH NETWORKS
VERSION 1.0
Clean-Traffic-Return Rules (FILTER CRITERIA)

• Sequence = 1
• Click Append
Clean-Traffic-Return Feeds (SOURCE INTERFACE)

• Select BS26--AccessRouter26. This is the source interface of the return traffic.
BIG SWITCH NETWORKS
VERSION 1.0
Clean-Traffic-Return Tools (DELIVERY INTERFACE)

• Select BS25--EdgeRouter25. This will send traffic back to the Edge Router.
Clean-Traffic-Return Summary
Go to Summary
• Validate Name = Clean-Traffic-Return
• Validate Filter Interfaces = BS26--AccessRouter26
• Validate Delivery Interfaces = BS25--EdgeRouter25
• Click Save
BIG SWITCH NETWORKS
VERSION 1.0
BMF Policy Dirty-Traffic

NOTE: The Dirty-Traffic policy will have a higher priority. Since BMF implements first match,
this will avoid duplication of the attack traffic to the copy port. This policy acts as a place
holder to be dynamically updated via SCO & DefenseFlow when an attack is detected by
DefensePro.
Dirty Traffic - Info
• Name = Dirty-Traffic
• Priority = 101
BIG SWITCH NETWORKS
VERSION 1.0
Dirty-Traffic Rules
NOTE: This Rule will not be initially configured. This policy acts as a place holder to be
dynamically updated via SCO & DefenseFlow when an attack is detected by DefensePro.
Dirty-Traffic Feeds (SOURCE INTERFACE)
• Select BS25--EdgeRouter25. This will be the source of the attack traffic.
Dirty-Traffic Tools (DELIVERY INTERFACE)

BIG SWITCH NETWORKS
VERSION 1.0
• Select BS09--DP09. This will send traffic to the attack port of the DefensePro.
Dirty-Traffic Summary
Go to Summary
• Validate Name = Dirty-Traffic
• Validate Filter Interfaces = BS25--EdgeRouter25
• Validate Delivery Interfaces = BS09--DP09
• Click Save
BIG SWITCH NETWORKS
VERSION 1.0
BMF Policy Scrubbed-Traffic

Scrubbed-Traffic Info
• Name = Scrubbed-Traffic
• Priority = 100
BIG SWITCH NETWORKS
VERSION 1.0
Scrubbed-Traffic Rules
• Sequence = 1
• Click Append
Scrubbed-Traffic Feeds (SOURCE INTERFACE)

• Select BS1--DP10
BIG SWITCH NETWORKS
VERSION 1.0
Scrubbed-Traffic Tools (DELIVERY INTERFACE)

• Select BS2--AccessRouter26. This will send scrubbed traffic to the access router.
Scrubbed-Traffic Summary
Go to Summary. Validate This is where you will select where to deliver the traffic. Traffic will
need to be delivered to the DefensePro (as a copy) and back to the core for delivery to the
destination
• Name = Scrubbed-Traffic
• Validate Filter Interfaces = Select BS1--DP10
BIG SWITCH NETWORKS
VERSION 1.0
• Validate Delivery Interfaces = BS2--AccessRouter26

• Click Save
Summary
• No VRF
• No BGP
• Fully transparent
• No requirement from netops
• All benefits from packet brokering
For more information on this use case please refer to the following webinar
https://www.radware.com/products/defensepro
This document is provided for information purposes only. This document is not
warranted to be error-free, nor subject to any other warranties or conditions, whether
expressed orally or implied in law. Radware specifically disclaims any liability with
respect to this document and no contractual obligations are formed either directly or
indirectly by this document. The technologies, functionalities, services, or processes
described herein are subject to change without notice.

Big Switch Installation

Uploaded by

Document Information

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

Big Switch Installation

Uploaded by

Copyright:

Available Formats

BIG SWITCH NETWORKS

VENDOR INTEGRATION SERIES

Big Monitoring Fabric (BMF) Overview

• Set IP Method to Manual

• Verify Controller State by entering “show controller details” at the CLI

2. Configure IPAM on BMF Controller

3. Configure BMF Switch Details on the BMF Controller

4. Install BMF Switch

• Show switch <switch name> zerotouch

Verify from the BMF Switch

Server Custom Operations (SCO) Overview

• Supports API calls to multiple BMF controllers

SCO High Availability

Edit SCO JSON

SCO Support Scripts

• [SCO00003] Error $error while validating JSON configuration file.

Diagram: Data Plane

Reference Diagram Control Plane

Diagram: Control Plane

• Click + to add a Detector

• Remote server authentication use = <BMF Admin User>

Go to Configuration-->Security Settings-->Workflows and click +

Click + to add a WORKFLOW RULE

• Exit Criteria = AttackStop

DefenseFlow Protected Object

Go to Configuration-->Security Settings-->Protected Objects--> and click +

Click + to add a Protected Network CIDR

Click Security Settings

Inbound-Traffic Rules (FILTER CRITERIA)

Inbound-Traffic Feeds (SOURCE INTERFACE)

Inbound-Traffic Tools (DELIVERY INTERFACE)

• Validate Action = forward

BMF Policy Clean-Traffic-Return

Clean-Traffic-Return Rules (FILTER CRITERIA)

Clean-Traffic-Return Feeds (SOURCE INTERFACE)

Clean-Traffic-Return Tools (DELIVERY INTERFACE)

BMF Policy Dirty-Traffic

Dirty-Traffic Tools (DELIVERY INTERFACE)

BMF Policy Scrubbed-Traffic

Scrubbed-Traffic Feeds (SOURCE INTERFACE)

Scrubbed-Traffic Tools (DELIVERY INTERFACE)

• Validate Delivery Interfaces = BS2--AccessRouter26

You might also like