Juniper to MikroTik – BGP commands

About the Juniper to MikroTik series

In the world of network engineering, learning a new syntax for a NOS can be daunting if you need a specific config quickly.  Juniper is a popular option for service providers/data centers and is widely deployed across the world. 

This is a continuation of the Rosetta stone for network operating systems series.  We’ll be working through several protocols over series of posts to help you quickly move between different environments. 

While many commands have almost the exact same information, others are as close as possible.  Since there isn’t always an exact match, sometimes you may have to run two or three commands to get the information needed. 

Using EVE-NG for testing

We conducted all of this testing utilizing EVE-NG and the topology seen below. 

Juniper CommandMikroTik Command
show bgp summaryrouting bgp peer print brief
show bgp neighborrouting bgp peer print status
show route advertising-protocol bgp 172.31.254.2routing bgp advertisements print peer=peer_name
show route receive-protocol bgp 172.31.254.2ip route print where received-from=peer_name
show route protocol bgpip route print where bgp=yes
clear bgp neighbor 172.31.254.2 soft-inboundrouting bgp peer refresh peer_name
clear bgp neighbor 172.31.254.2 softrouting bgp peer resend peer_name
set routing-options autonomous-system 1/routing bgp instance
set default as=2
set protocols bgp group EBGP type external
set protocols bgp group EBGP peer-as 2
set protocols bgp group EBGP neighbor 172.31.254.2
/routing bgp peer
add name=PEER-1 remote-address=172.31.254.1 remote-as=1
set policy-options policy-statement REDIS-CONNECTED term 1 from protocol direct
set policy-options policy-statement REDIS-CONNECTED term 1 then accept
set protocols bgp group EBGP export REDIS-CONNECTED
/routing bgp network
add network=100.89.88.0/24
add network=100.89.87.0/24
add network=100.89.86.0/24
set routing-options static route 0.0.0.0/0 discard
set protocols bgp group EBGP export SEND-DEFAULT
set policy-options policy-statement SEND-DEFAULT term 1 from protocol static
set policy-options policy-statement SEND-DEFAULT term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement SEND-DEFAULT term 1 then accept
/routing bgp peer
add default-originate-always name=PEER-1 remote-address=172.31.254.1 remote-as=1


https://iparchitechs.com/contact

Examples of the commands above


This is a quick way to get a list of the peers/ASN and their status

[[email protected]] > routing bgp peer print brief

[email protected]> show bgp summary

This next command will show you more information about a peer.  In this case we did not specify the peer as there is only one.  On a peering router with multiple peers it is recommended to look only at specific peer information to not be overwhelmed with irrelevant information. 

[[email protected]] > routing bgp peer print status

[email protected]> show bgp neighbor

The next command allows you to see the prefixes that are sent to your peer as well as the next-hop associated with it. 

[[email protected]] > routing bgp advertisements print peer=PEER-1

[email protected]> show route advertising-protocol bgp 172.31.254.2

This next one will show you what routes were received from the peer and the next-hop you will advertise. 

[[email protected]] > ip route print where received-from=PEER-1

[email protected]> show route receive-protocol bgp 172.31.254.2

Here we will see the BGP prefixes that are in the routing table – both active and not.  On junOS you will see the count for hidden routes in the output but you will not see the hidden entries.  This will require the use of “show route protocol bgp hidden” to see the hidden entries.  On mikrotik you will see this type of route in the route table as inactive. 

[[email protected]] > ip route print where bgp=yes

[email protected]> show route protocol bgp

Configure BGP instance, peering, and originate a default route. 

Here is a very basic BGP peering configuration to establish a peer, advertise a few routes, and originate a default route. 

Let’s look at some of the differences in the configuration. 

It’s worth noting that everything in CAPS was manually defined . 

On junOS there is no concept of the “network” command that you might see in MikroTik or Cisco.

To accomplish the same functionality in this example I used a policy-statement named REDIS-CONNECTED that matched any connected route for redistribution. 

This is then applied as an export statement into the EBGP peer group.  Likewise, there is not a construct for “default-originate”.  In order to accomplish the same functionality, we created a static route to discard and exported this to the EBGP peer.

MikroTik BGP Configuration

Juniper BGP Configuration

More to come

There are so many commands to consider for BGP, we probably could have added close to 100, but we decided to list the commands we use most often to start with and will be adding to the list of BGP commands as well as other like OSPF, MPLS, and VLANs in future posts. 

Put 500,000+ BGP routes in your lab network!!! Download this VM and become your own upstream BGP ISP for testing.

[adrotate banner=”5″]

 

Happy New Year and welcome to the VM you can punish your routers with 🙂

Hello from stubarea51.net and Happy New Year! We are back from the holidays and recharged with lots of new stuff in the world of network engineering. If you ever thought it would be cool to put a full BGP table into a lab router, GNS3 or other virtualized router, you’re not alone.

A while back, I tackled this post and got everything up and running:

http://evilrouters.net/2009/08/21/getting-bgp-routes-into-dynamips-with-video/

First of all, thanks to evilrouters.net for figuring out the hard parts so we could build this into a VM. After basking for a while in the high geek factor of this project, it gave me an idea to build a VM that could be distributed among network engineers and IT professionals. The idea is to easily spin up one or more full BGP tables to test a particular network design or convergence speed, playing with BGP attributes, etc. After a few months of tweaking it and getting the VM ready for distribution, we finally are ready to put it out for everyone to use.

Network Diagram

Here is an overview of the topology we used for testing our full BGP table. This can be done a number of different ways and you can use just about any combination of Hypervisors including VM Ware and VirtualBox which are the two downloads included in this post. In this setup, we are using a MikroTik x86 VM to peer into the Ubuntu VM that has copies of the global table. It established an EBGP peering over 10.254.253.0/24 and takes in a full table.

BGP-VM-Network-Diagram

Getting started 

First you need to download either the VM Ware or VirtualBox OVA files and import them into your hypervisor. The setup and installation of VM Ware ESXi or VirtualBox is beyond the scope of this post, so please google it if you need help.

Downloads

Download .OVA for VM Ware

Download .OVA for VirtualBox

Powering up the VM

Once you have successfully imported the VM, you will get a screen that looks like this:

BGP-VM-Startup-page

Credentials

Here are the credentials which you can change if needed.

username: bgpuser

password: bgpuser

sudo password: bgpuser

Bridging the VM NIC to your lab network

In order to have IP connectivity to another router (physical or virtual) you will need to setup the VM NIC to connect to the network you want to test on. There are a number of different ways to connect VMs into a virtual or physical network.

VM Ware – we connected the VM to the default VM management network (which is a physical server NIC) so it could reach other VMs and physical lab routers

ESXi-vswitch

 

VirtualBox – we bridged the VM to the NIC of the desktop we are running VirtualBox on so it could reach other VMs and physical lab routers

VirtualBox-network-bridged

BGP Feeds that are used in this VM

The BGP feeds that are available come from the RIPE RIS Raw Data page and were archived in January 2016. We included 6 different tables from 4 continents so you can have up to 6 unique BGP tables to use in your lab testing. See the next section for the syntax to use for one of these files.

RIPE RRCFile Name
rrc00.ripe.netISP1-Europe-Amsterdam-Jan-2016
rrc01.ripe.netISP2-Europe-London-Jan-2016
rrc06.ripe.netISP3-Asia-Tokyo-Jan-2016
rrc15.ripe.netISP4-SouthAmerica-SaoPaulo-Jan-2016
rrc11.ripe.netISP5-NorthAmerica-NewYork-Jan-2016
rrc14.ripe.netISP6-NorthAmerica-PaloAlto-Jan-2016

Important Note !!!! – Using this VM does not provide connectivity to the Internet and will likely cause an outage when connected to a production network with live BGP peerings. This VM is intended to simulate an upstream peering for testing and lab development.

Setting up a BGP peering – BGP VM

Once you have IP connectivity and can ping the router you want to peer with, you can set up a peering on the VM. Here is the command syntax – first change to the bgp directory and issue the command below (with edits for your IPs and AS numbers)

Options for the BGP Peering (using the program bgp_simple ver 0.12)

Setting up a BGP peering – Your peering router

We used a MikroTik x86 VM in ESXi for this test, but any brand of virtual or physical router that supports BGP can be used.

Sit back and watch hundreds of thousands of prefixes torture the CPU of your router

MikroTik-VM-500k-routes