BGP Route reflectors - BGP In Depth 6

well guys this is Joe Neville and welcome to this video on BGP route reflectors I feel like I should have one of those TV style introductions previously on BGP in-depth because this video follows on closely from my previous two videos dealing with the theme of loop prevention in BGP video for a discussed ebgp using a s path to stop prefixes looping in a network then in video 5 I looked at IV GP and explained why full mesh doesn't scale and how BGP route reflectors can help him if you haven't watched those videos I recommend that you do so links in the description because rather than just talking about route reflectors it will help you more I feel if you understand why are they used in the wider context of loop prevention so a quick recap about ibgp rules no ibgp learnt prefix is advertised to an eye bgp peer this leads to the requirement of having a full mesh of ibgp peers and what do we all know about full mesh networks they do not scale now route reflectors can help here a root reflector is just a bgp speaker in an eye bgp network it has ibgp sessions to clients and non clients so this is a new designation within the bgp network these are configurable status but they are local only to the root reflector so the clients and the non clients they do not have any configuration on them that designates that they are connected to a root reflector it is just from the point of view of the root reflector with that in mind a non client is just a normal eye bgp configuration between the client and the rig reflector but a client is an eye bgp session configured as normal but with this additional command p and then the IP address of the peer reflect client and the root reflector breaks those ibgp rules for propagation of prefixes we will advertise from our root reflector e bgp learn prefixes so that standard ibgp learned prefixes from clients and non clients so this is the special rule here for route reflectors it will reflect ibgp learnt prefixes but I should just reiterate that no non client to non client ibgp prefixes are reflected that's important to remember what does this mean then have a look at this network here it's an eye bgp network with six nodes without route reflectors that would mean 15 bgp sessions would need to be configured for the full mesh now with the route reflector because the route reflector will reflect the prefixes between its clients and non clients the nodes only have to peer with the route reflectors so with six nodes as you can see here we only need five bgp sessions so a dramatic reduction in the amount of configuration are the administrative overhead and the number of sessions that we need in this network obviously the relative savings in overhead are increased the more notes that you have in your network but one issue with this type of network having a single route reflector is not really recommended because that's a single point of failure so we normally have redundancy and we can have two route reflectors and our clients and will be configured to peer with both of those in this six node network with two route reflectors we're still down from our 15 bgp sessions that we would need to full mesh and we're down to nine bgp sessions so you can see the saving there my route reflectors have been getting quite a bit of press recently is you've probably heard about leaf spy networks they're all the rage in data center networking at the moment and route reflectors an able manageable ibgp design so you do not have to have your leaves peering with each other the leaves can peer with the spine switches if the spine switches are route reflectors then the leaves will learn about all of the neighboring leaf prefixes let's get into the then here's the network that I will be showing you root reflects your configuration using vs ours on my laptop as usual I've got 4 vs ARS in a single a s and I've got this other one here vs r2 0 1 in a different a s so we've got ebgp between vs r2 0 1 and 1 0 3 I'm going to configure this vsr-10 3 as the root reflector so that's going to be the heart of our network then I'm going to have two clients for your cell 1 0 1 it's going to be a client vsr-10 2 is going to be a client they are going to form a cluster it's called and then we're going to have vsr10 4 as a non client each one of the devices in the network except for vsr-10 2 are injecting a local prefix into the network and we're going to check what configuring a root reflector in the network does to the BGP routing tables here I have three SSH sessions two devices in my network top left I've got vsr-10 3 that's going to be our root reflector then bottom left I got vsr-10 2 which is going to be a client in my cluster and top right we've got vsr-10 4 which is going to be a non client so let's start by looking at vsr-10 threes BGP configuration as you can see there we've got a Rooter ID and we've got four sessions for BGP and then those are turned on they're enabled within the address family for ipv4 unique ours and we're injecting via Network statement this local network 172 dot $30.99 / 24 so nothing in there at the moment which designates that this is a root reflector down here on vsr-10 - let's have a look at the BGP configuration not much to see we're not injecting any prefixes there's nothing on there that suggests that we're going to be part of a cluster or anything like that we've just got an IB GP session up to vsr-10 3 so let's have a look at vsr-10 2 bgp routing table so nothing configured for route reflectors or cluster at the moment what we have here is two internally lured BGP prefixes we can see that we've got this 192 168 99 as we would expect so that's coming across from vs r2 0 1 across the ebgp and then vsr-10 3 is advertising that on now that is in a line with standard BGP because it's an e BGP learnt prefix that is then going to be propagated via ibgp so nothing new there we also have this 172 30 99 / 24 now that's injected by vsr-10 3 so that also adheres to standard ibgp advertisement rules as we would expect what we're not seeing on vsr-10 2 is this network that's been injected by vsr-10 1 this 170 2.30 1/24 or the network that's being injected by vsr-10 for this 172 30.4 / 24 Network now if we can figure the vsr-10 3 as a rude reflector we should see these two prefixes in vsr-10 2 because the Roode reflector will break the standard ibgp rules about propagating ibgp prefixes and it will reflect ibgp learnt prefixes from clients and non clients down to its clients now let's add that configuration to vsr-10 3 we go into the address family pick the peer doing vsr-10 1 first and it's this reflect client command down do the same for 1:02 because I'm in the lab to speed things up I'll just reset the sessions the backup it's all established so let's go back and look at for your sub one zero two speed EP table so we can see what it was like before we just had these two or expecting more nell and there we go and we do have these new prefixes the 172 30.1 slash 24 and 172 30.4 slash 24 those are the ibgp learnt routes that are being reflected from the route reflected down to the client nothing particularly interesting going on just looking at the table like this but let's take a look at the specific prefixes if we look closely we can see we've got two new BGP attributes in the update we've got this originator and we've got the cluster list to explain that further the originator ID and coming from the RFC four four five seek because we love to quote an RFC the originator ID is created by Roode reflector in reflecting a route so it's added by the route reflector when it does the reflection this attribute will carry the BGP identifier of the originator of the route in the local AAS a Rooter that recognizes the originator ID attribute should ignore a route received with its a BGP identifier as the originator ID so essentially it's a loop prevention mechanism because we have loosened the rules on forwarding ibgp prefixes thus there is the possibility for miss configuration of read reflectors which would create a loop we obviously don't want that so we have introduced new BGP attributes to stop that and something that's quite interesting about this is that the attribute is the BGP identifier of the originator of the route so it's not like it's the next hop or anything it's the BGP ID of the routed that originally injected the route into the network let's take a closer look now if we concentrate on another prefix this 172 34.0 this is injected by vsr-10 for that I've got top right here it is the BGP route or ID is 4.4.4 dot 4 that's advertised across the vsr-10 3 if we look at that prefix in vsr-10 threes BGP routing table you can see there's the next hop but they're attached to it is the BGP routes or ID and then if we follow that down so where it's reflected down to vsr-10 2 you can see that the originator ID is the original BGP local router ID from vsr-10 4 because that's the device that injected the prefix into the network so if vsr-10 4 receives this prefix back with its own originator ID in it then it should drop it thus preventing loops here we can see an illustration of the originator ID if a prefix got sent out and route reflectors from misconfigured in the network and they were reflecting the route rounding and loop then it would drop when it was received with the local route reflectors originator ID within the BGP update now let's look at the other BGP attribute which is new to route reflectors and that is the cluster list so another RFC quote and it reads when a route reflector reflects a route it must prepend the local cluster ID to the cluster list using this attribute a route two can identify if the routing information is looped back to the same cluster due to a Mis configuration if the local cluster ID is found in the cluster list the advertisement received should be ignored so it sounds very much like AAS path being added to an e BGP prefix we add in a cluster ID that becomes part of the BGP update if it lose background into a cluster then it should be dropped and thus preventing loops here's an illustration of that we've got two different clusters we've got rude reflectors configured cluster one originates a prefix which goes out to cluster two but then gets looped back gets reflected back into cluster one where it will be dropped because cluster one's cluster ID is part of the BGP update the rubra flex will see that and drop it looking back at vsr-10 two we can see the cluster list of three three three three now that's the local Rooter ID for vsr-10 three so that becomes by default the cluster list ID but you may be thinking what if we've got to route reflectors in our cluster what will be the cluster ID because if by default we take the BGP route ID of the reflector if we got two reflectors obviously we're going to have two competing IDs so what we actually have here is we have a command which can configure a cluster ID on a device so both of these route reflectors if we add in this reflector cluster ID number it doesn't need to be an IP address it can just be any number to ID the cluster that will be used instead so this is the recommended configuration if you've got more than one route reflector and if we take a quick look at the configuration on vsr-10 three we can see here the reflector cluster ID and we can add in we can use the format of an ipv4 address or we can just put in a number like so okay that was a quick overview of BGP route reflectors in the wider context of BGP loop prevention I hope you found that useful if you did please like comment and subscribe to the channel plenty more BGP and IP routing videos coming up but that's all for now thanks for watching my name's Joe Neville and goodbye

Channel: Airheads Broadcasting

Views: 30,159

Keywords: bgp, ip routing, networking, how to, tutorial

Id: RKJD5d-Ml9Y

Length: 16min 10sec (970 seconds)

Published: Wed Sep 14 2016