BGP Connector¶

Wanguard Sensor and Wanguard Filter can send and withdraw BGP announcements (advertisements/routing updates) automatically, by using Response actions, in the following cases:

■ To protect your network by announcing DDoS’ed destinations to the upstream provider(s) with a special BGP community. Your side will no longer route the attacked addresses making them effectively null-routed by your BGP peers. This network protection technique is called blackhole routing, null-routing or RTBH (Remote Triggered Black Hole)

■ To re-route attacked destinations through servers running Wanguard Filter, block attackers’ packets and re-inject cleaned traffic back into the network. This network protection technique is called traffic scrubbing, clean pipe, side filtering or sinkhole routing

■ To leverage BGP Flowspec for RTBH and/or traffic diversion

■ To announce the attacking IP in BGP when S/RTBH is available

If you do not need any of those features, you can safely skip this chapter.

You need to install and configure Quagga BGPd, FRR or ExaBGP before adding a BGP Connector. FRR is a fork of Quagga, so you can use it as a newer alternative.

A BGP Connector is a frontend to an existing Quagga BGPd or ExaBGP configuration. It is used solely to announce IPs, subnets or Flowspec rules to a previously configured backend, using the parameters from their configuration (route map, community, etc.).

Wanguard supports two different backends for dealing with BGP announcements:

● Quagga and FRR provide a mature and widely used BGP daemon that closely resembles existing closed- source platforms like Cisco IOS. This is the recommended backend if support for BGP Flowspec is not needed

● ExaBGP 4.0 is a Python-based tool, typically used outside the data plane to do path manipulation on a BGP network that may be composed of closed-source components. ExaBGP supports newer technologies such as Flowspec

To add a BGP Connector, click the [+] button from the title bar of the Configuration » Components panel. To modify an existing BGP Connector, go to Configuration » Components and click its name.

18.1. BGP Connector for Quagga / FRR¶

Before adding a Quagga connector, consider following the steps from Appendix 3 and Quagga / FRR BGPd Configuration.

● BGP Connector Name – A short name or description of the BGP Connector

● Device Group – Optional description used to group up components (e.g. by location or role). It can be used to restrict the access of Guest accounts

● BGPd Server – Which server runs the Quagga BGPd daemon. Install the WANbgp and WANsupervisor packages on the selected server. The configuration of servers is described in the Configuration » Servers chapter

● Connector Role – Set the correct role, “Diversion” or “Mitigation”. If you have a single bgpd.conf for both roles, define two distinct BGP Connectors, one for the diversion route-map and community and one for the mitigation route-map and community

● Source RTBH – Enable if the BGP Connector must be used for S/RTBH. If this is the case, add an S/RTBH action to the Response executed by Filter

● AS Number – The same AS number with the one from the BGPd configuration

● Route Map – A route-map that will be appended to each announcement. This option is not mandatory but widely used to add communities to the routing update

● AS View – If multiple AS views are defined in the BGPd configuration, you must enter the AS view you want to use for this configuration. This option is not mandatory and rarely used

● Login Password – Password needed to connect to the Quagga/FRR BGPd daemon

● Enable Password – Configuration mode password of the Quagga/FRR BGPd daemon

● Reject External IPs – When this option is selected, only the announcements for IPs/subnets defined inside an IP Zone (excluding 0.0.0.0/0) are sent

● Reject IPv4 under / – Restricts sending prefixes that have the IPv4 CIDR mask less than the configured value. For example, a value of 32 rejects all prefixes that are not hosts and prevents manual or automatic announcements of subnets. To disable this feature enter the value 0

● Reject IPv6 under / – Restricts sending prefixes that have the IPv6 CIDR mask less than the configured value. For example, a value of 128 rejects all prefixes that are not hosts and prevents manual or automatic announcements of subnets. To disable this feature enter the value 0

● Restrict IPv4 over / – Set to the maximum IPv4 CIDR mask accepted by your cloud-based DDoS mitigation providers. For example, if your BGP peers accept only /24 prefixes, and you want to announce a whole C class for a single attacked IP, set to 24. To disable this feature enter the value 32

● Restrict IPv6 over / – Set to the maximum IPv6 CIDR mask accepted by your cloud-based DDoS mitigation providers. To disable this feature enter the value 128

● Quagga/FRR bgpd.conf – The content of the bgpd.conf file downloaded by the WANsupervisor service. The file uses a format very similar to Cisco IOS configuration format. Quagga’s documentation covers the configuration options

● Quagga Zebra Local Black Hole – Check if you need the local black hole feature provided by the Zebra daemon. This rarely-used feature may be useful only for in-line servers

● Quagga Zebra Login & Enable Passwords – Passwords needed to connect to the zebra daemon

● Comments – Comments about the BGP Connector can be saved here. These observations are not visible elsewhere

Note

You can manually send a test BGP announcement with an unused/test IP address in Reports » Tools » Routing » [Create Black Hole] or [Divert Traffic], to see if everything is running correctly and that bgpd.conf is updated accordingly. If you encounter errors, follow the troubleshooting guide from below. All BGP routing updates are logged in Reports » Tools » Routing » BGP Announcement Archive.

18.2. BGP Connector for ExaBGP¶

Before adding an ExaBGP connector, consider following the steps from Appendix 3 and ExaBGP Configuration.

● BGP Connector Name – A short name or description for the BGP Connector

● Device Group – Optional description to group up components (e.g. by location or role). It can be used to restrict the access of Guest accounts

● ExaBGP Server – Which server runs ExaBGP. Install the WANbgp and WANsupervisor packages on the selected server. The configuration of servers is described in the Configuration » Servers chapter

● Connector Role – Set the correct role, “Diversion” or “Mitigation”

● ExaBGP Pipe – Mandatory path to the socat pipe file used to control ExaBGP. Details in the ExaBGP Configuration section

● BGP Flowspec – Enable if your network supports BGP Flowspec (RFC 5575)

● Source RTBH – Enable if the BGP Connector must be used for S/RTBH. If this is the case, add an S/RTBH action to the Response executed by Filter

● BGP Neighbor – Optional parameter used to distinguish between BGP neighbors

● Community – BGP community or list of BGP communities to be appended to each announcement. Not mandatory

● Extended Community – BGP extended community or list of BGP extended communities to be appended to each announcement. Not mandatory

● Redirect (IP/VRF) – Optional parameter for diversion. Can be an IP, VRF or “self”

● Route Distinguisher – An optional rd value to be passed with each announcement

● Other Parameters – Other parameters that will be passed with each announcement, such as local- preference or as-path, in ExaBGP.conf format, separated by semicolon

● Flow Direction – Switches the source IP with the destination IP in each announcement. Set to “Inverted” only when doing symmetric routing

● Reject External IPs – When this option is selected, only the announcements for IPs/subnets defined inside an IP Zone (excluding 0.0.0.0/0) are sent

● Max. Flowspec Rules – The number of Flowspec rules accepted by each router is limited, so you may have to enter the limit here to prevent overflowing the number of rules

● Reject IPv4 under / – Restricts sending prefixes that have the IPv4 CIDR mask less than the configured value. For example, a value of 32 rejects all prefixes that are not hosts and prevents manual or automatic announcements of subnets. To disable this feature enter the value 0

● Reject IPv6 under / – Restricts sending prefixes that have the IPv6 CIDR mask less than the configured value. For example, a value of 128 rejects all prefixes that are not hosts and prevents manual or automatic announcements of subnets. To disable this feature enter the value 0

● Restrict IPv4 over / – Set to the maximum IPv4 CIDR mask accepted by your cloud-based DDoS mitigation providers. For example, if your BGP peers accept only /24 prefixes, and you want to announce a whole C class for a single attacked IP, set to 24. To disable this feature enter the value 32

● Restrict IPv6 over / – Set to the maximum IPv6 CIDR mask accepted by your cloud-based DDoS mitigation providers. To disable this feature enter the value 128

● Comments – Comments about the BGP Connector can be saved here. These observations are not visible elsewhere

Start ExaBGP version 4.0 on the host, then enable the BGP Connector by clicking the small on/off switch button displayed next to its name in Configuration » Components.

Note

You can manually send a test BGP announcement with an unused/test IP address in Reports » Tools » Routing » [Create Black Hole] or [Divert Traffic], to see if everything is running correctly. If you encounter errors, follow the troubleshooting guide from below. All BGP routing updates are logged in Reports » Tools » Routing » BGP Announcement Archive.

18.3. BGP Connector Troubleshooting¶

✔ Ensure that you have correctly configured the BGP Connector. Each configuration field is described in depth in this chapter
✔ Look for warnings or errors produced by the BGP Connector in Reports » Tools » Routing » BGP Connector Events ( see the Configuration » Schedulers » Event Reporting section for more details)
✔ Telnet connection errors on port tcp/2605 in the event log indicate that the Quagga BGPd daemon is not accessible via telnet. By default, some Linux distributions bound bgpd to 127.0.0.1, which is why the string “-A 127.0.0.1” must be deleted from bgpd’s starting scripts (see Quagga / FRR BGPd Configuration for details)
✔ Telnet connection errors on port tcp/2601 indicate that the Quagga BGP Connector was configured with the Quagga Zebra Local Back Hole feature, but the zebra daemon is not configured or accessible from the Console server
✔ Telnet errors about pattern time-outs indicate mismatches between a parameter defined in the BGP Connector (password, AS number, route-map, AS view) and the similar parameter from bgpd.conf
✔ You can clear BGP prefix errors from Reports » Tools » Routing » Active BGP Announcements » Batch Actions » [Clear], or by clicking the stop button for each announcement
✔ Errors about “orphaned” announcements indicate that the BGP announcement is still active after the anomaly has ended. The BGP announcements are withdrawn by the Sensor that detected the anomaly, immediately after the anomaly ends.
Orphaned announcements can have multiple reasons:
◦ The anomaly was ended forcefully by clicking the [Expire] button in Reports » Tools » Anomalies
◦ The Sensor that detected the anomaly was deleted or is not running anymore
◦ The WANsupervisor was not running at the time of the withdrawal
◦ Networking errors between the Console server and the server running bgpd. If this is the case, you should see the exact telnet error in the event log’s details.
✔ Make sure you are running the latest version of the software by checking Help » Software Updates