There are three steps to creating BGP filters in NSX-T:
- Create an IP Prefix for “ANY” and each tenant subnet.
- Create a IP Route Map
- Apply the Route Map to the T0 Router Uplink
An IP prefix list contains a single or multiple IP addresses that are assigned access permissions for route advertisement. If there are multiple IP addresses in this list are processed sequentially. IP prefix lists are referenced through route maps with in or out direction.
For example, you can add the IP address 172.16.10.0/24 to the IP prefix list and deny the route from being redistributed to the northbound router. This means that with the exception of the 172.16.10.0/24 IP address all other IP addresses are going to be shared the router.
You can also append an IP address with less-than-or-equal-to (le) and greater-than-or-equal-to (ge) modifiers to grant or limit route redistribution. For example, 192.168.100.3/27 ge 24 le 30 modifiers match subnet masks greater than or equal to 24-bits and less than or equal to 30-bits in length.
The default action for a route is Deny. When you create a prefix list to deny or permit specific routes, be sure to create an IP prefix with a blank network address and the Permit action if you want to permit all other routes.
- From your browser, log in to an NSX Manager at https://nsx-manager-ip-address.
- Select Routing from the navigation panel.
- Select the tier-0 logical router.
- Click the Routing tab and select IP Prefix Lists from the drop-down menu.
- Select Add.
- Assign a name for the IP prefix list.
- Click Insert Row to add a network address in the CIDR format. For example, 192.168.100.3/27.
- Select Deny or Permit from the drop-down menu. You grant or deny each IP address from being advertised, depending on your requirement.
- (Optional) Set a range of IP address numbers in the le or ge modifiers.
- Click Save.
- The newly created IP prefix list appears in the row.
I’ve been really lucky over the last few weeks getting to do some deep dive workshops on NSX-T and will be blogging a lot about the good the bad and the ugly over the next few weeks (really good timing for “Blogtober” right?!)
First things first the documentation, for the moment at least, is a little bit on the light side. VMware are obviously working on the documentation as I am starting to see some more become available in the public domain but it certainly wasn’t as well documented as other GA products.
This leads onto my first topic, as I think it’s quit a big one!
I’m going to post about the new routing and switching technologies/methodologies used in NSX-T as they are VERY different from NSX-V in the next few days but for now let’s assume there is a need to move away from the well known and loved Distributed Switch (start looking up the Opaque Switch). Put simply you can’t run a vSphere Distributed Switch on a KVM host, the price for delivering a Hypervisor agnostic SDN solution means we need to introduce a new type of virtual switch.
No big deal right?
First apologies for all the NSX quick short sharp posts recently as I was working through the blueprint for the VCAP-NV exam. I have been working with NSX everyday for the last year or so and decided it was time to get the VCAP-NV out of the way, unfortunately I decided to put myself under a load of time pressure as I booked the exam for about 3 weeks after I started to study… hence the multiple blog posts every night!
I have already sat and passed the VCAP-DCA so had a reasonable idea what the format of this exam might be like i.e. too many questions and not enough time 🙂 The exam system is based on the familiar VMware Hands on Lab interface which is a huge improvement over the last setup in my opinion. There are a couple of tips that are called out at the start of the exam which are well worth doing (setting the manual to float, changing the screen resolution, maximising the screen real estate as much as possible etc.) as the exam kit, at least in the exam centre I was, is still a single tiny monitor! Not what I am used to! Continue reading
This one stumped me for a bit (I also might have completely misunderstood it)!
In order to configure Activity Monitoring for a Security Policy I think we need to right click on the “Activity Monitoring Data Collection” Security Group and select Apply Policy:
From here we can apply activity monitoring to existing (or create new) Security Policy:
Configuring Network Introspection is identical to the Guest Introspection process in my last blog, difference being we need to create a service manager before hand:
To do this click on Service Definitions then Service managers:
Install Guest Introspection
Installing Guest Introspection installs a new vib and a service virtual machine on each host in the cluster. Guest Introspection is required for NSX Data Security, Activity Monitoring, and several third-party security solutions.
If you want to assign an IP address to the NSX Guest Introspection service virtual machine from an IP pool, create the IP pool before installing NSX Guest Introspection.
1. On the Installation tab, click Service Deployments.
2. Click the New Service Deployment icon.
Troubleshoot DHCP service issues
If you are troubleshooting make sure you have enabled logging and changed the mode to debug or error etc. This sends the logs to the syslog server configured for the ESG.
You must restart the DHCP service on client virtual machines in the following situations:
- You changed or deleted a DHCP pool, default gateway, or DNS server.
- You changed the internal IP address of the NSX Edge instance
You first enable the L2 VPN service on the NSX Edge instance and then configure a server and then a client. I’m going to try and use a Hands on Lab to spin up two ESGs and stretch a L2 network between them both.
You need to use the Trunk interface to setup L2 VPNs, so here are the steps for that:
1. Click on Settings tab. Click on Interfaces Select a vNIC and click on the pencil icon to bring up the Edit NSX Edge Interface wizard.
2. Enter an interface name then set Type: Trunk. Click on the Select link next to the text box for Connected To and attach the interface to a standard or distributed port group:
You normally download the Technical Support Logs from the Edge Services Gateway if experiencing issues.
Should you be running the ESG in HA mode the logs for both are downloaded at the same time. Select the Edge Services Gateway that you wish to download the Technical Support Logs from.
Right-click and select Download Tech Support Logs:
Once they are gathered click Download and then save them: