CCIE R&S Instructor JP Discussing BGP States

hey guys wanted to take some time to talk about the bgp finite state machine we need to address the states that bgp goes through when we implement this in the real world or we implement this in our lab we really need to understand what's going on under the hood of bgp we need to know all the requirements that bgp needs in order to fully establish itself and if we don't understand this then when we sit down in our lab and we get a troubleshooting ticket that says maybe you know these two neighbors aren't able to peer or form an adjacency using BGP we're going to spend way more time than we should trying to figure out why and believe me that is not where you want to be so let's go ahead and let's take a look at this let's let's dive in and let's see what's going on under the hood with BGP so the very first state that we enter in BGP is called our idle State so we've come into our device our two routers we've said router bgp with our autonomous system and then we've entered in our neighbor command so neighbor destination IP address and then we've entered in the remote a s of our neighbor right but let's ignore that remote a s for a minute let's just focus on that destination IP address so we've said neighbor destination IP when we hit enter after that neighbor command we enter the idle State of BGP we're going to attempt to establish a TCP connection using port 179 with the neighbor that we've entered in that destination IP address so well not 1.1 whatever it may be I'm going to try to establish a TCP connection with that particular destination IP address now at this point once I've once I've attempted to initiate this connection I'm going to back off and I'm going to be a passive listener which means I'm going to enter this Connect State and I'm going to wait here in this Connect State for 120 seconds which is my connect retry timer now this timer is hard set in BGP we can't change it there's no hat we're going to have to sit here for 120 seconds but don't miss what I said at this point we only care about the destination IP address in our neighbors statement we're not concerned with everything else in BGP because all we're worried about is forming this TCP session between these two neighbors so again idle state I attempt to establish a connection with you and then I back off and I become a listener I wait for you or any neighbor for that for it for that matter you're going to do the same thing you're going to first try to establish and if I'm in the listening if I'm in the connect state and I'm listening and we've fired up this this neighbor router you've tried to initiate with me I'm listening we're going to go ahead and start a TCP session if we have a problem at this point it's going to be with TCP and we have to understand that we can have some control plan policing we could have a quality of service policy in there we could be we could be dropping TCP traffic for some reason we could have an access list now there's a number of different access lists that we could apply that can break BGP and we're not going to get into that in this video but just be aware that we're troubleshooting TCP so we need to look at TCP related issues did I even enter the right IP address in my neighbor command that's about all I care about inside of BGP itself okay can I get to that address if I can get to that address am i dropping TCP traffic somewhere else specifically the destination port of 179 maybe I'm not allowed to send traffic to that address but here we're still only talking about TCP now if the hundred and twenty seconds go by and we haven't heard a peep we haven't gotten any session whatsoever the next thing that happens is we are going to enter what we call active State we've spent 120 seconds in Connect state listening for a session we haven't gotten anything we haven't heard anything now we're going to actively try to initiate the session for 120 seconds with that neighbor with that destination IP address we're not going to wait we're going to actively try to establish it so now we're going to be the speaker now we're going to try to do this for another 120 seconds and if we fail we're going all the way back to idle state we will go through these three states in an endless loop forever until we fix our TCP problem so what we need to do and what I do in my mind is I draw a line right here and I say that this these first three states are considered phase one and they are TCP dependent sorry okay so these are TCP related or dependent states I'm not going to look at all the other BGP related information because I only care that I can reach that neighbor he can reach me and I've and I'm able to establish this TCP session now assuming that we did have a problem and we fixed it we're able to establish this TCP session now the next thing that we do is we enter what's called the open sent state now in the open sense state this is where we actually start to send BGP related messages what does that mean you have all been in the situation either you've done it on purpose or by accident where you get this wonderful error message peer in the wrong is well why does that happen what at what point are we in the BGP States and at what point in the vgp finite state machine are we to cause this error message well the answer is we're right here because contained in this open message we're now sending each other our basic BGP information contained in the open message that I'm going to send you is going to be my BGP ID my version number my hold down time and my autonomous system if the open message that I send you matches your configuration you send me a keepalive because you think we're good to go if you send me an open message and I compare it with my configuration and I find that the information in your open message didn't match what I have in my configuration I'm going to send you a notification that notification is going to signal the teardown of our BGP session and we're going to go all the way back to idle State now you've seen this before because when we get this error message peer in the wrong a s what happens we get these error messages displayed in our CLI there's a brief pause we try to enter the commands to - no neighbour or we try to shut down an interface and also boom the error messages come back we get the same display of errors all over again and then there's a brief pause and maybe we try to turn off console logging and boom there's another set of error messages the reason is is because TCP is not broken BGP is broken so what's happening is we're going back to idle state we don't have a TCP problem so we immediately establish a TCP session we go right into open sent state and then the minute we receive those open messages boom we fail we go right back to the beginning okay so this is where we actually find that error State in BGP it's the transmission of these open messages that are going back and forth between our two neighbors now assuming that we don't have that problem assuming that everything is configured properly right so I'm in the right is you're in the right a yes we've done our job properly as CC II's right we have we don't have any issues the very next state that we're going to enter is called the open confirm state now in the open confirmed state all we're waiting for is the receiving of each other's keepa lives so we've gone past the open send state we've sent each other open messages your open messages match my config my open messages match your config immediately I send you a keepalive and you're going to send me a keepalive during this keepalive transition we're going to be an open confirmed state now if we fail if I don't receive your keep alive or you don't receive mine we go all the way back to idle state and we start over if we receive each other's keep lives which we should I mean there really shouldn't be any problems at this state that would keep us from receiving our keeper lives the minute that happens we enter the state we want to see our BGP neighbors in and that's going to be established state now in this state this is where we will send our update messages at this point it only in established state am I going to send you an update message that contains all of my attributes maybe I've set the local preference of the weight or or the met or any of these other attributes in the update message that's where these attributes are going to be applied and not only not only those attributes but also the prefixes that I'm actually advertising to you so I will send you my update message with all of the BGP related config that I'm supposed to send and you're going to send me the same thing now by default our keeper lives are going to be sent every 60 seconds and we're going to have a whole time of 180 now we can change this if we want to but by default we're going to have 60 and 180 let's go for a minute now let's actually check this out in a packet capture I want you guys to actually see what I'm talking about it I want you to take my word for you should never do that you should always validate everything that an instructor says to you so notice in our packet capture these were two neighbors that I had set up just router one router two they were directly connected I didn't cause any TCP problems because I wanted to just show you that it is TCP related at first okay so notice what we have here we have router one as my initiator we have router two as my listener and how do I know that aside from the fact that Wireshark tells me my source and destination while I see here that my initiator which was my source had the higher random TCP port number in this case it was 24 650 my destination port was 179 so this is a TCP session the protocol I'm using TCP here's my TCP three-way handshake so again just regular standard TCP once I establish a session once we have our three-way TCP handshake router one he's the initiator immediately sends an open message and like I said look at what is in the open message we have the version the a s the hold down and the BGP identifier okay so this is contained in my open message and if you look closely we have another open message right underneath and here's router two here's my version here's my a s my hold down and my BGP identifier so we have this transition of open messages going back and forth but notice what happens router two immediately so here's router 2 my source my destination here's router 2 a BGP message he sends a keepalive so according - router - the update message that he received from router one matched his configuration so we know that the configuration on router 2 must be ok but look at what router wanded router 1 sent a notification message we have router 1 - router 2 notification and what did router once a router one told router 2 hey buddy you're in the wrong a s so at this point looking at this packet capture I know that the configuration problem is on router 1 because router 1 received the update message from router 2 he looked into his configuration and he said wait a second your open message said that you were in a s - but I'm configured differently in this case I know that he was configured in autonomous system 1 so router 1 was expecting ibgp whereas router 2 is expecting ebgp now I know that because I configured it right but the point is is that router 1 was the guy that had the wrong configuration where he had a different configuration we could have misconfigured router 2 of course in the wrong ass but the guy who was misconfigured was router 1 and router 1 says hey I'm being told that you're in a different autonomous system than the one you're actually configured in so his neighbour statement had a different autonomous system at this point the bgp session is torn down let me shrink this and you can see that we start over so we we close TCP here and notice that we start over so we start over again here's our three-way handshake we have an open message immediately what are we delivered with we're delivered with another notification message from router 1 that says you are in the wrong a s here's our notification again from router 1 let's scroll down we're going to see another one again from router 1 the same notification and look it I mean if we scroll down here you're going to see them again here's another one here's another one this will go down in an endless loop until we fix it BGP will just continue to cycle over and over and over again until we fix so I obviously went in and fixed it otherwise this would be a short video I went in and fixed it and when I fixed it I went ahead and said redistribute connected because I wanted BGP I wanted both routers to not only establish appearing but I also wanted them to redistribute all of their connected interfaces as well as their loop backs so that we can actually see these update messages in our capture so let's take a look at this actually working so here's our three-way handshake in this case it was initiated by router 2 so here's our three-way handshake and then immediately router 2 sends the open message so here's the information again from router 2 same exact information if we go down and we take a look at router 1 we have now we have this same information that we had above so they're the same open messages the difference is is that we've fixed the neighbor statement on router 1 we've gone in and said neighbor IP address of router 2 remote a s 2 so we've put it in the right a s immediately after we have this exchange of open messages we have the exchange of our keeper lives once we've established and once we get the keeper lives back and forth the very next message that we see is the update message and in this case the update message is being sent from router 2 to router 1 and look at what we have just like I told you we have our network reach ability information the the NL RI which is essentially the prefixes that were advertising to our neighbor in this case router 1 and we have our path attributes so in this case we had we had our origin our is path etc so these are all contained in the open messages look at router 1 if we scroll down just another another packet here router 1 sent the same the same update message saying here here's my prefixes and here's my path attributes in BGP so this is the transmission of these open messages in a step or these update messages in established state if we advertised another prefix we would see another update message if we removed any prefixes or or applied any any filtering or we applied any extra bgp attributes we would see those in an update message and this is going to be happening in our established state and if you scroll down we should see I stopped the packet capture but again we see these different keeper lives that are going back and forth so don't allow yourselves let me erase this don't allow yourselves to get confused with regards to the BGP states we have to understand this the first three phases are States rather that BGP goes through we can consider that phase one we can consider that TCP phase would that's where we're going to try to troubleshoot or or have our requirements to implement BGP the second three states that's going to be phase two all right very very easy and in phase two we're going to care about BGP we're going to be looking at BGP configuration BGP related information so don't allow yourself to get confused make sure that you pay attention to this make sure that you read the RFC s make sure you study hard guys you have any questions please reach out to me let me know keep up with your studies and I hope you enjoyed watching this video I really hope it was informative I'll talk to you soon bye bye

Channel: IPexpertInc

Views: 26,205

Rating: 4.9669423 out of 5

Keywords: CCIE Certification, CCIE R&S, CCIE Routing & Switching, CCIE Routing and Switching, CCIE, BGP States, iPexpert, CCIE Training, CCIE Lab Training, CCIE R&S V5 Lab

Id: 2JlD1ZaWbRo

Length: 16min 51sec (1011 seconds)

Published: Fri Sep 04 2015