166 IPExpert BGP Peering ebgp and ibgp

[Music] in the next video we are going to talk about bgp peering and here we are going to talk about the external and internal BGP peering sessions we are going to examine in detail the neighbor formation we are going to examine the different kinds of messages and keep lives that BGP sends we are going to talk about the external BGP and the rules that govern the behavior of external bgp peering we are going to talk about the behavior of BGP inside the AAS so we are going to talk about the ibgp as well and finally we are going to briefly touch upon the subject of scaling the ibgp sessions am scaling the capabilities of our internal BGP routing unlike pretty much any other routing protocol that either uses UDP for exchanging the information or uses its own IP protocol BGP is actually just a TCP application and it's a TCP application that actually operates on port 179 so port 179 is a well known port used by BGP so when BGP neighbors are configured and let's say that we want to establish the BGP peering session between two of our neighbors the first thing that needs to happen is this TCP session here needs to be established once the TCP or the transport session the control session as BGP calls it has been established BGP is going to start exchanging BGP messages to form an actual application relationship BGP uses for messages open update notification and keepalive messages open message is used initially when peers are establishing the connection to send the locally configured parameters like what is my own AES number what are the values of certain timers and so on so this is the initial hey let's talk let's peer message the update message is the message that will either add routes to the routing table to the BGP on the remote host or will instruct the host on the other side to no longer use certain routes so if we are adding routes we are going to have those routes with their attribute sent in the network layer reachability information and if we want to remove them they will be listed as the route to be withdrawn notification message is used by BGP when an error condition is encountered now keep in mind that the quotes error condition might be simply a neighbor signaling the other neighbor to cease the session so it's perfectly normal to tell the other neighbor hey let's stop peering but there is really no error condition or if any error condition is encountered one neighbor will send a notification message to other neighbor which is simply a deep hearing message it means okay let's stop this session so we can think of open message is where the relationship begins and the notification message is where the relationship between two routers end in the meantime if there are no updates to be sent or no notifications are being sent the keepalive message are periodically going to be sent to signal the neighbor on the other side that this connection that this TCP session is still alive BGP is really using these key pipes as its own form of the hello protocol which is used by so many different protocols now the next thing that I would like to talk about is the BGP finite state machine how does the BGP session form what are the steps and processes that happen on the local router and between different neighbors when the session is being established bgp finite state machine is a series of steps that every configured bgp router sometimes called bgp speaker needs to go through every time it attempts to establish a bgp relationship and neighbor ship relationship with another bgp speaker with another bgp configured router these steps are defined in the original BGP RFC which is 1771 so in BGP 1771 you can see all these steps I believe it's in section 8 of that RFC but don't hold my word for it the first step the first stage of this finite state machine where the whole process begins is the idle State RFC specifies that in this state all incoming BGP connections to port 179 should be refused and it for this particular neighbor no resources should be allocated no system resources that basically means memory is being allocated for this particular neighbor I should point out that in Cisco IOS this idle state might be just a little bit misleading when you do the command show IP BGP neighbor you're going to see the all sort of states that we have for that neighbor what version of BGP we are running what is the remote neighbors IP address how many messages we have sent how many messages we received and so on so on and at the very end of the output we are going to see the state in which we are with this in relationship to this neighbor basically we're going to see one of these states there sometimes you might see that the neighbor says idle when in fact iOS is behaving as if it was in idle connect or actually in active states what do I mean by that what I mean by that is that you can see the neighbor that is actually in the idle state but then there is a start event that happens now what is the start event it can be a large number of things start event could be you as the operator giving the router a particular command to start establishing the connection with the neighbor now in iOS there is no direct thing that is that is equivalent of this but RFC says that there is such a thing as the start event so maybe some other vendors have the ability for you as the operator to say okay I want to start establishing the connection with this neighbor right now in iOS the start event is really the connect timer expiring which is an internal timer that you have very very control of a connect timer expiring and then the router is going to transition into idle connect or active States or it could also mean that there was an incoming connection to port 179 from a configured neighbor which in iOS is going to trigger the start event and even though the router was in the idle State it is actually listening on this port so not all connections are being refused and the router is going to transition into connect and later to active States so what is happening in these connect or active States well in connect state the BGP engine is waiting for the TCP session to establish we know that there is that three-way handshake so there are certain things that need to happen before BGP can start operating once the operating system the iOS signals to the BGP process again in iOS that the connection that the TCP session has been established what is going to happen is the router is going to transition into the open sent State now if the timer the connect timer expires and there was and there was some problem establishing the TCP session it might have timed out or there is maybe authentication problem or something the router is going to transition into active State basically in active state the router is either actively initiating the sessions and is also listening for the incoming connections to arrive so when you see active in BGP when you are looking at the output of scishow ibgp summary active is usually not very good it's a transient state you really don't want your routers to be there for a very long time but now let's say that actually there was a transition to open send that we actually did successfully form the TCP relationship in open send that means that we have sent our open message and you remember what the open message is and we are now expecting to hear an open message from peer again this is a transient state and if this fails for whatever reason the router is going to go to idle and then it's going to start going through this process again now if we actually have received an open message from our neighbor we are going to move on to the open confirm state open confirm basically means that we have sent our own keepalive and we are also expecting to see the keepalive from one neighbor if you receive the keepalive which is basically an acknowledgement of our own open message just the same way our own people I was an acknowledgement for the neighbors open statement if you receive the keepalive message the router is going to transition into the established state this means that only the key lives and updates are going to be exchanged or notification messages if something is wrong so really this is a bgp finite state machine this is how the neighbors are formed once we configure the neighbors let's see this in action and to do that what I'm going to do is I'm going to use the network that we already have I have two routers r1 and r2 that are directly connected on gigabit one and the network between them is 192 168 12 0/24 dot one here dot two here and our one is configured in a s 65,000 1 and r 2 is connected configured in a s 6 5 2 3 4 and there is a direct period between them on gigabit one configured now what I have done is I have shut both of these interfaces down on both r1 and r2 and what I'm going to do is I'm going to connect my Wireshark here and we are going to tap into the communication between r1 and r2 as they are forming the relationship and let's take a look at how that goes I'm also going to be running some debugs on r1 to see all these states that I talked about as they are happening so going to r1 what I'm going to do first is I'm going to say debug IP BGP and then I'm going to specify the neighbor 192 168 12 2 so now I'm going to be seeing all events as they are happening in regard to the neighbor 192 168 12 2 also what I'm going to do is I'm going to go to my Wireshark I'm going to start collecting the data here but I'm interested only in seeing TCP or BGP traffic if there is no other TCP traffic between them this will only show me the BGP traffic as it is happening now why am I saying TCP or BGP here well if I said only BGP I will see only the actual protocol as it is happening so pretty much I'm going to see events starting with an open message but before that happens there needs to be that TCP session that forms that's not technically speaking bgp protocol vignette BGP starts with an open message there is nothing DGP about that TCP session prior to BGP sending its open message and Wireshark knows that and it's good thing to see that actually you know what I'm going to start by just capturing the BGP traffic and then I'm going to add the TCP so you can see that extra traffic it actually makes more sense to do it that way so what I'm going to do next as you can see now the debug has been enabled and on r2 I'm going to say show IP BGP summary now what we are seeing here is that labor 1 to 160 a 12-1 or r1 is in idle state if I go to r1 and if I do the same thing show IP BGP summary I am going to see here that the neighbor is also in idle State so in this state here there should be really no events going on so let's go to r1 and let's say interface gigabit 1 and I'm going to say no shutdown let's see if this changes anything well it won't change anything immediately the it's going to take some time for to start sending messages so we can see now that bgp is restarting we can see here actually that we had an indication that the active open has failed why did active open fail when we were not even in the open state remember what I told you this idle indicator here may be a little bit misleading in iOS what is actually happening is that 192 168 12:1 is now attempting to connect to this network here but because the interface is shut down on the other side that is failing so let's bring that interface up now here in Wireshark if I add just a TCP actually I will I will not see it let's see if we can now we don't we don't have any TCP traffic going on and the reason why we don't have any TCP traffic going on is that we really don't have any ARP entries for two here so our one cannot really form this session so it's not even sending the TCP packet let's bring this interface out of shutdown now so at this moment here let me you know what I'm going to remove myself here so that you can see the fullscreen oh there we go now something is happening here and if we go to our Wireshark we are going to see here that now we have the open message has been sent we have keeper lives and so on but let me show you that other thing that I was talking about so this is BGP or TCP you see here before the TCP before the first open message was actually sent an exchange there was an initiation of the communication there was the TCP syn was sent then there was a syn ACK and then there was AK there is the three-way handshake right here you can see it so that was happening while the router was in India Connect state once that has been completed once that session has been established the router has actually moved to open sent and this is where the open messages started sending now incidentally here it was 12 - that was the first one to send the open message we can see that because this is the source and this here is the destination but here we can see the open message so here is the open message from r1 to r2 so let's see what our debug told us there I'm going to scroll first of all let me turn off the B bugs so I'm going to scroll up and let's take a look at what happened here so let me see where did I get the first indication in the debug there it is so here it says passive open to 192 168 12:1 now what that passive open means is really that it was our two's active act of initiation that is going to trigger the active event and we can see here now that we are moving from idle to connect as the result of getting the peer from TCP now TCP is an internal iOS indicator of the TCP sessions established by the router into the router it stands for transmission control block and you can see at i/o s level so I'm just going to show you that briefly show TCP brief you can see here the actual session between our two and we can see that there was a random number in use here and that it was a well-known number on our side which means that the TCP session actually formed in this direction and we can see that from TCP perspective this is how it is seen so as far as TCP is concerned this is in an established state this is a TCP this is a unique identifier inside iOS that identifies this TCP session at the operating system level and if you wanted to destroy this session not through BGP but actually at the TCP level you would run the command clear TCP PCB and then you would enter this number and iOS would kill and destroy this session we are not going to do that now because we actually want to go through app through this debug a little bit here so we can see here that for it went from idle to connect which is exactly what we are expected and then we can see that there are certain events field that happened so what was setting open delay time or whatever it is so basically it means that we are going to wait for 6 seconds before we send our own delay but in the me before we send our own open but in the meantime we have actually received a message it says here we receive the message of type 1 which is really an open message and then this is here where the open message gets decoded it says here that it it is a version for the whole time hold down timer has been set 280 seconds the it does have some options options are really additional capabilities that router is able to perform like for example a route refresh or the outbound route filtering or it could be the multi address family etc so all these all these capabilities are going to be decoded here but that's not the most interesting thing that we are interested about the next event that we are interested about or interested in is this bit here basically says that we are now sending our open and here we can see that we have switched our state from connect to open sent let me disappear here so we can see here that we have went from connect state to the opens and why because we have sent our own open now because we have actually received already and there it is we have received the open we are immediately going to switch to open confirm state because we are just expire to get the keeper lives and we are sending our own keeper lives that event did happen and here we can see that we have now switched to the established state now one more thing that I would like to point out here it says that our active open has failed well it has failed because all this here was the result of an incoming session here our outgoing session is not no longer needed so we are basically saying here okay it it did fail and we don't care about that so that particular our attempt to establish the active connection has failed and after this has happened after we have established the session after it has formed if we take a look at show IP BGP summary now what we are going to see here in the state we are no longer going to see that it was saying idle or connector open confirm good luck by the way catching those transient state here the only one that you are most likely going to see is active and that's when something is wrong now when the actual BGP relationship is in an established at when the finite state machine is in an established state you are going to see the number of prefixes received from the other neighbor let's now take a look in our Wireshark how all these things look like so what I'm going to do now is I'm going to just remove the TCP I'm just going to leave the BGP in place so here is the open message that triggered all of this stuff we can see it came from 1212 - there it is it came from 12 - and 22 12 1m here I have already open the the BGP thing the important parts of the open message are what is the a s number of the transmitting host and we know that this was r2 here so we are going to see that this was 65 2 3 4 we can see the hole down timer we have already seen that in the debug and we can see here what is the bgp router ID then there are optional parameters and these optional parameters are really those capabilities that i mentioned like for example the multi-protocol extensions capability that's supporting multiple grass families we can see route refresh capability and there to two of them differently identified then there is going to be some unknown capability whatever that might is could be something Cisco internal and then we have the support for the four octave the 32-bit AAS numbers so all these things here are seen in the open message here in the open message from r1 to r2 we pretty much have the same parameters then we have keepalive messages here that are being exchanged either on a regular scheduled basis or as the result of confirming the open message this is when we switched into the open confirm state and finally here we can see that there were the update messages being sent so we actually have some routes being exchanged so here we can see loopback - of r2 being advertised and we can see here that no routes are being withdrawn so this is unfeasible route length here so and we are going to see keepalive messages sent there keep lab is always sent as an acknowledgment - when we send the update we respond back with a keepalive and the kippah labs are also periodically sent which we can see here so really this was the BGP finite state machine we are now going to start taking a look into bgp peering sessions and how they are different when the peering is external that means between the neighbors that are not in the same a.s and the internal peering sessions i'm going to start with the easier one with the external bgp for appearing to be considered an external bgp peering what needs to be true is that the neighbors that are peering needs to be in different autonomous systems that means that if we had two routers let's say our r1 and r2 when we configure the peering between them if they are not in the same areas like in our case we have sixty five thousand one and sixty-five thousand two three four these two routers will be considering this peering here external peering that means that the behavior they are going to exhibit on this peering session the default behavior they differ Paul the requirements they are going to be those of external peering session so what are those peering rules neighbors should be directly connected now please take note of should this means that this is presumed default behavior but it doesn't have to be this way we can have external peering between neighbors that are not directly connected however if this is true there are some configurations some extra steps that need to be taken first of all we need to have some sort of an underlying reachability protocol if the routers are not directly connected and we want to have peering between them let's say that you wanted to peer between our r1 and r3 through this router whatever it might be here and we wanted to peer between these two somehow this router here would have to know how to reach this router here and this one will need to know how to reach this one here but there is another situation in which we have bgp peering between non directly connected neighbors and while they may appear to be directly connected let's say that we had two routers that we wanted to peer between the loopback interfaces here these loop backs here are not directly connected these interfaces here are directly connected so we can still have a BGP peering between these two routers but they are not directly connected this is not an uncommon set up and it does have some dangers associated with it this underlying reach ability between these two loop backs can be accomplished using static routing or using IGP well in some advanced cases we can use BGP over BGP but I'm not going to talk about that that's that's not very very common configuration now if we have static routes here as an underlying routing protocol there is really no danger we are simply going to have a static route that is going to say that this loopback is reachable through this interface on this router here and this is done we are going to have the exact opposite on this router and this is it however if you used an AGP as an underlying routing protocol to provide the reach ability between these two loop backs we might have a problem if the same loop back ends up being advertised in BGP because remember the admin distance of external BGP is 20 and this is lower than pretty much any of the IDPs that means if we learn this loop back here in a BGP we are going to prefer that route over an IG P learned 1 now why would that be a problem well to understand why that would be a problem we need to take a look at what are the default policy behaviors in external BGP what I mean by default policy behaviors is what is going to happen with the route that we have learned say from internal neighbors from other external neighbors how are we going to process them where are we going to advertise them by default and are we going to update and change any of the attributes by default most of these things can be changed can be overridden by settings in either route maps on our direct neighbor sessions and we talked about changing these attributes before but this is the default behavior that I'm going to talk about the first one and the most important one is the next hope attribute and you might remember that this is probably the most important attribute in BGP in a sense that if next-hop is not reachable in the routing table the routes are not considered to be the best or cannot be considered to be the best so why would for example this be an issue with this configuration here well if we have the router here and let's say that this is our r1 and r2 and we want to peer instead of direct connections we wanted to peer between the loop backs and let's say that just for fun we ran OSPF as an underlying protocol what we're going to do here we are going to advertise the loopback of r2 in OSPF and r1 we'll learn it with the admin distance of 110 which is fine now when this look back here gets advertised in a BGP this is going to be now learned here with the admin distance of 20 so this route will disappear from the routing table and this one here goes into the routing table so what does that actually mean well that we're going to have the route that this loop back here is route reachable with the next couple VAR to but what is going to be the next cut well it is set by the advertising router and by default unless we change it in any way it will be whatever is the peering address whatever is the update source and the update source on our ebgp peering is the loopback itself so we are going to have information that loopback is reachable through the loopback which if we recursively look up is going to be reachable through this so we are basically going to have a local routing resolution problem on our one the problem that is commonly called as recursive routing that route is reachable through itself in other words what we are going to end up with is a valid route in the routing table which is going to satisfies the requirement of a valid reachable next hop however it is not actually reachable by traffic because it leads back to itself so in effect the peering session between r1 and r2 is going to become ineffective now given the default hold time of 180 seconds in iOS this means that this BGP session here is going to remain up for three minutes before routers notice a problem then after three minutes this peering session is going to go down this route is going to disappear from the routing table and this one is going to make a comeback when this route comes back r1 and r2 can communicate the BGP session forms again the e BGP route gets advertised and the same problem repeats itself now I know that this might be a little bit too much - to understand just on the this imitation whiteboard so let's take a look at this one actually in iOS I want to show you this particular issue for that purpose I am going to use two different routers I'm going to use my r5 and r6 and they're going to be interconnected on gigabit interface tree and the metric between them is going to be wanting to do one 6856 0/24 and I'm going to have dot 5 here and dot 6 here I will have a loop back on r5 and r6 and the address you will be wanting to do 168 0.5 / 32 and on this side I will have 1000 6 / 32 I want to run a routing protocol between r5 and r6 and advertise these loop backs into this routing protocol and I think that the easiest and the fastest one to run would be e IG RP so I'll run ARP 56 between them and just for fun I'm going to configure it using the new named mode because that's where things are going and then we are going to establish ebgp peering session between them so what I'm going to have here is my r5 here is going to be in a s sixty five thousand five and my r6 will be in sixty five thousand six so I want to establish the peering session the external bgp peering session between these two loop backs so let's get to the terminal and take a look at this and you know me by now I'm not going to start configuring anything unless I have the connectivity so I'm going to first start from r5 I'm just going to say show IP route connected what I'm looking for here is the 56 Network and what I want to do is I want to be able to ping 56 6 on that network and it seems that that was a success so on our six show IP route connected I want to make sure then I can spin 56 five and I can also observe that I do have looked like configured on our six and that I have the correct address there and I can see pretty much the same thing on our five there is a loop back and it's 192 168 0 5 now let's configure a idrp so the first thing that I'm going to do here is router ei GRP and I'm going to give it some name and let's you know call it by our AES number so it's going to be 65 thousand five and here I'm going to say address family ipv4 autonomous system and I have to share the autonomous system between r5 and r6 for a year GRP I'm going to make sure that there is no actually to configure elsewhere in this case so I'm just going to make sure that I don't create out of summary and just a quick reminder here so this is going to be in topology base and I'm going to say no Alto summary here and then I'm going to say network went to 168 56 0 so I want to configure it there and I want to make sure to advertise my loop back into the EIGRP so if I do show IDE idea interfaces this is what I want to be seeing now if I do show run section router ERP this is pretty much what I can copy/paste to the other side so I'm just going to do this one here then I'm going to copy paste this actually topology Bay is just going to make sure that no auto summary is configured going to run this network here and network 1000 0 6 0 0 0 0 and I can see that the neighbor is already up so if I go to our 5 show IP route the idrp I should be seeing the loopback of our 6 and on our sex show IP route ei GRP I should be seeing the loopback of our 5 so if I ping our file with the loopback of 0s source from our 6 I should be getting the responses and the same thing here so our slope back 0 I'm getting the responses so I do have my ERP ready now so let's build bgp i'm going to start with our 5 on our 5 I'm going to say router bgp 65 5 this is what our AAS number is I'm going to set the bgp route ready to be 192 168 0 5 this is optional I don't have to do it I'm also going to say bgp operate CLI because this is what I like to do and I'm going to say neighbor one into two months ago actually its neighbor 10000 six remote a s sixty five thousand six and here what I need to do is I need to say that I want to send my open messages from the loopback interface and I want the TCP session to be formed from the loopback interface now by default because there is that requirement that external neighbors are going to be directly connected what is going to happen here these messages are not going to be sent out they are not going to be sent out because BGP expects to have a directly connected neighbor in this case our neighbor is not directly connected because the peering will be between the loop backs now because our five and our six for that matter will expect directly connected neighbors this message or this TCP session will be attempted to be established with the TTL set to one on the IP packets now if the TTL is set to one it will never reach our sex because it needs to go from loopback to this interface and TTL will be decremented at that point so we cannot send the packet with TTL zero our five knows this so it's not even going to attempt now we can change the behavior of this TTL and we can relax it we can set it to two three five or whatever or we can simply set it to 255 and tell our five establish the session with our sex anyway you know and this is something that we can do if we simply say ebgp multi-hop here on the neighbor statement we can specify what our hop count is going to be if we don't specify it it will be 255 so now if I do show IP BGP summary I'm going to see that the neighbors are idle at the moment but very very soon we might actually see this change state to active but while we are waiting for that let's go and configure our six again I'm going to do a little bit of copy pasting here what I can do is well I don't have much copy paste so let's start from scratch so here I'm going to say router bgp 65 six and I'm going to say BGP route riding 1000 six and I'm going to say BGP upgrade CLI because I like the new format then once a neighbor wanted to do one sixty eight zero five remote is sixty five five update source to look back zero and we are also going to say a BGP multi-hop here and we can see here that the neighbor is coming up or actually it's not coming up it says it's in a wrong guess oh my goodness what did I do wrong let's see show run section router bgp 6505 oh s i have configured here the neighbor to be in up in my own area so i'm trying to configure this as an internal session but you know what i honestly made this mistake but it's actually not that bad that I made a mistake if you make a mistake like this this is what you can expect you can see that iOS is very very loud about that thing now one thing that I want to show you here is this error message here now with this error message here we are telling our neighbor that hey you are in the wrong AES I'm not expecting you here now with this message here we can decode what the neighbor was configured to be in so let me let me show you how you can do that so what I'm going to do here is I'm going to see to start my calculator I've been just finally because I don't often use it there we go here is my calculator and I'm going to switch it to a programmer mode in this case and this number here these letters fde these are actually hex numbers of the area so if I confirm this here if I change this to ten I can see here that I'm telling my I'm telling the neighbor hey I can see you configured in 65 oh six now see what is happening on our six side here we are also sending their application do they make mistake on both sides this would be silly no I did not so here's some where we should actually be seeing a slightly different error message let me see if maybe it's somewhere down I'm not seeing it yeah let me see that configuration again I want to see the section router bgp this one sixty five five this one sixty five or five so yes exactly that's that's what I'm seeing so here apologies so on our five we have configured our six as if it was in $65,000 five so I just misread that message there now our six on the other hand was configured properly to be in sixty five thousand six so what we are seeing here with this error message is we are telling the neighbor hey you are configured in the wrong guess and this is the a s I am seeing from you the router is basically with this lock message telling us as the operator that we may have missed configured the neighbor say s which is exactly what I've done this is an incorrect configuration this should be sixty five thousand six so let's go ahead and fix it so I'm going to go in into this router bgp i'm going to remove this neighbor i'm going to add it back now with the correct areas and i'm simply going to copy paste these two because when you remove this command when you remove the neighbor areas command what is going to happen you're going to remove all the related configuration for that neighbor because remember this is a mandatory command you cannot have the neighbor without defining the remote areas let me show you that as well so what i'm going to do now is I'm going to remove this neighbor so I have removed the configuration and I'm simply going to repeat for example this command I want to say neighbor update source loopback zero look it's telling me that I cannot configure this come because I have not defined the neighbor with remote Thais and if I take a look at my VIP configuration there it is it's all con so what I need to do here is I first need to specify the neighbor in the remote areas and then I can run the other commands like the update source and like the ebgp multi-hop there it is so now if I repeat my show run I'm going to see the correcting and BGP I can see here it just came up now if I do show IP BGP summary what I'm going to be seeing here is that zero prefixes have been received that's okay because we have not advertised anything at this moment what I can do is I can pink loop back six from the loop back a little bit of our sex from the loop back of our file now I'm going to go to our six and I'm going to go to router bgp sixty-five thousand six address family ipv4 and I'm going to say network 1000 six mask I'm going to advertise the loopback of our six into BGP now at this point if I do show IP route on our five there we go we can see now that the route that I have in a routing table for 1000 six is now BGP route please observe that it has the administrative distance of 20 and that it is reachable through 1000 six which in turn is reachable through 1000 six so now I have recreated my recursive routing problem at this point from r6 from r5 I cannot ping our sex if I don't use the source to loop back 0 I still cannot ping it because the source doesn't matter now keep in mind that technically speaking at this point r6 can communicate with our five it's our five that cannot communicate with our six at this moment if I do show IP BGP summary I'm going to see that everything is okay well not everything is okay because this timer here will never at this moment go beyond three minutes why because at the three minute mark which is about one minute away from now it is going to go down because well not maybe at the three minute mark actually we have to know when the keepalive stop but at the moment the keep arrives stopped we have to wait three minutes from that that means since the moment r5 learned that BGP route the three minutes after that roughly this session is going to go down now when it reestablishes itself we are going to see this timer here never go above three minutes because when three minutes expire our five and our six will not be able to communicate anymore and when that happens the bgp session is going to go down when bgp session goes down the eigrp route will show up and when they are GRP route takes over the bgp session will re-establish the route will be advertised and the session will go down after three minutes so what I'm going to do now is I'm going to wait for the BGP session to go down and I'm going to at that moment run show IP route to show you what is happening with the routing table I might need to do it multiple times so right now you're just going to wait for this to happen I might fast forward a little bit oh I don't have to there we go look what happened the bgp session went down and we can see EA GRP route in the routing table then now we can see that the neighbor came up and if I do show IP route I can see here that the BGP route is in place show IP BGP summary now shows me this timer here at 10 seconds that means that there was a change 10 seconds ago three minutes from these 10 seconds ago the BGP session is going to go down so let's let's analyze what happened here the keep alive and or here we see that the whole time expired it means hundred and eighty seconds went by without receiving a keepalive message now we are tearing down the session and at this moment if I scroll down in this output I'm going to see that now route to 1000 six becomes e IG RP route with the admin distance of nine at this moment r5 and r6 can communicate which means that they're going to reform the session back up when this happens the BGP route is going to get advertised and take over at this moment there is no reach ability between r5 and r6 and this up/down timer is now at 1 millon l 11 seconds so what I'm going to do now is I'm going to wait for about 2 minutes we have about a minute and a half to go and almost on the queue there the neighbor went down it closed the session now the ERP route is being really learned and here we go the neighbor is back up now this is obviously a problem so how do we fix this problem well think about it don't think in terms of commands that you may need to run to fix this think in terms what do we need to do here well what we need to do here is when we go and take a look at our routing table on our file what we need to make sure is that our five will always prefer a ARP route for this loop back over the BGP learned one so how can we do that well we need to either lower the admin distance of this route or increase the admin distance of this route or use a built in mechanism in BGP that is actually meant to solve this particular problem now what is that mechanism it is something called the backdoor route the command is very simple it's configured on our five and it's configured as a network statement so we are going to say Network and then specify the loopback of our six 1000 six mask 255 255 255 255 now if I press enter at the moment that I'm typing this command then what's going to happen are five is going to attempt to advertise this into bgp but I'm not going to press ENTER I'm actually going to use a backdoor key word here now what this keyword does what this key word will do actually is the following it is going to tell our five if you receive this network here that matches this network and this mask exactly treat it as a backdoor link which means do not give it the usual admin distance of 20 and instead give it the admin distance of 200 the same that would be given for locally generated routes now locally generated route by default in iOS have the same admin distance as those routes learned from internal peers now 200 is higher than 90 it is actually higher than all the I GPS hems the whole idea of having internal BGP routes having higher admin distance which means that on r5 the route learn from BGP from external BGP which would by default have admin distance of 20 is now no longer going to be preferred over an eID airplay route let me show you that so going into my terminal I'm going to go to router r5 router bgp 65,000 5 I P before remember all policy settings are done inside the address family and this is a policy setting so I'm going to say network 1000 6 mask and here if I do the question mark there is my backdoor option there so I'm going to say backdoor now if I do show IP route I'm going to see that e LG RP route is still in the routing table no matter how many times I repeat this show IP route show IP route short route so out there it is now it stays if I do show IP BGP what I am going to see now is that this route 10006 has this lowercase R with it now lowercase R is identified here in the output as the rib failure now when you read the word failure you are immediately going to a full panic mode oh my god what has failed here well nothing has really failed what rip failure indicates is that this as far as BGP is concerned is a valid route it is also in this case the best route we can see that this greater than sign here marks that this is the best route we have for this prefix as far as BGP is concerned however rib failure here indicates to us that there is a bad route from another routing source from another routing protocol that has one the insertion into the routing table war so to speak so what has one it was deep ei GRP route that is now winning over this external BGP route going back to our default policy behavior here I would like to note that in external BGP the primary loop prevention mechanism is the AES path contents the way it works is if an external router or sir if the BGP speaker receives the route from an external neighbor it is going to examine the contents of the AES path and it's going to examine the contents of both the AAS sequence and AES set attributes and it's going to look for its own AAS number in that AES path if it encounters its own autonomous system number in that in either one of these two attributes it is going to reject the incoming update this simply means that the route from one a is traveled to some other areas and is now trying to make the come back into this a s depending on the iOS version this might actually happen on this peering session here some of the older versions of iOS when they received a BGP update from the neighbor they would also send this update back to the same neighbor this doesn't happen with all the versions of the iOS and in the latest versions of the RSI from what I have seen this behavior has been removed but be on the lookout for it there is nothing bad about this being riad vert eyes it's a little bit of a wasteful behavior from the perspective of the bandwidth and the time it will take to converge this bgp peering session but BGP does that by default in some of the older versions of the iOS now all other routes that have been accepted that means that exists in the BGP table as valid and best route so only the best routes are advertised will be advertised on the external peering session and as they are being advertise the next hop is going to be changed and set to whatever is the update source on that peering session as you can see external PGP is really not that complex it's relatively straightforward internal BGP on the other hand is a much different story and now we are going to talk about the internal BGP and I'm going to talk about two things there I'm going to talk about the rules and the default policies that exist in the internal peering sessions and then we are going to talk about how we can scale our internal BGP to address the issues that arise from certain rules that govern the behavior of the internal BGP and there I'm going to talk about route reflectors and the BGP confederations let's now take a look at the peering behavior of internal BGP the first thing is what makes the peering and internal if the neighbor being defined is defined with the same autonomous system as our own from the perspective of the peering rudder this peering session will be considered to be an internal and must follow the internal BGP rules now the first rule here is or I would say a rule but kind of the first difference between internal and external BGP is that unlike the external BGP where by default all our peers need to be directly connected and we can override that behavior with the internal BGP there is no such restriction the neighbor don't have to be the neighbors don't have to be directly connected the reason there is that the assumption is that there is an underlying connectivity between the neighbors now they may be directly connected there is no restriction against that but if there is no connectivity if there are not directly connected we need to have an underlying AGP and an internal BGP and ibgp the assumption is that yes there is such a protocol running inside the autonomous system unlike the external where the assumption is that the BGP is the own protocol running so the neighbors may not be directly connected and there is really nothing special that needs to be done in fact with the internal BGP the most common configuration is to actually have the peering done between the loop backs because that way if we have multiple paths between let's say our neighbor one and neighbor two here so we have these three paths here and we also have this path here no matter which one of these interfaces is up and running as long as we have a connection between our loop backs our peering session will be operational and will be up and running so this is the first thing the second thing is obviously we are going to talk about the default policy behavior unlike ebgp where next hop is changed when the routes are being advertised in internal BGP this is not the case and this may actually lead to some interesting scenarios so let's take a look at one of these possible scenarios let's see what we had three routers and let's say that these three routers were actually in two different autonomous systems so this is going to be our autonomous system sixty five thousand one and let's say that this is going to be sixty five thousand two three four and you might be guessing already that this is something that I already have up and running so here let's say that we do have a peering between directly connected interfaces and as a quick reminder this in our scenarios here is gigabit one interface and let's say that the network here is one hundred to one sixty eight twelve 0/24 and we want to have a peering session between directly connected interfaces this is good now let's sit here on our two and three we didn't have loopback interfaces and they are going to be one into two 168 zero 2/32 and this here is going to be 102 168 zero 3/32 and let's say that interface here is kick a bit too I'm going to be using sub interfaces in this scenario so gigabit 223 and the network here is going to be 100 to 160 8 23 0 / 24 so let's say that I wanted to build an internal BGP session here so I want to build ibgp session between R 2 and R 3 that means that I need to have some underlying protocol so that this loop back here can actually be able to reach this loop back here so let's run EAG RP so I'm going to run erp 23 on these interfaces and I'm going to advertise the loop backs into this ERG RP 23 if I build this correctly and if I built this bgp neighbor here let's examine what is going to happen with the bgp update as it arrives from r1 now you might remember that on r1 we have some loopback interface here and if I'm not much mistaken it's 172 1601 / 32 so we are going to advertise this in BGP now when this arrives to our to the next hop of this route will be set by r1 to be whatever is the update source for this period and in this particular case it will be this interface here so from our tools perspective this is an external route external round will be advertised to internal peers so now this gets advertised to r3 but mind you this is an eye bgp session now and in ibgp session the next hop does not change so when this route arrives to r3 it will have the next hop attribute of 192 168 12 1 now unless I run di g RP on this link here or if unless I redistribute this in here this route is now going to be ineligible to become the best route on r3 and I might need to do something on either our tube or r3 to fix this let me show you this what I have configured at this moment is the peering session between r1 and r2 I also have the connection between r2 and r3 and there is year GRP running between them so let's take a look at that so if I do show I route connected on our - I'm going to see that I do have network 192 168 - 23 0/24 and it's basically right here it's it's this line here second from the bottom that we are looking at and I can paint 102 168 23 3 so I have the direct connectivity and if I do show IP route EIGRP I can see that I have the loop back in my routing table it by pin 1 and 2 168 0 3 source loopback 0 I do have connectivity from loopback to loop back on our 3 if I do show IP route connected I see that I have my 23 Network if I do show IP route here GRP I can see that I have the loopback of r2 and I should be able to ping it and that is successful so on r2 here is my configuration here so I do have my router bgp and whenever you're configuring BGP it's a very good idea to actually use a notepad or some text editor to actually edit this configuration because what you are going to have is mostly the same configuration on other side so what I'm going to do here is I'm simply going to copy paste whatever I had on my r2 and what I'm going to do now is I'm going to change the configuration to remove unnecessary stuff and I'm just going to put in the configuration as I want to have it so I'm going to have the period from r3 to r2 between the loop backs so what I want to do here is I want to set the update source loop back 0 and this is an external session so really nothing else needs to be done I may want to activate it here but there is really no need to do that because all IP v4 sessions will be activated by default so I'm going to go here and say copy paste and I really what I need to do is I need to repeat pretty much the same configuration on our to itself and there you go you see copy paste with a little bit of editing and now I'm going to have my bgp peering session come up the IM expert to see it in just a minute there Oh actually I did make a mistake yeah I made a mistake again this is the wrong way so let's let's fix this then so I'm going to say no dis and I'm going to say this is neighbor 2 3 4 much better now and going to fix this ok maybe I need to copy paste this one more time there was this tiny little error message here so uh let's do the same thing on the other side and actually there is an easier way to do that I'm just going to do this and do not do this in production environment you can do when you're studying but removing the bgp process is not actually a not actually a good idea to do so now let's see if our neighbor now it's much better now we can see that the neighbor came up here everyone makes mistakes but it's important if you make a mistake a silly mistake like I did it was it was a wrong copy/paste I used the wrong AES number because I copied the configuration for r1 as it was configured on r2 to r3 and that made me use the wrong AES now the reason why I didn't get any error messages here is because I did use update source looped back and the neighbor wasn't directly connected so the router wasn't even trying to send the TCP to activate the TCP connection so there was no since senton because because of the TTL expiry I did talk about that a little bit earlier so this is why we didn't have that error message with the peer in the wrong das now if we did configure the update source any bgp multi-hop in that case you would have gotten the error message but we don't need a bgp multi-hop because this is an internal session so now on our three if i do show IP vgp summary i'm going to see that from our two we are actually learning two prefixes now if i take a look at show IP bgp i'm going to see that one of these prefixes has a rip failure and as we're in member the rib failure isn't actually that big of a problem and we do have a rib failure afford the loopback of our to which is perfectly legitimate because we are actually learning it from AI GRP rib failure is what we want to see in this case however this network here is much more interesting this is the loopback both are one and we can see here that as far as BGP is concerned it's a valid route now what well it means is yeah we received it it's ok all the attributes are there there's nothing wrong with this route but what is missing is that this is the best route as far as BGP is concerned so what answered the what not the best route it is the only route for this prefix in our BGP table so why isn't it the best we cannot tell that from this output here but what we can do it should be GP 172 1601 and what we are going to see here is this it says it's inaccessible what is inaccessible well we need to look at this bit here this is the next hop for our route now going back here to our whiteboard this here is this address here is 192 168 12 1 now we know when this route was advertised to r2 that this was set to be the next hop by r1 now when our to re-advertise this route to r3 because of the rules in Eid our oh sorry in ibgp where the next hop is not changed when routes are advertised this next hop remains on r3 now because we have not advertised this network here into our CI GRP or because we didn't redistributed r3 now receives the BGP route a valid BGP route with the next hope that it doesn't have in a routing table so if we go here and if you do show IP route oops I made a mistake copy/paste it again so show IP BGP 172 1601 let's repeat the process so if I do show IP route this I will see that the network is not in table if I do show IP route indeed the network is not in table so how can I fix this problem well I have multiple possible solutions here one is I could advertise this network in Eid chirping - I could make I could advertise this using the network statement in air GRP and I could make the interface passive just to avoid speaking AGP with r1 or I could redistribute this network or I could go to r2 and this is probably the most elegant solution I would go to router bgp so I'm going to go to router bgp I'm going to go into the address family ipv4 if I'm using address families if not you don't have to go there and then I'm going to say neighbor and remember this is a policy we are setting 100 to 168 0 3 and I'm going to say next hop self now what this command is going to do is when r2 advertises the route to its internal peer it is going to set the next cop to be whatever is the update source for that peering session in other words configuring the next hop selves makes IGP behave from the perspective of the next hop behavior behave in the exact same way as ebgp does when we advertise the route change the next cop from whatever it was to ourselves so if I now go to my terminal to r3 if I do show IP bgp 172 1601 now I will see that my next hop is 192 168 0 - and here we can see what is the IGP metric for this and remember this is used in the best path selection process at about step number 8 I believe wood 9 we have all those bunch of tiebreakers we can also learn we can also see here that this was our peer address so right now we can see that this here is the same value so at this point if I do show IP route what I'm going to see here is this route learned from BGP so now this route is actually valid and best and if I see this shorthand output of show IP BGP I can see that this router is valid which it was before but I can also see it is the best route one more thing that I would like to show you here let's go all the way back to r1 so on r1 if I do show IP BGP what I want to take a look at here is the route 170 to 1601 now taking a look at this route and let's say that you are seeing this for the first time what could you tell me about this route is it an internal route or is it an external route did you learn it from someone else or did we inject it ourselves let me answer that first things first this route looks like it might be an external route what because I'm looking at this part of the output if in this part of the output I see a lowercase I this will indicate that this is an internal route so this route as far as this router is concerned is not an internal route but people learn it from someone else well we have two queues that might tell us that this is not the case first queue is the weight of 32,768 which we know will be by default for locally generated routes the second queue if this was an external route we would have an Aes path here we don't have an a spot please don't mistake this lowercase I for the AES path it is not this here is an indicator of the origin code of IGP now keep in mind the lowercase I here indicates an internal route lowercase I at the end indicates the origin code of the route so this is the second cue the next queue or the next clue is really the next cup of zero zero zero zero so if we have the net top of zero zero zero zero zero and if we have the route that appears to be external route and we have the weight of 32768 and we don't have the external path we can clearly we can be fairly certain that this is a locally injected route now let's take a look at this same route on r2 so I'm going to say show IP BGP now let's take a look at this road again I am looking at at the output here there is no lowercase I so this does appear to be an external route I can see the two weight is zero which probably means this is not that this is not a local injected route second or the third is the AAS path it's nonzero and finally the next hop is not all zeros so all these indicators here tell me that this might be an external route now we know it is an external route because we know how our topology looks like so we have our two and we have our 3 here so this is the a s boundary here so when this route was learned here it was an external route now what about the route here will it be perceived as an internal or external route at this stage here what do you think well if your answer was it was an external route you are in for a surprise because it is not an external route this is now perceived sorry bada this is now perceived as an internal route we can see here we have a lowercase I here this means it's an internal route keep in mind this I is irrelevant it's simply an original code this one here tells us it's an internal route so how can it be an internal route when it comes from a different a s the differentiation between the internal and the external outs doesn't mean where the route originated in and I did talk about this earlier it means where did we learn the route from so in our case here we have R 1 R 2 and R 3 right this is the is boundary when r2 learns this route it's an external route because it was learned from an external peer but when r3 learns this route it learned it from an internal peer so here on r3 this route will be perceived as an internal route so r3 now has the route that it learned from an internal peer so from the perspective of r3 this is an internal route now why is that important thing because routes learned from other internal peers are not advertised to other internal peers so here I forgot to mention so it says routes learn from internal peers are not advertised to internal peers which means that if here on r3 we had another router here let's say R for this route would not be advertised to it but if on r3 we had another let's say r5 here which was in a different areas this route yes would be advertised to the external peer but it will not be advertised to internal peers and the reason for that is the loop prevention mechanism that I talked about earlier so how do we work around this there are multiple ways we can do that the first one is to use a full mesh of peering sessions here to solve the problem now what is the full mesh of peering sessions now you will remember that there is no requirement that ibgp peers are directly connected to each other because we don't have that requirement what we can do here is let's say we have our r1 r2 r3 and let's say that we add our r4 which we are going to do in a minute what we can do is we can have the peering between the loop PACs here between r2 and r3 then we can have the peering between r3 and r4 and we can have the peering between 2 & 4 in this case and all these pairings can be done between the Bax now you might be thinking if r3 here is not going to advertise the route to r4 what is the point of this peering session well what if r4 had the connection to some router that is outside the ASO yet another AAS boundary here how then are three learn about these routes here well over this peering session that is right here so this is why we have to have the full mesh of pairings to actually work around what I like to call ibgp split horizon it is of course not officially called split horizon I like to call it glitter Eisen because it really behaves in such a way if we take a look at the route received from one internal neighbor then we are receiving them on this internal neighbor we are not going to advertise them back to internal neighbors so it kind of does behave like a split horizon and it's very very easy to understand it if we use a term that we know and understand from different protocols so one of the workarounds for this split horizon problem as I said is the full mesh and in this case here full mesh is actually not that bad of a solution but the problem is if we had there a larger autonomous system full mesh won't scale it won't scale because it requires n times n minus 1 over 2 number of peering sessions and what would happen if your internal autonomous system here said let's say five thousand years how many peering sessions would that be let me answer that question a lot of peering sessions so the full mesh here even though it solves the problem in a relatively small areas like this one here wouldn't scale to larger autonomous systems so for that reason I'm going to skip using full mesh as the solution here what I'm going to do now is I am going to add our four to our mix without the r5 here on this side so I'm just going to have our four and I'm going to have it connected directly to our three and the network that I'm going to be using there is going to be 102 168 34 0 / 2 before and I'm going to peel between the loop backs and this is going to be interface gigabit to 34 on both of these sides so that should make things simple so let's get to the terminal configure this I already have ear GRP pre-configured so I'm just going to add BGP and let's see both the problem and the possible solution for the problem that's going to come up in action I am of course going to start that by making sure that my r3 and r4 are actually connected so on our three show IP route connected what I'm looking for here is the network 192 168 34 / 24 and indeed here is my network it is connected on the gigabit interface right where I wanted to be and I am going to do show IP route EIGRP just to make sure that my EA GRP has cotton it has received the route from r4 and here is that route so what I'm going to do now is ping 1 and T 2 168 0 4 source loop X 0 and that works on are for similar verification I have the eigrp route show IP route well if I have the IG pirata obviously have the connected route so let's just try to ping between 4 and 3 I can do that and just for fun I'm just going to make sure that from our 4 I can actually pin all the way to r2 and that also worked now let's configure BGP so to do that I'm going to use the configuration from r3 but I'm not going to make the mistake that I did before so what I'm going to do now is going to bring in my text editor here now let's make it a little bit wider here and I'm going to make sure that this appearing here goes to r3 so this looks good for the configuration on our 4 we're going to paste the same and for the configuration on our 3 what actually want to do is this and that would pretty much be it so let's paste the same and now I'm going to wait for the BGP to come up and I can see it actually did come up right here so let's now make sure and see the the behavior I explained did happen so on our three here if I do show IP BGP I'm going to be seen the route 170 to 1601 and here is this route there and this is going to pop out again so let's put it back in so here is the route that I'm looking for so 172 16-0 1/32 and we can see it is actually an internal route now going to our 4 if I do show IP BGP summary so the first thing that I want to see is that I am not actually receiving any prefixes here why am I not receiving any prefixes well because all of them on are 3 if I take a look at this output here all of them have been internal prefixes now if I have internal prefixes and our 4 is my internal neighbor that means the time not going to advertise any of these prefixes and if I go to our 4 I'm just going to confirm that show IP BGP shows me nothing how do I then fix this well we said that we can have the full mesh peering between our two and our 4 and that would somewhat address this issue but what I actually want to do now is I want to make sure that our 3 advertises this route to our 4 I want to make our 3 kind of relax the rules of the route of advertising the internal routes to other internal peers because this may help me with the scaling of internal peering let's see how we can do that one way would be to make our router our three so-called BGP route reflector now what is a BGP route reflector practically speaking it's the router that has somewhat relaxed split horizon rules that allows the internal route to be advertised to other internal peers but not all internal peers from the perspective of this route reflector are the same so let's take a look at some of the terminology that BGP uses to the describe the behavior of route reflectors the first thing obviously we are going to take a look at what the route reflector is it's the router that has this feature enabled that has this relaxation in place this is configured on / neighbor basis so when we have one router that let's say has multiple internal peer so let's say this is our one that this is our two and this is our three here now our two might be configured to perform route reflection with our three or towards r3 that route the trotter r3 here is what we call a route reflector client but this other router here that was on the left side of the collection that one might be unknown client so what is a client and what is a non client well route reflector client is the router that appears with the route reflector and for which the route reflector actually has the route reflection enabled rocket reflection is another way of saying we are going to reflect the internal router because think about it let's say that we have an external peering here so this is an external peering and then we have an internal peering and then we have another internal peering if we receive an internal route here what really want to do is to reflect this route to this router here so this is why it's really choral called our reflector it could have been called the route balancer as well but it is called a route reflector now this word to reflect or the the purpose of this router here it's very very important to can get to the bottom of that word it means that this route as it was received it will be announced here pretty much the same way it was received now we can obviously apply some of the outbound policies here but by default this route is going to be sent completely unchanged which means that whatever was the next hop advertised by this router here it will be unchanged when it is elected depending on the iOS version even configuring next-hop self on the client session here may have zero effect because route reflectors are really not supposed to change the next hop of the route so keep that in mind by default this will not change so this router here better know how to reach this router here which shouldn't be a problem because these three routers here should be running the common IGP but if they don't you might have a problem when you reflect the routes and keep in mind that setting the next hop cell phone that peering session may be a little bit ineffective so what is a non client then a non client is an internal peer of the route reflector for which this feature has not been enabled so why would we have that well we could have a scenario in which we just have one client that we don't have a full mesh with and there is no need to enable route reflection for every single router in the network when enabling it for that one router will and should be more than enough now let's take a look at some of the route reflection rules so what I'm going to do now is I'm going to come up with the scenario so it's init I have four routers here that are in some AAS and then I have these let's say five routers here so I'm going to hide myself now that are all in let's say a s 100 so this router here is going to be our route reflector raus reflector and let's say that we have peering sessions that follow these black lines like this so route reflector has some internal appearance litera this is external one external to external three external four so there are some external pairings going on here and we have a bunch of internal ones now let's say that this router here is non client one and that this is here non client two so these two routers here are non clients and this one here is going to be client one and let's say that this one here Our client - let's see from the route reflectors perspective which route by default will be advertised where so let's say that we receive an external route so when we receive the external route by default this route will be advertised to all the external peers it will be advertised to all non clients and interestingly this client here will advertise it here but this client will not advertise it to other non client and this one and this sorry non client and this non client here will not advertise it to this non client here why because these here are just regular ibgp sessions there is nothing special about them there is no reflection of the route as far as MC 1 non client 1 is concerned this route received here is just a regular internal route the route reflector will advertise this to clients and this client will advertise these two external routes because from the perspective of client this is just a regular internal route it doesn't really need or doesn't even have any special configuration for in relationship with the route reflector its route reflector that is specially configured in regard to these two clients here so this route will be advertised to all external peers non clients and all the clients now let's take a look what's going to happen when we have a non client route receipt so let's say that this non client one receives the route from an external peer 1 by default it will advertise this to non client - but non client 2 now sees this as an internal route so it will not advertise it through the route reflector non client window since this is an external route so it will advertise it to its other internal peer from the perspective of this router there is nothing special about the route reflector and route reflector here will not realities this to a non client why because this is a regular internal route as far as israel's reflector is concerned it will however advertise this to external peers and also it will advertise it to clients now this is significant because this is an internal route but because we have relaxed the split horizon rules as far as these routers here go it will have realized relax it don't only for the routes received from clients but also those received from non clients we somehow have to get the routes from here to here so this route will be advertised to clients as well now client one will advertise this to our external peer let's now take a look what's going to happen with client received route so let's say that this client here receives route it's going to advertise it to the route reflector now route reflector will obviously advertise this route out to its external peers so this goes to external peers we expected that also because this is a client we are relaxing the split horizon rule between our clients and the rest of the internal network so this route needs to go to the non client so it will be reflected to non clients now as far as non client one is concerned this is an internal route so it won't be advertised to other internal peers and the same thing happens on non client to non client one will however advertise this to our external peer now route reflector will reflect the client received route not only to non client but somehow we have to get this route all down here so this route goes here which means that this route will be reflected to clients as well so when it comes to the routing route reflection rules I have listed them here for client routes will be reflected to externals clients and non clients and non client routes will be reflected to external will actually be advertised we are not saying we are not calling this reflected so I might even cross this but they will be reflected to clients and non clients for clients received routes and for non client received routes they will be reflected to client but they will be advertised to external routers external peers because the internal in Lord router always advertise to external peers as long as they're valid and best how can we then utilize this to fix our problem well the solution to me at least is obvious we are going to make router 3 a route reflector now we have two possible approaches we can make our two a route reflector client and our for a route reflector plan in effect making both r2 and r4 clients but that way I'm not going to show you this behavior with clients and non clients this would be the recommended way of doing it but I'm going to break the rules a little bit or break the tradition so I'm going to make our two here non client in other words I'm not going to configure anything special between r2 and r3 but I am going to make our 4 here the route reflector client so I'm going to configure r3 to reflect the relearned routes from r2 to r3 before I do that what I'm going to do is we have to loop back here on our 4 we already know we have it because we have the peering between it between r3 and r4 between those loop backs now I'm going to add this into bgp what i should be observing there and i'm going to do this before I configure the route reflection is that this loop back of r4 is visible in the BGP tables on our 4 as a locally generated route in an hour 3 as an internal route which means it will not be advertised to r2 when I configure the route reflection we should be seeing our ones looped back all the way on our 4 and our for loop back all the way on our 1 let's go ahead and configure this so I'm going to start with our 4 as I said I'm going to go to router bgp 65 2 3 4 address family ipv4 and I'm going to say network want to 168 0 4 mask to 5 to 5 2 / 5 to 5 5 so now what I should be seeing on r3 if I do show IP BGP summary I should be seeing from our for that there is one route that is learned let's take a look at that route so if I do show IP BGP I be seeing now from our for the time learning one route 192 168 0 4 and this is an internal route which means that if I go to r2 and if I do show IP BGP summary I am NOT going to be seeing anything learned from our three and here we go again that's okay we can fix that easily now if I do show IP BGP I'm not going to be seeing anything from my r3 router learned on r2 and the reason for that is that that was an internal route on r3 so our R to here that is an internal route so it will not be advertised to r2 let's fix it so what I'm going to do on our three I'm going to go to router bgp sixty five two three four and remember configuring the route reflection will affect the route hence it's a policy command so I need to configure it under the address family so I'm going to go to the address family ipv4 and I'm going to say neighbor one at two 168 0 4 simply route reflector client that's it when I press ENTER the bgp session is going to go down and it's going to re-establish itself it's going to go down because we have changed the configuration that deals with the route reflection technically speaking there is really no need for this to go down but this is what iris will do let's see if there has been any change in behavior so if I go to r4 if I do show IP v GP summary I'm going to see now that I am receiving two prefixes from our four so if I do show IP BGP look what I'm seeing I am seeing the loopback of our one and I'm seeing the loopback of our tube so the route that I did not receive before this route here actually let me do it this way this route here and this route here were now both advertised to r3 and reflected to R for one more thing to show you before we continue is take a look at the next hop for these two routes it's 100 to 160 8:02 so we know that our 2 here was configured with the next cop self towards r3 but this was not changed by r3 when it reflected the route furthermore on r2 if I do show IP BGP now I am going to be seeing here the loopback of our 4 and here it is I am seeing the loopback of our 4 and on r1 if I go here if I do show IP BGP I'm going to be seen the loopback of r4 here as well so if I think 172 sorry 192 168 0 4 source loopback 0 I'm going to have the pink all the way there route reflectors are a very very good scalable solution for scaling the number of parents that you might have in your autonomous system but they are not the only one there is another solution called the Confederations the BGP Confederations the idea behind the Confederations is to divide the large autonomous system into smaller more manageable autonomous systems while still presenting the same coherent view of the internal routing to the outside world in other words the outside world is not going to see the complexities is not going to see all the members of the sabato of the large autonomous system it's not going to see all the members and the sub autonomous systems of the Confederation it's going to see one large autonomous system but inside the Confederation the entire BGP configuration has been divided into smaller more manageable pieces that we call sub autonomous systems this sub autonomous system sometimes called the member autonomous systems or simply members are really really small autonomous systems that abide by internal BGP rules between the sub autonomous systems rules that are very similar to eebee GP are in use let me explain that let's say that we had an autonomous system that consists of say three routers that we have peering sessions that look like this now because these peering sessions are not directly connected this router here or there we don't have full mesh this router here is most likely going to be a route reflector now let's say that we have another autonomous system that may look exactly the same so here we have the route reflector for the experience let's say that we have the peering between these here now we know let's say that this here is our AES 65,000 one and let's say that this is 65,000 two now let's say that these belong to the same organization that has the a s12 for example so inside we are using private autonomous systems but we won't represent this whole big autonomous system to let's say our autonomous system 100 here that may have a full match as a s12 so this router here that peers with this router here is going to think that it is peering with the a s12 so this whole entire autonomous system here is represented to the outside world as a single autonomous system however when we go inside these members we are first of all seeing that we have two autonomous systems so this peering here and this peering here is a regular ibgp peering which means that routes received from this router by this router will not be advertised to this unless this router is made a route reflector so first thing that I want you to observe here the fact that we are using a confederation here does not automatically mean that we are not going to be using route reflectors we can if we needed to scale the number of peering sessions inside our sub autonomous system here now this router here and this router here they are in the same Confederate but they are in different Confederation members so the peering session between them is going to be something between ibgp and ebgp and i like to call this CBGB or the confederation BGP I'll explain what are the rules there now when these routes are received here they abide through the same rules that exist here so here we have regular ibgp sessions so let's see what's so special about the Confederation BGP first thing I want you to remember one thing remember when we talked about the BGP attribute and we talked about one that was called the local preference so if this router here set the local preference it will not affect only the routers in this sub autonomous system they will affect the routes in the entire system here because the local preference will actually transit the CBGB session furthermore when this router here advertises the route to this rodgero let's say that we used next-hop self or if we didn't even worse this would be by default the next cup here and here and you know what also here because the next cup will carry over the C BGP so another thing that will survive the peering session between our sub autonomous systems is the next hop so will met or dimetric one thing that doesn't exist between these two or the assumption is that it does not exist is the IGP routing protocol so the session rules here I am likely use the different color here so well when it comes to the session we need to abide to ebgp rules which means that the neighbors need to be directly connected if they are not directly connected we need to have some routing protocol between them and we have to configure the ebgp multi-hop but these values here will be carried over but what about the a s path how does the a s path look between these members here well that's very good if you ask yourself that question let's let's go to the next page so let's say here that we have our a s what was it a s 100 and here we have our two autonomous systems so this one is 12 this one is 65,000 2 and this one here is 65,000 1 now when the route is advertised from a s 100 to the router that sits in 65,000 to the a s path is simply going to be 100 now when this route gets advertised inside this sub autonomous system member here we know that the a s path will not change now when this route goes out to 65,000 won our alias path is going to change but in a very unusual way we are going to have 100 at the end and then in parentheses we are going to have 65,000 too which indicates that this was learned from so-called Confederation peer Confederation peer is the router that is in the same Confederation but in a different sub autonomous system number than we are now let's say that here our a is sixty five thousand one in the peering session with the router in say a is 200 how will the a s path look when it gets advertised here well it will look like this it will have one hundred and then twelve because when this route leaves the Confederation we have to actually remove the traces of that Confederation the reason is that entire a s12 is going to represent itself to the rest of the world as one big AAS so from the perspective of a s 100 and a s 200 what sits between them is a s 12 they are completely unaware of the internal complexities that might exist in the a s12 there are some special considerations when it comes to the Confederations first of all if you are considering using Confederations in real life the initial answer letter I have to give you is don't do it the reason is that Confederations are truly designed for special purposes like mergers and acquisitions and really really large networks they are the Ordnance a they are they do require an additional work and additional maintenance and they do require a little bit more care and attention then route reflectors route reflectors are good everyday solution for scaling your BGP pairings but then again in some cases you don't have to choice and you have to go down the Confederations if you have to configure the Confederations keep in mind that all routers must be configured to be aware of the confederation identifier now what I mean by that is when you are configuring your BGP you have to start you say router bgp and then you specify the a s number here and then here we are going to say BGP Confederation identifier and we are going to specify what is our Confederation now this X here is a sub Confederation a s which means in this case here it would be our sixty five thousand one or sixty five thousand two depending which are two we are configuring and this number Y here is actually the Confederation identifier so it would be our a s12 another thing that you should configure on all peers now here India in the slide I say that all routers should be configure that to be aware of the Confederation peers what I mean by should and not must is that really this requirement exists only on the routers that are actually pealing with other sub configuration so this router here and this router here are the two routers that would require this next configuration and this next configuration is BGP Confederation peers and then you specify the list of peers so this letter Z here or this number Z is actually other sub Confederation members so we are helping our routers determine which one of our neighbors are actually going to follow the sub Confederation rules and which are going to follow the external rules because remember if the AES number is not is not this we are by default going to behave as if this was an external peer however if the other router is the member of the same Confederation we have to behave slightly differently we have to behave according to these rules that I described in these previous couple of drawings so it's very very important to configure at least these routers this one here and this one here to be aware of these pairings however as a good common sense practice I would recommend that you configure the Confederation peers on pretty much all of your routers in your Confederation

Channel: CCIEORDIE.COM

Views: 5,666

Keywords:

Id: mJU9DWxgprQ

Length: 109min 1sec (6541 seconds)

Published: Thu Feb 08 2018