Friday, 17 July 2015

Configuring OSPF / BGP Authentication within NSX and RouterOS

A little tip Andy Kennedy (Twitter) gave in one of his internal presentations was to use authentication when configuring a routing protocol during a Proof of Concept to avoid redistributing routes into a production environment in the event of a misconfiguration.  This is just a quick post to show you how to configure authentication when using OSPF and BGP within NSX and RouterOS.  My lab environment currently looks like this:


I have OSPF configured between my DLR (PA-DLR-01) and my Edge (PA-EDGE-01) and BGP between my Edge (PA-EDGE-01) and my physical router (Mikrotik) which runs RouterOS.  To configure OSPF authentication on the DLR simply fire up the vSphere web client and navigate to Networking & Security -> NSX Edges -> DLR you want to configure -> Routing -> OSPF and then modify the area definition.  Change the authentication type to Password and then enter a password, click OK and then publish the changes:


At this point routes should stop distributing into the Edge as we need to configure the same password on the Edge (PA-EDGE-01).  Once configured on Edge routes should start populating again.  We can also run a show ip ospf interface on the edge and see that authentication is enabled:


To configure authentication for BGP on the edge navigate to Networking & Security -> NSX Edges -> Edge you want to configure -> Routing -> BGP and edit the neighbour you want to configure for authentication.  In the password field enter the required password, click OK and then publish the changes:


Route distribution will stop from the Edge into the physical router and vice-versa until we configure authentication within the physical router.  To do this is RouterOS simply log in and navigate to Routing -> BGP -> Peers and modify the Edge peer.  Within the TCP MD5 Key field enter the same password you used on the Edge and click OK:


Once you do this routes should start redistributing again.  Now if the Edge uplink interface is accidentally connected to the wrong VLAN backed portgroup with a physical router with the same neighbour IP address we will not accidentally redistribute routes into the production environment.