How-to – Huawei Flowspec configuration

Device tested: NE8000-F1A, VRP Version V800R012C10SPC300

Config

BGP Config

bgp 100 
 peer 10.10.10.2 as-number 65001
 peer 10.10.10.2 description "BGP session to BGP FLOWSPEC Controller"
 peer 10.10.10.2 ebgp-max-hop 1
 peer 10.10.10.2 password PWD
 peer 10.10.10.2 local-graceful-restart enable
#
ipv4-family unicast
  undo peer 10.10.10.2 enable
#
 ipv4-family flow
  peer 10.10.10.2 enable
  peer 10.10.10.2 route-policy FLOWSPEC-IN import
  peer 10.10.10.2 route-policy FLOWSPEC-OUT export
  peer 10.10.10.2 route-limit 100
  peer 10.10.10.2 advertise-community
  peer 10.10.10.2 advertise-large-community
  peer 10.10.10.2 validation-disable
#

Important Note: Route-policies won’t work on flow routes. They will filter any route per default. See the next step.

Filtering the FlowSpec networks/subnets in NLRIs

The “destination” field of received Flowspec routes need to be filtered. This is a first important step in granting some level of security of a per node basis.

If you can’t filter or don’t, you will overtrust your controller node which may harm your networks reachability at some point, because even if your Controller is secure, things just happen: while testing this Setup with a GoBGP server, I accidentally used an erronous command line to filter ICMPv4 with a dst/src combo but it filtered ICMP any/any instead, which is something you can avoid by requiring the dst field to be set to a specific IP range or even to one single /32 or /128 host address to avoid wiping out whole networks.

2 Ways to do it

From here there are two possible techniques. The first works on most VRP versions with FS support, while the second will only work with version V800R022C10SPC500, V800R023C00 or later (well, it may work with some earlier versions but Huawei support did recommend me these for stability reasons).

Note that the first technique can only filter the “destination” field of a FS announcement.

Technique 1

Use a prefix-filter + route-map combo, like you would on any other ipv4/v6 unicast peering session:

ip ip-prefix MYPREFIXES index 1 permit 172.16.0.0 16 greater-equal 32 less-equal 32
route-policy FLOWSPEC-IN permit node 10
  if-match ip-prefix MYPREFIXES
  apply community 100:666 additive
#

Now add this magical little piece of ducktape:

ipv4-family flow
  route match-destination
#

Technique 2

Only with the newer VRP versions, there are new Flowspec specific “if-match” parameters to match on in route-policies. Check this link for more info: Huawei Flowspec route-policy

There are 4 available in total:

  • if-match flowspec source ip-prefix
  • if-match flowspec source ipv6 prefix-list
  • if-match flowspec destination ip-prefix
  • if-match flowspec destination ipv6 prefix-list

So to achieve the same as above in Technique 1, you would have to only set this route-policy, without:

ip ip-prefix MYPREFIXES index 1 permit 172.16.0.0 16 greater-equal 32 less-equal 32
route-policy FLOWSPEC-IN permit node 10
  if-match flowspec destination ip-prefix MYPREFIXES
  apply community 100:666 additive
#

Check

GoBGP

This is the controller side:

$ sudo gobgp global rib -a ipv4-flowspec add community 65001:666 match protocol '==tcp' destination-port '==80' destination 172.16.0.1/32 then discard

$ gobgp global rib -a ipv4-flowspec
   Network  Next Hop             AS_PATH              Age    Attrs
*> [destination: 172.16.0.1/32][protocol: ==tcp][destination-port: ==80] fictitious 29d 07:19:41 [{Origin: ?} {Communities: 65001:666} {Extcomms: [discard]}]

Huawei CLI

Every route has an index, you can see details for a Flowspec rule after checking the routing-table:

>disp bgp flow peer

 BGP local router ID : 10.10.10.1
 Local AS number : 100
 Total number of peers : 1                 Peers in established state : 1

  Peer          V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State  PrefRcv
  10.10.10.2    4       65001   107404   125552     0 0894h54m Established        3
>disp bgp flow routing

 BGP Local router ID is 10.10.10.1
 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete
 RPKI validation codes: V - valid, I - invalid, N - not-found

 Total Number of Routes: 1
 * >  ReIndex : 188419
      Dissemination Rules:
       Destination IP : 172.16.0.1/32
       Protocol       : eq 6
       Dest. Port     : eq 80
       MED      :                     PrefVal  : 0
       LocalPref:
       Path/Ogn : 65001
>disp bgp flow routing-table 188419

 BGP local router ID : 10.10.10.1
 Local AS number : 100
 ReIndex : 188419
 Dissemination Rules :
   Destination IP : 172.16.0.1/32
   Protocol       : eq 6
   Dest. Port     : eq 80

 BGP flow-ipv4 routing table entry information of 188419:
 Match action :
   apply deny
 From: 10.10.10.1 (10.10.10.1)
 Route Duration: 29d07h12m03s
 Community: <100:666>, <65001:666>
 AS-path 65001, origin incomplete, pref-val 0, valid, external, best, pre 255
 Not advertised to any peer yet

How-to – Setup an OOB interface on a Huawei router

Create a VRF

ip vpn-instance oob-mgmt
description oob-mgmt-net
ipv4-family
#

Add the interface into the VRF

interface giga 0/0/0
description rear-eth-mgmt
undo shutdown
ip binding vpn-instance oob-mgmt
ip address 10.0.0.100 24
#

Set a static route as gateway

ip route-static vpn-instance oob-mgmt 0.0.0.0 0.0.0.0 10.0.0.1 description oob-mgmt-gw

Allow access via ACL

acl name ssh-access number mgmt-acl
rule 10 permit vpn-instance oob-mgmt source 172.16.0.0 0.0.255.255
rule 20 permit vpn-instance oob-mgmt source 192.168.100.0 0.0.0.255
rule 30 permit vpn-instance oob-mgmt source 10.0.0.200 0

Restrict SSH Access

user-interface vty 0 4
 acl ssh-access inbound
 authentication-mode aaa
 protocol inbound ssh
#

How-To – Activate licenses on Huawei NetEngine 8000

Licenses

You might receive a ton of licenses from your reseller. If they are PDFs, forward them accompanied by the ESN’s of your routers to the huawei support and let them take care of it, it’s a painful process otherwise. Once you get the XML license files you may only have to upload one type of license file to your device: the port activation license which is named something like “NetEngine 8000 XXXXX Fixed Port 10GE Upgrade RTU”. If the license shows “Free From Activation” you don’t have to upload & activate it. Note that in some cases all the licenses were already pre-uploaded on the device when new (N.B. You still need to activate manually the license slots per port though).

You can upload them using the How-To I wrote on How-To: Upload files to Huawei VRP devices.

Activating a port upgrade license

<router> tftp 192.168.0.100 get LICNetEngine8000F1A-8H20Q_V800R021_20220631XXXXX.xml
[~router] license activate 2102353XXXXXXXX.xml
[~router] display license
Active License    : 2102353XXXXXXXX.xml
License state     : Normal
Revoke ticket     : No ticket
License mode      : common

No relevant customer information

Product name      : NetEngine 8000
Product version   : V800R012
License Serial No : LIC20210XXXXXXX
Creator           : Huawei Technologies Co., Ltd.
Created Time      : 2021-08-25 11:22:33
-------------------------------------------------------------
Feature name      : CRFEA5
Authorize type    : comm
Expired date      : PERMANENT
Trial days        : --
Item name          Item type      Value      Description
-------------------------------------------------------------
LIC20210XXXXXXX      --             10         NetEngine 8000 F1A-8H20Q Fixed Port 10GE Upgrade RTU

LIC20210XXXXXXX     Resource       10         NetEngine 8000 F1A-8H20Q Fixed Port 10GE Upgrade RTU
Item name          (View)Resource License Command-line
-------------------------------------------------------------
LIC20210XXXXXXX      (License)active port-basic slot <slot-id> card <card-id> port <port-list>
Master board license state: Normal.

IMPORTANT: maybe the license is already pre-loaded on the device and you can skip those steps.

Done? Not yet!

Here comes the bitter sweet part. While your devices now got licenses to allow you the use of a bunch of 10, 25, 40, 100 or 400 GE Ports, you can’t just use them.

Indeed, now you will need to activate one license allocation slot to a port before using it:

router# license
router# active port-basic slot 0 card 1 port 28

You can see the allocation now being incremented by one:


			

How-To – Configure clock & ntp on Huawei VRP devices

The official guide to configure the clock and the ntp service is great but it’s difficult to guess what the config bare minimum has to be, so I summed it up here.

Set the time, date, timezone and DST

Just set the actual time this device should show:

<huawei>
clock timezone berlin add 01:00:00
clock daylight-saving-time berlin repeating 01:00 last Sun Mar 01:00 last Sun Oct 01:00
clock datetime 14:51:00 2022-05-04

Configure NTP synchronization

You want to configure a time server to get time synchronized via NTP but you don’t want this device to work as an ntp server itself.

[huawei]
ntp-service server disable
ntp-service ipv6 server disable
ntp-service unicast-server 172.16.0.201

Configure NTP service

If you want to serve time to clients as an actual NTP Server, following config will get you started:

[huawei]
undo ntp-service server disable
undo ntp-service ipv6 server disable
ntp-service refclock-master 2

PS: You may want to configure access control in this case. Check following link for this:

Disable NTP

Completely disable all NTP capabilities on the device.

[huawei]
ntp-service disable

Sources:

How-To – Upload files to Huawei VRP devices

Vendor documentation is full of information but everything is spread, sometimes confuse, unclear about compatibility and so on, so here’s a quick recap how to get your files on your Huawei VRP OS based router or switch.

Manual upload

You need files quickly uploaded on one single device for that single time. Maybe it’s an emergency or you have just one device to upgrade.

via SCP

We assume you have SSH already working from your client to the router. Just add following:

[~huawei] scp server enable

[~huawei] commit

Then:

admin@ubuntu:~$ scp NE20E-S2F-V800R012C10SPC300.cc admin@192.168.1.1:

admin@192.168.1.1’s password:

NE20E-S2F-V800R012C10SPC300.cc                                                                                                     100%  289MB 430.5KB/s   11:27

Note: works only with the Linux SCP command line. WinSCP or the RoyalTS SCP client doesn’t seem to work.

via TFTP or FTP

IMPORTANT: you will need to specify “vpn-instance oob-mgmt” if you want to transfer files over this interface or it won’t work.

We assume you have a TFTP or FTP server running and the router can reach the server.

Note: TFTP uses UDP to transfer data, in contrast to SCP, FTP or SFTP. I personally only ever use it when connected locally, directly, at a VRP device and all I got is a Windows PC where SCP doesn’t work.

I usually use the simple but excellent TFTPD64, which is an opensource project from Philippe Jounin (merci!).

Then it’s as simple as this:

<huawei>tftp 192.168.1.1 get S6730-S-V200R019C10SPC500.cc S6730-S-V200R019C10SPC500.cc
Info: Transfer file in binary mode.
Downloading the file from the remote TFTP server. Please wait…
100%
TFTP: Downloading the file successfully.
147262764 byte(s) received in 534 second(s).

Check firmware files

Before you do any operation based on those uploaded files, always check them first:

<huawei>check system-software cfcard:/NE20E-S2F-V800R012C10SPC300.cc

How-to – Upgrade a Huawei Switch Stack

Transfer files

<huawei-stack>tftp 192.168.1.1 put vrpcfg.zip vrpcfg-bak.zip
Info: Transfer file in binary mode.
Uploading the file to the remote TFTP server. Please wait…
100%
TFTP: Uploading the file successfully.
1589 byte(s) sent in 1 second(s).
<huawei-stack>tftp 192.168.1.1 get S6730-S-V200R019C10SPC500.cc S6730-S-V200R019C10SPC500.cc
Info: Transfer file in binary mode.
Downloading the file from the remote TFTP server. Please wait…
100%
TFTP: Downloading the file successfully.
147262764 byte(s) received in 534 second(s).
<huawei-stack>tftp 192.168.1.1 get S6730-S-V200R019SPH033.pat S6730-S-V200R019SPH033.pat
Info: Transfer file in binary mode.
Downloading the file from the remote TFTP server. Please wait…
100%
TFTP: Downloading the file successfully.
5371863 byte(s) received in 19 second(s).

Pre-upgrade

<huawei-stack>startup system-software s6730-s-v200r019c10spc500.cc all
Info: Operating, please wait for a moment……..
Info: Succeeded in setting the software for booting system in the slot 0.
The file flash:/s6730-s-v200r019c10spc500.cc already exists in the board 1. Overwrite? [Y/N]:Y
100% complete.\
Info: Copied file flash:/s6730-s-v200r019c10spc500.cc to slot1#flash:/s6730-s-v200r019c10spc500.cc…Done.
Info: Operating, please wait for a moment………..
Info: Succeeded in setting the software for booting system in the slot 1.
Info: Succeeded in setting the software for booting system.

<huawei-stack>startup patch s6730-s-v200r019sph033.pat ….
Info: Succeeded in setting main board resource file for system.

<huawei-stack>startup patch s6730-s-v200r019sph033.pat slave-board ..
Info: Succeeded in setting slave board resource file for system.

<huawei-stack>system-view 
[huawei-stack]upgrade backup-area slot 1 to 1

Pre-check

Take a look at your stack infos and check everything is as expected:

<huawei-stack>disp stack
Stack mode: Service-port
Stack topology type: Ring
Stack system MAC: 5413-1097-24d0
MAC switch delay time: 10 min
Stack reserved VLAN: 4093
Slot of the active management port: 0
Slot      Role        MAC Address      Priority   Device Type
-------------------------------------------------------------
0         Master      5413-1097-24d0   200        S6730-S24X6Q
1         Standby     8ce5-ef05-5b50   100        S6730-S24X6Q

Check the if the test is passed and if the right switch slots are in the right area:

<huawei-stack>disp upgrade area
Slot      Area         Upgrade-Check
------------------------------------
0         active       passed
1         backup       passed

Upgrade

Run the process:

[huawei-stack]upgrade start
Info: The system is now comparing the configuration, please wait......
Warning: Upgrade will begin. Continue? [Y/N]:Y
Info: The system is performing upgrade. Please wait......

Check the upgrade status:

[huawei-stack]disp upgrade state
Slot      Area         Status
-----------------------------
0         active       backup rebooting
1         backup       backup rebooting

You should see the status of the slot 0 (master) as “backup rebooting”:

[huawei-stack]disp upgrade state slot 0
--------------------------------------
  Slot        : 0
  Area        : active
  Status      : backup rebooting
  ErrorCode   : 0
  Description :
--------------------------------------

Check

Check the status of the upgrade again:

[huawei-stack]disp upgrade state
Slot      Area         Status
-----------------------------
0         active       successful
1         backup       successful

Check the versions are correct:

<huawei-stack>disp version slot 0 | inc VRP
Software      Version   : VRP (R) Software, Version 5.170 (V200R019C10SPC500)

<huawei-stack>disp version slot 1 | inc VRP
Software      Version   : VRP (R) Software, Version 5.170 (V200R019C10SPC500)

Ansible module – automatically send out notification E-Mails to down BGP peers

Use case

I’ve been working with Ansible for some time now but wanted to see how much it takes to write a module so I made up the scenario where you have routers peering at different IX’s and your goal is to check periodically for all bgp sessions stuck in “CONNECT” state then do something about it. Either getting a summary E-mail with some more info and/or sending notifications to those peers.

After reading through couple of docs and testing I came up with some working code built as a python ansible module so vars could be handed over at the ansible playbook execution.

In networking, Ansible is not always used like in servers where you define tasks that will be pushed to the nodes of an inventory and all of it executed remotely. In some ways it loses some functionality but regarding how network devices work, the only generic way get things done remotely is sending CLI commands through the integrated SSH/CLI session handler called network_cli that uses paramiko, maybe over rest API or netconf if you are lucky.

Architecture

  • group_vars/
    • extreme.yml
  • library/
    • notify_peers_napalm
  • vars/
    • config.yml
  • inventory.yml
  • ansible_notify_peers_playbook.yml

group_vars/extreme.yml

That’s where we define the connection variables for the routers are defined. If you have other type of routers you can add such a file with its own vars in group_vars/. If you have devices of the same group “extreme” but a couple have different vars, you would create a “vars/” directory at the root of your project and add a .yml file named after the host entry in the inventory, add there the custom variables.

---
os: netiron
user: admin
passwd: password

library/notify_peers_napalm

This is the ansible module we wrote for this usecase. It isn’t complicated: it’s just a python script that imports the ansible modules:

from ansible.module_utils.basic import *

Then in the main function you have to handle the JSON variable mapping, and…. that’s it! The rest is your own python code, it’s all just a question of logic and understanding how Ansible is the most efficient and finding the best way to make it work with the task.

Note: Of course don’t forget that Ansible has been developed with the goal to deploy/provision/maintain services & gather infos on a lot of systems at the same time – it’s an automation tool. If you don’t automate anything with it, you might want to ask yourself if it’s the right tool for your needs, even if in networking the built-in CLI handlers come in so handy it’s difficult not to justify the usage.

vars/config.yml

Here we store variables that are global anyways but needed for our modules execution. In our example, we define the details about our own network/AS and our infos/credentials for our SMTP server and peeringdb.com account (AS contact information are not disclosed in guest mode).

---
myvars:
as: '65500'
noc_email: 'yournoc@domain.tld'
cpy_name: 'CompanyLTD'
peeringdb_url: 'https://www.peeringdb.com/search?q=65500'
peeringdb_usr: 'login'
peeringdb_pwd: 'password'
smtp_auth: 'true'
smtp_login: 'peering@domain.tld'
smtp_pwd: 'password'
smtp_host: 'mail.domain.tld'
smtp_sender: 'peering@domain.tld'
smtp_port: '587'

inventory.yml

The inventory file records the existing internet exchanges we want to get processed and related information to each IX. Here we define all the routers of type extreme (here 10.10.10.255 is the hostname string but we tricked with the IP because the network_cli will connect to it via SSH anyway). Under “vars” we specified the IX’s name and the IPv4 network it runs on.

---
all:
vars:
children:
extreme:
hosts:
10.10.10.255:
vars:
ix: 'INTERNET-EXCHANGE1'
network: '192.168.1.0'

ansible_notify_peers_playbook.yml

This is the playbook file where tasks are defined. What it does in our case is import the vars from the vars/config.yml, then it uses Napalm’s napalm_get_facts to get a standardized output equivalent to a CLI “show ip bgp summary” command, assign the output to a variable result and finally call our own notify_peers_napalm module to process that info:

---
- hosts: all
  connection: local
  gather_facts: no
  vars:
#    ansible_python_interpreter: "/usr/bin/env python"

  tasks:
    - name: Include only files matching config.yml
      include_vars:
        dir: vars
        files_matching: config.yml

    - name: collect bgp neighbors information
      napalm_get_facts:
        hostname={{ inventory_hostname }}
        username={{ user }}
        dev_os={{ os }}
        password={{ passwd }}
        filter='bgp_neighbors'
      register: result
 
    - name: process the show bgp in the module
      notify_peers_napalm:
        input: "{{ result }}"
        notify_peers: "False"
        notify_summary: "True"
        vars: "{{ myvars }}"
        ix: "{{ ix }}"
        router_ip: "{{ inventory_hostname  }}"
        network: "{{ network }}"

notify_peers_napalm module

Main Routine

#strip the raw string and split it into individual peering lines
rough_peer_list = objectify_json(input,network)

#transform the string list into a list of "peer" objects
enriched_peer_list = add_info_obj(rough_peer_list)

#generate a summary to your NOC and/or/but don't send an E-Mail to all down peers 
generate_email(enriched_peer_list,notify_peers,notify_summary,ix)

If you want more detail, you can find the project’s files and code in my github repo:

https://github.com/pirmins/notify_peers_napalm

Output sample

You’d receive a summary E-Mail at your NOC:

Following Peerings have been identified as in down state: 
(No E-Mails have been sent, to auto-send E-Mails to peers change notify_peers to true in vars/config.yml)

------------------------
------------------------

Peer E-Mail: noc@peeringispX.com
------------------------
Peering session with peer AS65000 down at IX1
------------------------
   AS       IPv4           State      Age   
  65501   192.168.1.176   CONN   34d23h4m

------------------------
------------------------

Peer E-Mail: noc@peeringispY.com
------------------------
Peering session with peer AS65000 down at IX1
------------------------
   AS       IPv4           State      Age   
  65502   192.168.1.236   CONN   12d2h1m

If you do change notify_peers to true in vars/config.yml, an E-Mail like this sample will be sent to each down peer:

Hello AS65501 NOC,
We are ISPXY AS65000 and are peering with you at IX1.
Unfortunately, our peering session is down:

   AS       IPv4           State      Age   
  65501   192.168.1.176   CONN   66d2h47m 

Could you please take a look at your side or notify us about any peering policy changes so we can take them into account.
Thank you,

Kind regards,
ISPXY NOC
E-Mail: noc@ispXY.com
PeeringDB: https://www.peeringdb.com/search?q=65000

Final note

This is a case study and as a whole is an interesting automation project to implement from A to Z (for the Z part, I will explain how I integrated this Ansible project into AWX to make it really interesting). While bigger ISPs already have centralized set of tools to administrate and maintain their peerings, this could still be of big interest to smaller ISPs.

Now, at beginning, I wrote this module for Extreme SLX OS solely. I had to write a module per router OS to extend router OS compatibility because I am parsing CLI output which can vary a lot from one vendor to another. Thanks to NAPALM’s “get_bgp_neighbor” getter instead of “slxos_command” & “show ip bgp neighbor summary“, its CLI abstraction and ouput normalization, I could rewrite the main parsing function and simplify the ansible playbook a lot.

Caution though, NAPALM doesn’t officialy support the full range of network OSs, “only” IOS, IOS-XR, JUNOS, EOS & NXOS, but there are community projects for other vendors (Extreme SLXOS beeing one of them) that are working & if lucky also maintained. When you think about it, you can make your code handle most of the industry vendors instead of just one, for the same amount of work involved. That’s pretty powerfull!

For more informations about NAPALM & its getters/setters compatibility table per OSes: https://napalm.readthedocs.io/en/latest/support/index.html

Community projects listed here: https://github.com/napalm-automation-community

My project: https://github.com/pirmins/notify_peers_napalm

How-to – Simple network automation with Ansible – Part 2

Files

inventory.yml

---
all:
  vars:
  children:
    cisco:
      hosts:
        router1:
        router2:
    brocade:
      hosts:
        router3:
extreme:
hosts:
router4: huawei: hosts: router5:

Take care to the yaml syntax as its pretty sensitive. You can use an online syntax checker if your files don’t contain confidential infos.

Continue reading

How-to – Implement RPKI in 3 simple steps

What’s RPKI?

Although sounding complicated, Resource Public Key Infrastructure is just a way to secure the internet against IPv4/v6 prefix hijacks and leaks. To achieve that, RPKI will serve your router the trusted information so it can check if eBGP learned prefixes are originating from where they are allowed to (first AS in path) and in the format they are allowed to (subnetmask or subnetmask range). It’s first described in RFC6480.

An ROA (Route Origin Authorization) is kind of a signed IRR and basically has following structure:

ASN |  IPv4/v6 Prefix  |  Mask  | (Optional)  Max. Mask  | signature

These are usually stored on specific servers managed by your responsible IRR org.

2-way implementation

There are 2 independent aspects when you implement RPKI:

  • generate ROAs to protect your prefixes. This is usually made on your RIR platform who will act like a “Certification Authority” for it’s managed prefixes.
  • implement RPKI Validation to protect your routing-table. Setup your own Validator server who will download and verify the ROAs from the RIRs. A RTR Server (RPKI-to-Router protocol) is needed to send the ROA lists to your  routers.

You can run RPKI on your routers and take routing decisions based on it without having ROAs. You can also create ROAs for your prefixes without having RPKI implemented in your routing logic or network. Implement both is best.

While the title may refer to a very simple and quick process to implement RPKI, you might want to plan this carefully and study the impact on your routing. Best is to go trough the whole process with a /24 that isn’t used for prod.

Here you can see the Cloudflare RPKI diagram neatly describing the whole setup:

RPKI-diagram

Source: https://blog.cloudflare.com/rpki/

Before we start

Well, yes, deploying it could be relatively quick & easy in a small AS but  make sure you take time to fully understand the implications before taking any productive steps. Read through the tutorial and make your own opinion about how you will benefit from it and what risks it involves for your network.

Continue reading

How-to – Simple automated blackholing – Part 5

Upstream/RTBH blackholing

RFC 7999

A simple way to achieve blackholing is when your upstreams support RFC 7999 so you can tag a /32 eBGP announcement with community 666, the upstreams router picks it up and blackholes the prefix on their own network. That is a very simple solution, especially if you have only Tier1 Upstreams and no other eBGP/external Routing like peering IX’s etc.

Continue reading