11. NSX-T Routing Protocols
Now, just bear in mind, the Tierzero Gateway is our north-south router. This is the router that’s going to form a relationship with the physical routers in our network. And so, how does it know which traffic to send to those physical routers? How does it learn routes from them? And how does it advertise routes to them? And the most basic way that you can set this up is with simple static routes. So with static routes, I’m going to manually configure my route table entries. And I may have something as simple as a default route out to the physical network. And the tier-zero gateway is going to automatically learn about routes from the tier-one gateway, so it will know about those internal networks inside our NSX domain. So setting up static routing is extremely simple and straightforward. BGP is not quite so simple, but it has the benefit of being a dynamic routing protocol. So that means it’s going to automatically learn about networks that are advertised by the physical router, and vice versa. It’s going to advertise networks to the physical routers.
And so now I don’t have to go in and configure my physical routers with routetable entries pointing at my NSX subnets. So with EBGP, this is external. That’s what the E stands for. So basically, there are two different flavours of BGP. There are external and internal externals. We’re using EBGP to dynamically learn routes from the physical routers and also to advertise our NSX networks out to those physical routers. We’re using IBGP between our edge nodes to exchange route updates between the edge nodes and the cluster. And that way, if one of the edge nodes fails, they’ve exchanged routing information. So the tier-zero gateway supports static routes, EBGPIBGP, and equal-cost multipaths, allowing us to have multiple paths out to physical routers that traffic can be evenly distributed across, which aids in failover. But just remember, ECMP is not compatible with stateful services like the NSX Edge Firewall. So let’s take a look at a diagram. And this diagram is from the inter-service routing section of the VMware NXT reference design guide.
So let’s just take a few minutes to break this diagram down and explain all of the little routing intricacies that are happening here. So number one on the diagram, you can see we’ve got two different physical routers, and both of these Tier Zero gateways connect to both of these physical routers. The reason for that is to provide redundancy in case one of these physical routers happens to fail. So both of these Tier Zero service routers are going to establish an EBGP adjacency with these physical routers so that they can exchange routing table information with those. And we may have situations like those we see here in the NSS design and reference guide, where we have different networks on both of those physical routers. So, for example, if physical router 2 were to fail, this particular network would become unavailable to us. So what we can also do is use something called IS-R Routing for what’s called an “asymmetric” topology like this.
And what we’ve got here are active service routers here. So we’re using equal-cost multipathing, and we’re not using ActivePassive, right? So both of these service routers are actively passing traffic. So in this case, we’ve enabled inter-SR routing. And there’s this automatically created overlay segment between the Tier Zero gateways. and we can see this automatically assigned IP address at each end of it. That’s where IBGP happens. There’s an IBGP session that’s automatically established between these tier-zero SRS. In addition, northbound routes are exchanged during IBGP sessions. So they’re basically learning routes from each other. So what we’ve primarily been focusing on so far is the service routers. Here. The service routers communicate with the physical routers via external BGP. They have internal BGP amongst themselves. And then down here, we see our distributed routers that are sitting on all of the transport nodes in our NSX domain. Those DRS have default routes pointed at these tier-zero gateways, these tier-zero SRS. So basically, the DRS don’t really differentiate between the SRS. The DRS basically have a default route to those SRS. So let’s walk through a scenario of something that could possibly go wrong here and why it’s important to have this routing topology set up the way that it is. So you’ve noticed that we have this corporate network here, right? Assume that the 192.168.1000 interface fails for our Tier 0 gateway on edge node one. Now, traffic destined for that 192.168.100 network may still hit this SR.
And in this case, this SR does not have a route that will actually work to get that traffic directly to that network. Well, it does have this automatically plumbed connection to the other service router, and this other service router does have a viable connection to that network. Stone, so that’s one of the points of this automatically-plumbed IBGP connection between the two edge nodes: to give us this higher level of availability in the event that one of our physical interfaces fails. Now, before we continue to delve into dynamic routing, I do want to take a couple of moments and talk about static routing. So here we can see a services router where we have two physical routers connected, and those two physical routers, let’s say, give us access to identical networks. So the whole point of these two physical routers is not to give us two different sets of networks; that’s basically our northbound connectivity for everything that can go through either of those physical routers. So if I’m using static routes, I may want to load balance and give myself fault tolerance across those two physical routers.
And ECMP is supported with static routes. I can use equal-cost multipathing to distribute traffic across both of these physical routers. In the event that one of these physical routers fails, I will still have a static route in place here, pointed at the other physical router, so that my traffic will continue to flow even if one of those physical routers fails. And the way that it’s going to distribute traffic is based on source and destination IP addresses. So traffic for one source and one destination will go out this interface. Traffic will exit the other interface for some other source or destination. Now, let’s wrap up this lesson by talking through some of the BGP features that are supported by Nsxt 24. Route aggregation with BGP is supported, and this gives you the ability to advertise a summary route to the BGP peer or advertise a summary route as well as more specific routes. But basically, if you have a bunch of contiguous subnets that could be advertised by sending only one route instead of many routes, then route redistribution can be used to simplify your route table.
And if route aggregation itself is a topic that you’re not really familiar with, we’re not going to get too deep into it here. I would suggest checking out some YouTube videos or something like that to learn a little bit more about route aggregation. Also supported are BGP community lists. And basically, a BGP community is some extra information that you can add to prefixes when they’re advertised to BGP neighbors. And so, for example, you can have a BGP community for the Internet, a BGP community for routes that should not be advertised, or a BGP community for no export if there are certain prefixes that you do not want to export to any exterior BGP neighbors. And so yeah, BGP communities are supported with NSX Two Four as well. IP prefix lists are a way to identify IP networks with subnet masks that are either going to be permitted or denied based upon a match condition. And so IP prefix lists are used in BGP filters or route maps.
You’ll specify either the inbound or outbound direction, and the prefix list essentially controls which networks should be advertised out and which networks should be able to be advertised in. And route maps are going to match routes based on those IP prefix lists or based on community lists. So depending on whether or not a routematch matches an IP prefix list or a community list, you can allow or block route redistribution. You can set BGP attributes like weight, like a multiexit discriminator, and things like that, and then finally allow the autonomous system in. By default, BGP drops routes that it receives if those routes contain their own autonomous system number. and this is done to avoid routing loops. So if you’re a single customer with two sites that are interconnected to the same ISP, you may receive routes from a BGP peer that’s on the same autonomous system number. So you can configure this BGP allow ASN if you need the ability to accept those routes.
