BMP on the Huawei NE for EdgeWarden, configuration explained

What BMP gives EdgeWarden

BMP (BGP Monitoring Protocol, RFC 7854) sends the router's BGP tables to the collector in real time. In EdgeWarden they show up under BGP → BMP Station, a read-only screen. Each table (RIB) and what depends on it are explained in BMP on the Juniper MX for EdgeWarden, configuration explained; here the focus is the Huawei configuration.

On Huawei, BMP lives in its own view, outside BGP, and everything is declared in one place, per session and per family. There is no hierarchy trap like on Junos.

The collector address was replaced with a documentation address: 192.0.2.10. Replace it with your own.

Prerequisites

Enterprise license: without it, EdgeWarden's BMP receiver doesn't start and the log records why. After upgrading, restart the collector.
Port 11019/TCP open on the EdgeWarden server, only to your routers' IPs. EdgeWarden opens the port and waits: the router always initiates the connection.
VRP with two-stage configuration: nothing takes effect until commit.

The configuration

This is the configuration as it appears in display current-configuration:

VRP: BMP in production

bmp
 #
 bmp-session 192.0.2.10 alias netflowspec
  tcp connect port 11019
  connect-interface LoopBack0
  #
  monitor public
   route-mode ipv4-family unicast adj-rib-in pre-policy
   route-mode ipv4-family unicast adj-rib-out pre-policy
   route-mode ipv4-family unicast adj-rib-out post-policy
   route-mode ipv4-family unicast local-rib
   route-mode ipv6-family unicast adj-rib-in pre-policy
   route-mode ipv6-family unicast adj-rib-out pre-policy
   route-mode ipv6-family unicast adj-rib-out post-policy
   route-mode ipv6-family unicast local-rib
  #
  monitor peer 192.0.2.10
#

Session

bmp: enters the BMP view, separate from the BGP configuration.
bmp-session 192.0.2.10 alias netflowspec: creates the BMP session with the EdgeWarden collector. The alias names the session and allows more than one session to the same IP.
tcp connect port 11019: the router opens the TCP connection to port 11019 on the collector, EdgeWarden's default port.
connect-interface LoopBack0: the session is sourced from the loopback. The session's source IP becomes the router's identity in EdgeWarden; with the loopback, it stays stable and matches the device record and SNMP. Without this line, the session leaves through whichever interface reaches the collector, and a route change makes the router reappear as if it were a different one, with its history split in two. Applying it on a router whose session is already up makes the session drop and reconnect; BGP sessions with neighbors aren't affected. Open 11019 on the server to the loopback IP as well.

What is monitored

monitor public: monitors the BGP neighbors of the public network (outside VPNs). The route-mode lines below say which tables of each neighbor are sent.
route-mode ipv4-family unicast adj-rib-in pre-policy: sends in pre, everything each neighbor announces in IPv4, before the import filter. It answers "is the neighbor sending me this prefix?".
route-mode ipv4-family unicast adj-rib-out pre-policy: sends out pre, what would go to each neighbor in IPv4, before the export policy.
route-mode ipv4-family unicast adj-rib-out post-policy: sends out post, what is actually announced to each neighbor in IPv4, after the export policy. VRP accepts pre-policy and post-policy together on the Adj-RIB-Out: with both lines, both versions arrive.
route-mode ipv4-family unicast local-rib: sends the IPv4 Local-RIB, the router's effective table. It has no pre or post, because it is the result of the BGP decision.
The four ipv6-family lines: the same for IPv6. On Huawei, each family is declared separately; without these lines, IPv6 doesn't arrive.
monitor peer 192.0.2.10: opens the monitoring configuration for one specific BGP neighbor, here the EdgeWarden server itself, which also has a BGP session with the router. With no route-mode under it, the line doesn't change what is sent: in display bgp bmp-monitor all, this neighbor shows the same tables as monitor public.

Keeping routes in BGP

The line below goes in the BGP configuration, not in the BMP view:

VRP: BGP with keep-all-routes

bgp 65000
 keep-all-routes

bgp 65000: the BGP view. Replace it with your ASN.
keep-all-routes: the router keeps every route received from each neighbor since the session came up, including those rejected by the import policy (route-policy, filter-policy, ip-prefix). They are stored but don't enter the active BGP table.
Its original purpose is changing an import policy without dropping the session: the router reapplies the new policy to the local copy, without asking the neighbor to resend its routes via route-refresh (RFC 2918). It is the equivalent of Cisco's soft-reconfiguration inbound.
For BMP, it is what makes in pre complete. Without this line, VRP discards rejected routes, they never reach BMP, and in pre shows only what passed the filter, the opposite of what "pre-policy" promises.
The cost is memory: the router keeps routes it would otherwise discard. If your BGP doesn't have the line yet, apply it in a maintenance window and watch Routing Engine memory and BGP sessions after commit.

What reaches EdgeWarden

With this configuration, the Route Feed tab of the BMP Station screen shows, in the RIB column:

RIB	Where it comes from
`in pre`	`adj-rib-in pre-policy`, IPv4 and IPv6
`out pre`	`adj-rib-out pre-policy`, IPv4 and IPv6
`out post`	`adj-rib-out post-policy`, IPv4 and IPv6
`loc-rib`	`local-rib`, IPv4 and IPv6

in post doesn't show up, because the configuration doesn't request adj-rib-in post-policy. EdgeWarden processes IPv4 unicast and IPv6 unicast; VPN, L2VPN, and FlowSpec arriving over BMP are ignored on purpose.

Points to watch

The points below don't change the configuration above; they explain what each choice means in EdgeWarden.

Adj-RIB-Out in pre- and post-policy

out post is what the router actually announces to each neighbor, after the export policy. EdgeWarden's inbound traffic engineering confirms its signals (withdrawing or prepending a block toward a provider) and checks manual inbound announcements through out post: without the post-policy line, that confirmation doesn't happen for the router. out pre shows what would go out before the policy; comparing the two shows what the export policy filtered or changed. RIB Guard uses both versions.

Scope

monitor public sends the tables of every public-network neighbor, including customers receiving a full table. The Adj-RIB-Out of a full-table customer generates a lot of volume with no value for traffic engineering. To narrow it down, Huawei uses monitor peer with your transit and peering neighbors, each with its own route-mode lines, instead of monitor public.

Verification

Output from an NE with this configuration (addresses replaced and neighbor list shortened):

VRP: BMP status

display bgp bmp-monitor all
 0.0.0.0/:: : monitor public / private
 Route modes: a - add-path, A - all, m - path-marking, ID - route-identifier

*>BGP ipv4-family unicast :
  Peer                Session Ip    Alias        State  route-mode
  0.0.0.0             192.0.2.10    netflowspec  up     local-rib
  203.0.113.1         192.0.2.10    netflowspec  up     in pre-policy/out pre-policy/out post-policy
  192.0.2.10          192.0.2.10    netflowspec  up     in pre-policy/out pre-policy/out post-policy
  203.0.113.5         192.0.2.10    netflowspec  up     in pre-policy/out pre-policy/out post-policy

*>BGP ipv6-family unicast :
  Peer                Session Ip    Alias        State  route-mode
  ::                  192.0.2.10    netflowspec  up     local-rib
  2001:DB8:1000::1E   192.0.2.10    netflowspec  up     in pre-policy/out pre-policy/out post-policy
  2001:DB8:8000::FFFE 192.0.2.10    netflowspec  up     in pre-policy/out pre-policy/out post-policy

State up on every line: the BMP session is up.
The Local-RIB shows up as a "neighbor" with address 0.0.0.0 (IPv4) and :: (IPv6), with local-rib in the route-mode column. This is normal.
Each real neighbor shows in pre-policy/out pre-policy/out post-policy, the three tables requested under monitor public.
IPv4 and IPv6 appear in separate blocks. If a family is missing, its route-mode is missing.
The collector IP (192.0.2.10) also shows up as a neighbor, because the EdgeWarden server has a BGP session with this router.

On the EdgeWarden server, check the TCP session:

EdgeWarden server: BMP sessions

ss -tn state established '( sport = :11019 )'

In the interface, under BGP → BMP Station, the Roteadores (routers) tab shows the NE by the session's source IP, and the Route Feed tab shows in pre, out pre, out post, and loc-rib.

Open 11019/TCP on the server only to your routers' IPs. Anyone who connects to that port and speaks BMP joins the router list and can send forged routes to the automations that depend on BMP.

Configuration to paste

The same commands as the configuration above, with navigation between views (system-view, quit) and commit at the end. Replace the collector and the ASN with your own.

VRP: BMP to paste

system-view
bmp
 bmp-session 192.0.2.10 alias netflowspec
  tcp connect port 11019
  connect-interface LoopBack0
  monitor public
   route-mode ipv4-family unicast adj-rib-in pre-policy
   route-mode ipv4-family unicast adj-rib-out pre-policy
   route-mode ipv4-family unicast adj-rib-out post-policy
   route-mode ipv4-family unicast local-rib
   route-mode ipv6-family unicast adj-rib-in pre-policy
   route-mode ipv6-family unicast adj-rib-out pre-policy
   route-mode ipv6-family unicast adj-rib-out post-policy
   route-mode ipv6-family unicast local-rib
   quit
  monitor peer 192.0.2.10
   quit
  quit
 quit
bgp 65000
 keep-all-routes
 quit
commit

Next steps

Each RIB and the automations that use BMP are explained in BMP on the Juniper MX for EdgeWarden, configuration explained. For flows from the same NE, see NetStream v9 explained or NetStream IPFIX explained. Server ports and firewall are in the installation guide.