In this guide, we will provide a detailed guide which will help you establish a BGP session between FastNetMon and JunOS / Juniper network devices.
To apply commands which alter the configuration of a router, you need to be in JunOS CLI, in configure mode. To switch JunOS CLI into configure mode, you need to runthe following command:
configure
We assume that you have BGP enabled on your router, but if you configure a new router, it may be needed.
set routing-options router-id 192.168.1.132 set routing-options autonomous-system 65001
Then you need to create a BGP peering session:
set protocols bgp group fastnetmon-advanced type internal set protocols bgp group fastnetmon-advanced description "Connection to FastNetMon"
In our example, we use iBGP, but you may use eBGP as well. On the next step, you need to set local and remote IPs (for a machine with FastNetMon installed) for this BGP session. Please ensure that each device can reach each other using these IP addresses:
set protocols bgp group fastnetmon-advanced local-address 192.168.1.132 set protocols bgp group fastnetmon-advanced neighbor 192.168.1.106
If FastNetMon is not connected directly into router, you will need to set this option on the router:
set protocols bgp group fastnetmon-advanced multihop
If you set multihop on the router, then on FastNetMon’s side, you will need to set the flag multihop for BGP peering session too.
In addition, I can recommend setting this option to simplify debugging as it will provide log entries when the BGP session goes up or down:
set protocols bgp group fastnetmon-advanced log-updown
Finally, commit changes:
commit
Then you will need to check that BGP peering session is configured properly on FastNetMon’s side.
As the next step, you can run this command to check the BGP session state change with this command. To run a command which just shows information, you need to use the “quit” command to leave configuration mode.
Then check the log files:
show log messages | last 5
Example output may look like:
Mar 1 03:12:24 rpd[8494]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 192.168.1.106 (Internal AS 65001) changed state from Established to Idle (event RecvNotify) (instance master) Mar 1 03:12:32 rpd[8494]: BGP_NLRI_MISMATCH: bgp_process_caps: mismatch NLRI with 192.168.1.106 (Internal AS 65001): peer: <inet-unicast inet-flow>(16385) us: <inet-unicast>(1) (instance master) Mar 1 03:12:32 rpd[8494]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 192.168.1.106 (Internal AS 65001) changed state from OpenConfirm to Established (event RecvKeepAlive) (instance master)
It confirms that the BGP session was successfully established between FastNetMon and GoBGP.
You may check the BGP session status from FastNetMon’s side this way (use IP of router here):
gobgp nei 192.168.1.132
Example output:
BGP neighbor is 192.168.1.132, remote AS 65001
BGP version 4, remote router ID 192.168.1.132
BGP state = ESTABLISHED, up for 00:07:15
BGP OutQ = 0, Flops = 0
Hold time is 90, keepalive interval is 30 seconds
Configured hold time is 90, keepalive interval is 30 seconds
Neighbor capabilities:
multiprotocol:
ipv4-unicast: advertised and received
ipv4-flowspec: advertised
route-refresh: advertised and received
extended-nexthop: advertised
Local: nlri: ipv4-unicast, nexthop: ipv6
nlri: ipv4-flowspec, nexthop: ipv6
graceful-restart: received
Remote: notification flag set
4-octet-as: advertised and received
long-lived-graceful-restart: received
cisco-route-refresh: received
Message statistics:
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 0 1
Keepalives: 15 17
Route Refresh: 0 0
Discarded: 0 0
Total: 16 19
Route statistics:
Advertised: 0
Received: 0
Accepted: 0
To see the BGP session status from Juniper, you can use this command (use IP of FastNetMon’s machine):
show bgp neighbor 192.168.1.106
Example output:
Peer: 192.168.1.106+179 AS 65001 Local: 192.168.1.132+62243 AS 65001
Description: Connection to FastNetMon
Group: fastnetmon-advanced Routing-Instance: master
Forwarding routing-instance: master
Type: Internal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Multihop Preference LocalAddress LogUpDown Refresh>
Options: <GracefulShutdownRcv>
Local Address: 192.168.1.132 Holdtime: 90 Preference: 170
Graceful Shutdown Receiver local-preference: 0
Number of flaps: 3
Last flap event: RecvNotify
Error: 'Cease' Sent: 0 Recv: 3
Peer ID: 192.168.1.106 Local ID: 192.168.1.132 Active Holdtime: 90
Keepalive Interval: 30 Group index: 0 Peer index: 0 SNMP index: 0
I/O Session Thread: bgpio-0 State: Enabled
BFD: disabled, down
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast inet-flow
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI of all end-of-rib markers sent: inet-unicast
Peer does not support Receiver functionality
Peer does not support LLGR Restarter or Receiver functionality
Peer supports 4 byte AS extension (peer-as 65001)
Peer does not support Addpath
NLRI that peer supports extended nexthop encoding for: inet-unicast
NLRI(s) enabled for color nexthop resolution: inet-unicast
Table inet.0 Bit: 20000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Accepted prefixes: 0
Suppressed due to damping: 0
Advertised prefixes: 0
Last traffic (seconds): Received 20 Sent 13 Checked 860
Input messages: Total 29 Updates 0 Refreshes 0 Octets 551
Output messages: Total 33 Updates 0 Refreshes 0 Octets 631
Output Queue[1]: 0 (inet.0, inet-unicast)
To confirm that everything works fine, we recommend blocking some test host on FastNetMon’s side in the following way:
sudo fcli set blackhole 11.22.33.44
And then checking that Juniper receive it correctly (use IP of the machine with FastNetMon):
show route receive-protocol bgp 192.168.1.106
Example output:
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 11.22.33.0/24 1.2.3.4 100 ? * 11.22.33.44/32 1.2.3.4 100 ? inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
This guide covers only BGP peering session setup. We did not create any filters or policies to apply a BGP blackhole. You need to do it on your own using the BGP communities provided by your ISP.