Firepower threat defense high avaIlability

so let me know if you can see my screen now yeah so starting with the firepower threat defense AJ before that I'd like to introduce myself so I've been working with Cisco for around two and a half years before that I was working with janab attack I've totaled around 4.5 years of experience with fire fall products yeah so let's get started so this is the agenda for today's discussion I'll be taking you through the introduction to a CD and then why why do we need FG DHA the reasons and what what is the licensing how does it work I have made certain videos for you to understand the creation of a free DHA and the break delete or Andy switch options and in the end we'll show you what logs can we look into many have certain issues with regards to the FTD HM so this is going to be fully focused on FDA and DHA operations involved in it so I'd like to begin with telling you how an overview of the architecture of the STD how it works how's it different from the area same so under on the PPD you could see on the slide you can see there is a diagram or which yeah so refer to the first diagram that I'm talking about so that's it that's a big picture that's the that's the overall understanding of how we have integrated the snot Andy is it together too far to come up with a new firewall which is firepower threat defense so basically we have two parts to this the a say engine and is not engine although meth the other names for a changin we can we we will refer it as Lena in in the country in the upcoming slide so so I can use this engine aleena interchangeably I can use not and firepower interchangeably so these are terminologies although sometimes that will be using your will be SMC firepower Management Center and STD 45% defense so for an overview of traffic would enter the AC engine we would do certain three checks on the a si and on the basis of certain configuration called as pre-filter rules will decide if this traffic is to be sent to the north or not if it is to be sent to the snot it will be sent to the snot we have a shared memory over between asin is not where in the packet will be pulled by the snot and they will take it through certain policy valuations you can reference second diagram we have si SSL decryption access policy file ambience motto so all this will be happening internally in the snot so when I talk about failover and synchronization of synchronization of states between STDs I'm referring to synchronization of both this not ndaa part so unlike a failover so originally I mean before this the evolution was that we would be using a say with five of modules and fire power modules did not have did not have any power modules did not have any synchronization between amongst themselves so this is our attempt to create an absolute perfect failover scenario so traffic would be entering the ACE engine which is also called as Lina sent to this not depending on the pre-filter policy if the pre-filter policy is configured as analyzed it will be sent to snot if it is configured as fast path it will be this not will bypass and it will be sent to or through his engine so this is the flow of packet through the FTD so let's go to the next slide so I'll be starting with an overview of what we have on the FTD so this is like in the FTD or we support after standby only there is no active active because active active is a the feature which requires multiple context flowers and also now after it does not support multiple context we will be using will be only consumed can only configure state puts stateful salable because we need to have a state link in STD has come back to the a say we're in week we we had in we had an option to use a scheduling but it was not necessary but in this case we have to have a state link is required for perfect synchronization across the STDs the so the all the policies and the synchronizations will happen from active to the standby unit um what about we we unlike aces we have a management interface which which IP whose IP doesn't does not seen on failover so it's somewhat like a console connection wherein it won't be affected on failover if the management interface is alright yeah and considering the SMC's view all the policies will be pushed to to the FTD why the SMC actives to the active unit only and it's the job of the active unit to synchronize it across to the to the standby unit now we have we have a few platforms that were recently introduced which are called SSP platforms one of those is 9300 the other is 4100 and so on so so in 9300 we can only have failover in inter chassis you can't have a failure between two sqd applications installed on the same hardware on the same chassis so you need to have them on the different on the French RP also while deploying an application on the 1900 you get an option to deployed a standalone or though so you need to have this application to present the standalone mode only if you have it in Gloucester and then then the we cannot have failover configured also also when we are deploy an application on the 9300 we do get an option to we will have to assign certain interfaces to 9300 or I can show you that so this is our ninth agenda box so let me see if we have an STD so this is an 1984 my lab and it will have certain logical devices posted on it so it has an STD and yeah so while assigning while editing creating this we get an option to assign interfaces to an application so if 9300 can have three different applications so in order to have failure between 293 hundreds having STDs it is required that the STDs have same interface names so independent of the blade in which they are installed on that 9300 the FTD should have same interface names so these mapping should be the same then and then the failover will come up so that was about 90 channel so as I've described before we need to have two identical devices in hardware will be having of saleable link which is required to synchronize the FSM states and states of failover across the failover link we can use the same link for state state state state synchronization but what we cannot we can but it is better to have another state link so as the basic thumb rule all the engines all the config synchronization and states and transitions working will be done from the active to the standby there are certain parameters which which which decides the health of a particular FTD those I've mentioned here which includes laws not status if it is up or down what is the disk status is it full is it so it depends in decides the health of that particular SPD interfaces if a particular interface is down then we can mark that particular FTD as field and this office status so when we talk about when we talk about failover so there are two two things that are just like other that are deciding factors so the first of all there are roles and the others are States so primary and secondary are the roles which which we can also which are uniquely which which will uniquely identify a box and second active and standby other states so when we have so let's say we have a fresh failover and two devices popping up identical doses booting up together so in that case if both the devices come up together then primary will always be chosen as the active box now in X also if let's say if the box are already up and we enable seal over on both the devices simultaneously in this case as well primary will be chosen as the active box with regards to the SMC SMC will see this our single box and it will communicate all the configuration and synchronizations to the active unit only but obviously SMC can SMC will receive events really and reports into a connection and health my health monitor and stuff from both DSM from both the STDs so it will it will for configuration purposes since this is a single unit for FMC but for and it's the job of the active to sync it to the standby but for other issues such as events we will have both both the essence cities reporting to the FNC so this is my lab setup this is what has created for this particular demands for this particular session so I have an STD installed on my Asus 55:45 both the a system for device so I'm using big 0 3 as the interface which is connected back to back for you know both for failover state link and for inter failover interface 0 0 will be is used for outside and gig 0 1 is used for inside now I just using this diagram I just like to clarify certain points so I have configured 55/44 was the primary 55/45 a as the primary and system what if FB as the secondary now despite of so consider the failover interface so failure interface with an IP address 1 1 1 1 on 1635 a and 1 1 1 to 150 would affect B so these addresses they will always remain on the same boxes they will not swap during during or failover so we can be sure that this this IP will always be on the Box 50 45 a will always have 1 1 1 1 and 50 of Abib is always up 1 1 1 2 yeah so now talking about data interfaces consider outside interface so celebrity five is the primary intuitive would be the secondary now when I do a consideration for interface IP addresses we need an active I being a standby IP so that means in my diagram 192 168 76 dot ten will be retained with the active box so as I've mentioned before active is the status and primary is a role playing so either a primary or a second can be active at a time so at any given point of time whichever boxes the primary will hold thee whichever box is the active will hold the active IP on a particular data interface or another point to another point to keep in mind is that active IP will always be coupled with interface marketers of the primary so irrespective of any box being active it will use it will source its traffic by using primary interfaces marketer so let's say zero-zero has an market risk a and being zero zero one's 55/45 B has DB BV so active IP will always a source traffic from MAC address a and similarly for second sign by it will always go through traffic from bbbbb so in case of a failure let's save and secondaries active secondary will source is traffic from IP 76 dots 10 1 n 2 1 6 th and 6.10 and MAC address AAA which is the physical map of gig 0 0 on primary flowers I hope this is clear because this this this is required in case a lot of cases where in regulating certain units and stuff so let's move on to the next side so the here we have listed certain features that are supported on the firewall I will I will give you some time to go through it basically synchronization of firewall features in this slide knack tables TCP UDP connections not connection state are payable up inspection dynamic routing protocols signaling sessions all this will be synchronized perfect perfectly across the devices and the job of the activists to send this information to the standby so now so this this this light have a sudden some important points we'll discuss so these features that I've highlighted under ng of dill features ng of W features are features which are on the snot side of the FTA so in the in the first letter I talked about snort and Lena so so so these features are from the aleena side most of them and these features are some is not self so out of this I the important points are to discuss about the app ID I play seduction States by blocking in child abduction so before in with reference to a PI D for so consider like certain traffic is coming to firewall and firewall is yet to decide the application application name for that particular traffic so if before identifying that application the app ID if a failover is you know if if a failure happens the other unit will not be able to detect the app I applied it because it has not seen the entire entire traffic and also across failover we only only replicate the verdict so we only after identifying the application we send certain information to the stand by saying that okay this app is what happened this is Facebook and now you can match all the traffic to this particular connection to Facebook now the key point is here that we don't replicate internals steps that we take I mean the internal flow chart or the steps that we are taking in identifying a particular after so those steps are not synchronized only the final output is synchronized to the app ID or to the standby unit so if in case of app is not identified yet and a failure happens we might hit we might hit wrong wrong rule or a dog policy on the stand by unit so the next point is about IPS detection States so when I talk about IEP election state what it actually means is so let's say a particular traffic is supposed to hit a particular signature lights like it's a malware or it's a particular SNP traffic or something like that and DB traffic or something like that and I have not yet seen the regex that I am going to a match against a particular signature in that traffic and while doing so free lower happens so so the the new unit will not be able to completely identify give you a perfect answer as to okay this should match the signature because the internal steps in the matching of those X those are not synchronized across the IPS with regards to the IPS only STDs now like coming next to the file file malware blocking so given given a file it could either be normal clean or it could be malicious or the disposition could be unknown so the dispositions are unknown malware or clean now if in case if there is a particular file that is going to the firewall and the the current active has not yet decided the disposition of the file and if there is a failover then it is quite possible that we will let this file go through because the new unit the new active will not be able to identify the disposition because it does not seen the complete file now yeah so another another feature that is what discussing is the aperture protection so if the detection is not yet not yet happen before a failover then being the the other the new unit will not be able to detect the file that correctly yeah so other features you can have a look as a normal features but do those the change of the blue features required explanation well I'll give you some in seconds to go through it so let's move to the next slide so these are a list of ensembl features are I can just have a look the way the main point here is that with regards to a decryption decryption will only happen successfully if if and only if a particular unit has seen the SSL handshake on that box and if there is a failure between in between before description and after the handshake the new unit might not be able to identify and decrypt the traffic that's the key point here so there are particular guidelines that you need to follow when you are having the land sale over link and state failover link so yeah with regards to the guidelines they need to be the regular interfaces each the channel redundant or you need they need to have IP in the same subnet or LAN link is used for synchronizing interface States heartbeats MAC addresses on the while during this while the setup of the failover so as soon as we enable failover you will see interfaces MAC addresses being exchanged the device state is being exchanged over the LAN fellow length these stateful failover link is just for sanitizing the the connection states from the active to the standby now there are particular so if you see the diagram on the right hand side starting from top so these are possible deployments that you could have you could have failover link going through a separate which you could have failover link going through the things which as you're outside insert interfaces or you could have three leveling connected back to back to put this police in my lab it is connected back to back now on one particular topic that we need to talk about your is that sale over a silly fellow si in for transparent mode fibers so if everyone remembers transparent mode firewalls are layer two firewalls and they they are supposed to pass all the layer two traffic and they can also pass VPD use for extra bit of STP traffic so let's say if if a particular firewall is active or just passing the Lepidus through it understand by firewall is not passing people do so for though for the for the pores which are connected across the switch on the stand by firewall they will not be receiving any BP do so for them those ports are normal but as soon as there is a failover it is possible that you know the the new active will see start will start seeing the police across the across this across the new active firewall and the switch ports might end up going to block state because because the STP will detect a topology change so the work arounds where that we do apply in certain situations is first on the firewall we could just block the be produced applying an access list and that should that should do it but apart from there you can have a bpdu guard you can have an enabled port first feature on the switch you can increase interface whole time on the firewall this whole time should be more than the STP convergence time so that once once the ends STP has resolved itself if it does if it unlocks the port we can the filo till that time the field doesn't happen so increase whole time more than the STP convergence time and then you can also decrease the estimate Imus so moving to the next slide yeah so this is something have to show you why my lab just a moment okay there's some problem with my laugh so the these are the steps that we do to create an essay I was supposed to show you this while video some reason so this is interface IP address' for failover link I'm not using the same interface for both the day up as a chillin and sitting let's go back to the DVD so as discussed before for immediate interface we'll have an active understand by ID both lists both need to be in the same subnet the any data interface both the firewalls will keep on exchanging keeper lives on those interfaces sourcing from both the devices so if on the active unit there will be people s going out with sourcing from the active IEP destined for the send by P and from understand the unit they will be keeper let's going on on stored sourcing from the standby IP or destined for the active IP and this will use or the si protocol 1:05 that that we also use in a pillow to keep monitoring those interfaces yeah on on the on failover this is a swap so as I mentioned before the addresses move with the status of the box so who whichever boxes active will keep the active IEP and which boxes and we will keep the standby and also start using the primary Mac active box will keep start using the primary Mac and secondary standard box will use the second dream at one point to talk about this advantage of using virtual MAC addresses in failover so so as mentioned before primary Mac and distance will be used by the active unit irrespective whichever unit is active so what happens in in a case where in the primary device is gone bad so secondary will be active and and so secondary will be the active in it and that will be the only unit in failover so right now we have secondary active and no other unit and secondary is using source MAC address of the primary box which is removed from failover now we want to introduce a new primary box to the failover right so this new box will have different market rest so then we try to add this device to failover secondary will still remain active but it will have to switch to use the MAC addresses from the new primary so when when it does that the upstream and the downstream devices will will have will have we'll have our pantries which will resort to the old mac addresses so there is a chance of having a certain traffic outage in such scenario so we have to go and clear the ARP entries on the upstream and downstream devices so that these these outages are not there so the best so if the best thing to do is use the virtual MAC addresses so even if any unit fails we just have to replace the unit and the device can keep on continuing the virtual MAC addresses so we have that's what is mentioned here so taking into account the differences so as I've mentioned before or FTD has a management IP which always remains with the same box so a primary box will always have a management ID which and it will not change irrespective of the failover irrespective of the state of the box the management IP will be there on that box so this is this is this is a difference from me a severe in you say even if you have a management interface you need to have an active and the standby IP so on on or failover the IP swap so you have to go and reconnect this expressions again on a failover to connect to the new Activant to the newsstand way yeah so that is one thing which is different in FTD naa say in MCD in f3 there is a connection between SMC and the and the active unit understand by unit these are called exceptional connections so what a sense it does is it creates the policy bundle and sends it to the active unit and its job of the activity towards its orchestrate the deployment on the standby while while we are considering the AC you just have to enter the CLI on the active and those CLI commands will be replicated across through the standby unit now so one advantage of having a Maxim or a stable or a consistent management like an SPD is that during troubleshooting you don't have to reconnect sessions so let's say your your troubleshooting something or where in which things on standby after a failure or something like that so you need constant management sessions so that is available with the help of management IP of the equity because it will not swap on a failover whereas that is not possible for an AAS you need to have a console if you have to troubleshoot certain problems where which occur on a failover yeah so this this this table talks about the config updates to both the AC and the FTD's so yeah it's quite self-explanatory Oh SMC will push the conflict to the active node and active your in da say CLI is used to configure the active node and V conjugate synchronized also the active node will take up the job of synchronizing all the conflict to the standby and the same happens in the AC as well in case we're in standby you to the shutdown and brought back into H a sv active unit will synchronize all all of the policies and other states to the active or to the Sun bayonet and the same goes for the ACL so these are the platforms that we support I say on the thumb rule is that they should be identical units with respect to hardware software memory and number of interfaces there are certain issues with certain platforms as in a say 5506 5555 16 they have wireless modules so the config related to the wireless specific conflict this that is not replicated in the failover 5512 15 software and if i these are n GF w s-- with sub which does not have no issue we have 4.95 power 9300 on which SP DHA supported after one 1/4 same goes for firepower 4100 there is full support on vmware so we can have a CD SEO on STDs deployed on vmware as of now we don't have any support on a CD for H a on a SS environment oh yeah so oh so let's see particular devices lissa primary is active and secondary standby so there should be a reason for the for a failover to happen so what are those triggers what are the what are those conditions where in you know the active role will be given whether another you vent unit so the those those those things are trickier than the I've mentioned a few triggers over here so let's say primary is active and secondary standby so if the primary crashes it will see be actually the sandbag PD will identify that the other unit is not that on the basis of the monitoring on the interface and it will make himself active and wait for the other you need to come up and when the other unit comes up it will join us the standby in the failover so yeah unit reloading or crashing is one scenario where in where you can when you can have a failover another thing that you can do is to test the failover is to bring one interface down on the one of the interface so if we have less the secondaries are doing primaries sandwich so you can shut down a particular interface on the particular interface on the secondary active to see if the failure happens so on the basis of the interface policy so there is a the inside level configuration as we remember from a say there is interface policy so that policy is normally configured for one interface so if if there is at least one link down then they will be failover so in case in this case if there is if we bring down one link the the PHA levels figured other condition is where in the monitoring phase on an interface so as I mentioned before both the units keep on polling keep on sending keeper likes on protocol 1:05 across the intern that broadcast segment on from the active to the standby and vice versa so if in case we don't receive any keep alive for the whole time configured so there is a poll demand the whole time so poll time is something is the frequency at which we send the keeper lives and who that means how many whole times you can manage without receiving or keep alive so if if if we don't receive any keep alive until the whole time and doubles that timer expires then there's a failover declaring the other gym does field so another condition is where in the snort instances on the SPD are down so if if there if it's more than 50% of the start insulin are down basically then that can trigger a lower or with with respect to the f-series now there is something but as notification beam in India studies so this day might be used with a synchronizing configuration communication between the weeks not in the Lina component of the AC so I've mentioned in the first slide that there is a Lina component in there is not components we call Lina as well as the ACE engine as well so there is there's a daemon which deals with the communication between these two so if that Damon is down so that means there is something wrong with the health of that fire for the Deaf to do and we will trigger a failover another condition is the root partition available photos full up to nine different person then it means that the device is not in a healthy state and we will initiate affair over with respect to the ninety three hundred boxes so 1,900 bucks is have an OS on which there is an application hosting so it's like it's like it's like having a mobile phone and Android over which you have an application like a box up hosted so when the Android is not able to communicate with the whatsapp application and the backend then there are so similarly this is relatable to that so if the software of the chassis is not able to communicate with the software of the application so there will be hard boot failure in fact situations where this communication is failing or we will trigger a failover so yeah these are the triggers which which will cause failures and yeah let's look to the look into the next slide so this this slide talks about the licensing requirements and what how many licenses we use of when we are use actually nature so for for for bringing actually using a chain the only requirement is that you should have on based license on both the devices so if you have bass lessons on each of the equities then you can register them into these same SMC and then add it to NHA but but if you want to use go ahead and use certain features which require like set license manual license and your licenses then you need two of those licenses for every feature so let's say you want to use a set license on be used count only under the SMC will increase to two because both the units need to have this less insistence they can any one of them can pass traffic at any point of time and they will need the pulses to be deployed to both the devices yeah so that's the main catch from this CLI from this is tivity that on every feature needs two licenses so yeah so the next part is with respect to the creation of a series i'll points palsy points both here for a minute just take a break you so yes let's get started so in between if you have any queries you can post it in the Q&A section and we'll be answering those questions as well oh now let's go to the let's go to the prerequisites so you need to have two STDs register two and do an SMC with same hardware same software in number of interfaces the main point here is that there should be no deployment pending on the on any of the f-series and otherwise we are the we will not be able to create an essay it will throw an error saying that there is a deployment pending of on one of the peers and you might have to resolve that first and then do it so I had seen I had the same problem yesterday and I had to like resolve that situation and then only I was able to create the FT DHA so I just take you to my setup I've just shown you some time back so you can go on to the device section on the SMC device management and then click on so first of all we had these two devices registered separately to the SMC actually 5055 a and sed 50 of different B then we clicked on add and add that's availability once we do that we will get certain pop-ups we have to fill in that so that pop-up is asking for the failover conflict so we can also we also call that as a frail over bootstrap conflict this is similar to the configuration on the a say that we we do failure wall and in a primary failover LAN interface IP this salable state link IP that and all that so let's go back to the PPD I'll show you the steps and then so yeah so these are the steps before go to devices device management add add si once you do a let's say you will get a pop-up to identify which device you want to use as primary in which you want to use the secondary click on continue you will get to configure the available and interface and stateful interface so in this in this side of I am using both the interfaces of the in my lab with this geek 0-3 so yeah there's an option to use a key you can have a custom key or an auto key or two so in Auto key dsmcc self in generator key for you and use it on both the devices and for the custom game you can configure key so what is happening here is so when you when you deploy NHA on SPD what essentially is happening is f f MC is first contacting the primary STD sending this boost sub config that we have just configured to the primary first and enable filler and so there are two stages the blowing is conflict to the SMC once it is deployed enables failover on that particular SPD so and then goes to the second is since since since this is the initial part where and there is no active the FNC needs to contact both the primary and the secondary individually so forces it contacts the primary pushes the bootstrap conflict enables the failover on the primary and then goes to the secondary STD pushes the config enables it and after this after this they say we'll perform and you know on the failover link they will communicate and one will become active the other will income standby and they're on afterwards the other normal basel deploy deployments will just go to the active unit so I have a video video that I have created to show you the creation process of stha oh if you can see I have to separate as police after da say 54 to pee and 55 45 be so I go and click add at a or fill in those details I choose device type as far about 3rd defense divert if I a and suffered event B click on yes now I get so this this part is called the bootstraps convict and there is one important point to note here that you can only change the boost up config while considering the HEA same as same is the case with aces you cannot change the bootstrap config after the failure is working so this is one point to be noted so I'm using a custom key just go one two three Cisco one two three and [Music] you you so you'll get a warning acknowledgement - it will ask you to configure interface monitoring once you do a boost sub convict yeah after this I'll skip through pause the video and get through when the SP DHA is formed so in the task but I could see that first the SMC contacted the primary spend the boost up config enable filler on it and then it contact the secondary push the boot would smooth stub config and enable failover on the secondary so yeah you could see that the failure is setup primaries after second is standby so yeah so if you go to the this is an important point that I can I wanted to highlight as you go to the button next to the deploy button you will go to show history click on show history and then you'll be able to see the CLI equivalents of the commands that are pushed to the FTA so this is the primary STD so if you see this command three level annual primary sea level and interface d03 failover interface IP or real over any bill so all this command is similar to what we do these are the see like where so this is this is an important place where you could see what exactly is being pushed to the device so this under deploy or next to the deployment under deployments show history and you can see the transcript so similarly on the secondary box there's one important point that we can see what exactly is being pushed to the FTA with the help of the transcripts yeah so this is what how we can create an H a now moving to the next part so yeah so I speaking about the spoken about this so now let's next part is configuring the STD a so I'll just talk to doc talk about this using my FMC so let's go to devices device management and then as it DHA so you can see a high availability tab here so this first section I have already configuration this this is entirely the bootstrap configuration so as I mentioned before we cannot modify this this is done during creation so this is something that is deployed when the hae setup now you can you can have you can configure data interfaces and standby so once you have achieved applaud you can come here and configure the data interfaces so I have configured outside inside interfaces you can edit this so this is the outside interface after wipe is this and here is the option to contribute assign by P so this is the only section the monitor interface section from where you can configure or standby if there is no other area or part value somewhere you can configure or standby episode if you want to configure standby P you need to come to device device management's device management sa and monitor monitor interface section by default we will be monitoring all those interfaces but you can disable monitoring from the same dump so other point that I wanted to talk about this considering MAC addresses so I mentioned you are want to just have of having virtual MAC addresses but this is the place where from where you can configure so this is also on the same section under SJ you can add MAC addresses so you choose any of so big 0 0 is outside so you can have active MAC address let's say I have dead then dot dead similarly I have dead dot then God the EAB so this is the active mask the standby map so you have like statically assigned Marc addresses to both interfaces so now you don't have to worry about any units failing or replacing and even at noon you can keep it here save it and deploy it this can select for now so there's one more thing that I wanted to talk about from that point so there are particular times over yeah so I just want to talk about the failover triggered criteria this criteria involves the failure limit this is also called as failure threshold and in a terminology it is called as interface policy so if if this stays that if if there is at least one interface down or in field state then I'll do a feel over so that's the failure limit you can increase it to two or three but that is not ideally what is done on customer setups so now we have pole times and hole times so pole times are something which which which is of which talked about the frequency of polling so this something was pure whole time this comes in all this interface whole time so interface pole time are the key pillars that are sent across the raita interfaces so outside will send outside will send let's say 120 1.1 21.1 21 will send keeper lives to the standby IP we can have the standby be configured from here so so active so the primary box will send keep Allies sourcing from active IP to the standby similarly the standby box will send keep electron dot 2 2.1 so it will so as per configured Fulton will send out people of every 5 seconds and if I don't receive any reply or I mean any other keep Ally from any of the pure for whole time which is 25 seconds then I will declare that interfaces field so similarly pole time your pole time so this was interface Fulton now there is pure holding pure boredom is something just talking about the units so this is happening over both the failure interface and as well as the data interfaces so if let's say if a failover and the failover link is down in if I'm not able to identify if the ever if I'm not receiving any keeper lives on the failure interface the device will start sending Capella's on the data interfaces to see you know the unity so this is people time in pure whole time yeah so this was this this is all that I am going to talk about on this section this there are certain outputs that are important here let's go to statistics so the this is output of Sophie lower on the primary they say so this talks will say that primaries active and these are the synchronization that has done across the device consistent relation connection our table our table route synchronization simmer so this is this is this so this is similar to show failover output on the a si the bottom part of it describes these stateful transactions happening across the unit they can also go to and so see the transactions that are happening on the standby unit so this is statistics part we can go to the summary tab there is an important output there so it sees 5500 ka actives this stand by licensing enabled you are filtering read malware and beef licenses so the important output is d failure history if you click on this view icon or you'll see so this is the this is show fill our history output from both the units what it does is it it it correlates we show full of history from both the FTD's and displays them in chronological order so you see the latest event at the top and and thereby go down with the old time timestamps so you can easily call it what happens when with was box so as per this the latest event is 50 the 45 be went from bulking to standby ready and yeah and 470 by E the latest event is it went from active config applied practice so this is so Felicity or puller is being displayed under the summary tab on the f-series so yeah so this was the configuration part have talked about and this and this this as well so so let's come to the operations that we can perform on the SPD so if I go back to my FN c so if you see there are certain operations that you can perform on the FFT DHA so these options first is for editing they can this for switching second the third one is for break and last is for delete now I'm going to talk one by one about these actions so switch so what the switch actually means switching is just same as you know on making the other unit primary or triggering a failover so we can switch the access peers from the SMC and that how it is done is actually the SMT sends a no-fail over active command to the active unit and then it it it gives up the active role and the other guy becomes reactive so that is what is happening in the background so so in cases where you want to upgrade upgrade or the firewalls and socks then you can you can switch roles and perform an upgrade also in cases where in the deployment is not going through or certain traffic is not working through a particular device then you can switch role and think the other unit is successfully passenger traffic so that a certain use cases where you would use or low failover and see what is happening I have a video prepared for the switch as well so I have primary as standby and second is active in this case so it is asking you do you want to make the primary as active I said okay you know you can see that the primary become at this second case we can stand by so you have that song from this video this what essentially happens is you just and no further active command to the active unit and that triggers the failover so the next option that is present on the FT DHA is to break the être now what do you mean by break DHA breaking an essay is something like you know as of now I don't want to manage those devices and I say I want to individually manage it so this can be done in situation so just before the beginning the starting the presentation I had a set up where in both my primary and significant for active and I was getting a reason that we cannot detect others up here cannot detect us up there I tried many things and then ultimately what I had to do is are to break PSA once I did the break essay these were not registered as in as a part of the essay they become registered as individual units on the DFT and then after that went ahead and created DHA so breaking NHA is sometimes required in situations wherein we we are not able to proceed with certain configuration or an upgrade or something so we decide to get rid of DHA and just consume go ahead proceed with the configuration yes it is it is advised to do it as the as the last step if and only if you have exhausted all your options but that can that this helps in resolving a lot of problems so what happens when you do a break essay is that basically you do you you disable failure on the active unit and do a clear considered failover on the extreme unit and you also and then understand where you raised all the conflicts shut down the interfaces and it will just have the access policies so on the primary you will you will just remove the failure of configuration and disable the failure so it will keep all the interfaces up and it will retain the access policies which it had from me from the from the last deployment so it will keep on pressing traffic as the as it was while it was an active unit but the standby will have all the interfaces shut down and it will not have any failure policy or anything like that and all the individual be shut down and most of the config will be factory default apart from the ECP it will keep the CP access policies as it is so this this makes sure that you know even if you break the SI the old primary keeps on passing your network traffic as as a standalone unit so that that is what happens in the s break part in the background let's go to the break video so I have primary active and secondly standby on this setup so I am going to click on the break icon next to switch pair active so it tells me big media table there is all the configuration except TCP on the standby so that's what I was mentioned that it will remove everything and just keep the easy to understand where you see that after the break those those devices come up as individual F police on to the FD and now we will see what config was deployed to the units so so let's go to the primary first so you see that let me pause it here you'll see no failover and clear clear configure failover so this consideration is pushed to the primary and the secondary and also all the interface stuffs are down to the secondary so this this this PLA view can be seen from the transcript part so once this is done this in units will be managed as separate units on the F 2d H a coming on the MC and they will not be part of an H a so what essentially we are doing in break is just the disabling failover and doing a clear a failure on the active and apart from this shutting down all the interfaces and retaining dhcp on the second day standby so that was brief video no yeah so so there are so when when you try to break an SI let's let me show you that so it will ask you to do a force break so they will be situation where in the break action it will itself will fail why will it fail they'll be certain scenarios where in the the communication between the secondary box the standby box and the offense is not alright so it will not receive all this information and the break action will fail so there is an option to do a force break so what it will do is that on the essence from the essence is perspective they will not be and I say anymore even if it is not able to communicate with the standby pure so SMC will display two devices as separately registered boxes instead of instead of them showing in the edge.a if we don't do this the break the breaking will fail and yeah so there's an option to do a force pick Oh what happens what happens let's say let's say if we have if we have a standby unit which is not able to communicate with the SMC or adjacency so when I do a force break it will it will not receive the the clear configured failover command from the SMC so what essentially is happening is the primary unit will not have any failover config and it will start working as standalone and the secondary unit will have the failure config so let's say now it is able to communicate with the SMC back but it was so it knows now that it was standby so it will not pass any traffic so let's say in this state for some reason the standby box2d loads now when it reloads it comes up and see that there is no other box in the failover so what is going to believe that okay the failover is broken and there is no other box in the failover so I'll assume active role now in this situation you have the old primary running a stand-alone using the active IP addresses as its IP addresses and the end of understand but which reloaded and came back up as reactive so there is a possibility of having IP conflict and all that in this breaks scenario so it is - it is so it is better to as soon as you have access to the Box just shut down the interfaces and stuff that was one problem when you you can of course you can encounter when you do a break ok so yeah so I spoke about all this points are out there on the equity yeah also spoken about this if user do not do a full split then what can happen on the SNC the IP conflict part and the standalone part so all these points are covered so worst case scenario so let's say breaking the ice is not resolving your problem and you want to go ahead with certain configuration the break the break is not happening for despite of doing force break as well so what would you do as a last resort as a last resort we have an option to delete and si so when you delete an SI so what it does is it will actually delete the si and also there will be no devices registered to the Box to the SMC so you'll have to register it to the SMC to another SMC or to the same SMC again and try to make anything so so also when you do this SMC so the payload is broken with from the SMC perspective but when you go and check out circuit on the CLI on the obscurities you will see that primary's active and secondary standby and all that so so breaking deleting nhe should be the last resort wearing you cannot proceed or do anything and you want you have certain deployment that you want or need to go through and stuff so deleting is is one such option at that point of time one point to remember is that when you delete a particular expedite it is stirred to NSMC you know you will lose interface configuration you will lose routing so the looting end device is really risky because we have to configure interfaces and route your open Hammond's manually the only thing that is written on this MC is the policy unlike in thought fire modules we're in the wrong thing in our interface parts 1200 by ASE and policies were sold on a fencing so yeah deleting should be the last result and should totally depend on the criticality of this show so I don't have any video for talking about the delete but so I could just do a delete from here but I should say that would delete everything from S&P I'm not going to do that for now next let's move on to there are certain CLI commands that you have for your FTD so first is show how ability config the still show you something similar to show fill award we will talk about which is primary which is secondary what are the statistics across all that so these servers of this arrow that you see so this arrow is nothing but this is nothing but the the flesh of an SMC so let me just show you so this is the place so when you log into there pretty you are given a prompt which is with an arrow this is called as the cliff and you can run all the commands from there so from I think from 6 1 onwards you have you can run all the commands from here so you can do so so hi everybody 1 6 so it will show you the this is something similar to this so for your output on the AC it talks about which is primary is actually what are the serial numbers of the devices what is the versions if we'll talk about interface plates so I have inside interface shutdown I have author interface waiting this status is fine these North Persian is fine so these are something these other things which are monitored across the failover and these are the statistics that I was talking about that we saw under the Hyuga tab the routes thing tensed of the commands synchronize and stuff this is shown on the show high of Lutie conflict the next command that thiele that we are talking about this configuring high Liberty the same disability so this is similar to so similar to what we do from the SMC with the break so we can do we can break the table failover using the break options from the SMC or we can do it from the CLI so when the device is not registered into SMC and you want to break so let's say for example you deleted the a chip from the SMC but deleting the SA from the offense it does not insure I mean it the failure is still up on the ft-ev police so you can go ahead and do a configure high ability disabled so this will remove the failure punk from both the boxes and make it you know stand Alone's so yeah so there are certain use cases when didn't mention that let's say you're not the SMC that that was being used as gone bad so let's say you are using a hardware SMC to manage this is a pair for some reason that defense is not booting up so you want to add this F if it's a pair to another referencing so you cannot and so there is no functionality to add an extra pair to an SMC you need - in disturb those boxes and then only you can add it to make an edge on differently though so the force requirement is to disable DHEA so that you can do using configured high ability disable and then once they're disabled registered those boxes individually to the SMC and then make an AC there one point to point to mention here is that you have when you register the boxes on the SNC or you have to do the interface and the routing configuration I mean we have to do it by ourselves because we we don't have an option to discover SMC SPD's configuration from the SMC so that's something which is yet not supported yeah so we need to be cautious when we do tha or when we disable failover and it is registered to a new essentially so so similar to the same link failover on the aasa' we have when we do so on under they say when we do go to the configuration terminals and do a no-fail over this so if we do that on the active unit it it makes the current active unit as disabled like there is no failover and on this standby unit it will mean pseudo standby state so similar to that we have configured higher ability suspend so this is used in cases where and you don't want a failover to happen or if you want to troubleshoot a particular thing on a particular unit you want to keep that unit running despite of any other events let's say something is going on with an interface on SPD and it's going down value well because of because of some issue and you want to continue troubleshooting with that even as active so you can just to configure high ability suspend so this unit will remain active the standby will go into pseudo standby and there will be no failover so this is used in social situations where you want to troubleshoot or pause failover for some reason or disable failover another command is to so when you do a suspense how do you really feel over so to enable the failure you can use configure hi ready resume so this will make the active active again and put the pseudo standby state on the secondary and make it span back again so that's to feel like a man to resume the fellow now talking about the a bit obvious fdh a pair so when we upgrade vs a pair so we we cannot individually upgrade both the STDs from the SMC perspective it is an SPD H a pair it will it is an SMC job to you know do a hitless upgrade so it will first it will see really see really upgrade one unit after the other so it will first choose the current standby then the finally the current standby it will upgrade the standby when the standby comes up after these up after the upgrade it it will it will try to become the active and when once so if that becomes active the new standby will be given a file and then reloaded to come up with the staff with the new image now in case when when you know the standby is upgraded and it is building to gain the active roles from the other unit if they're also doesn't happen in 15 minutes then the ability will fail so that is one condition when the upgrade will sell so case wherein the stand by itself is for example and when a pushin upgrade and the up weight feels understand by itself then D then we will not proceed further the SNP will declare that updated sale and we need to retry doing that so in such conditions when you want so this is also an application I mean you can also use the break functionality here wherein you want to up get the devices upgraded and because of an SI are not able to do so so you can break the SI I'm going to devices and then we add them to the SI so this is one example of using the break statement yeah so it's C really does it it W is the standby first reloads it makes it active then updates the new standby and then yeah you will have NH a pair upgraded so now there are certain so how does supposed to deployment work for an FP DHA how is it different than standalone device so for before beginning everything I just want to point point out something that for and SAF DHA there needs to be at least one active unit if the deployment has to be successful so for the deployment to be successful there has to be at least one active unit amongst them so you can have active field active field and still the deployment will go through the exceptions are that you cannot have active active or active standalone my active standalone I mean there is just one unit in this field what those deployments will not go through and active active also do not go through apart from this every situation will the deployment will go through so let's say you have one ended in active at that in whole standby or another in the app saying so in this case of the the basic thumb rule the condition is to have at least one unit active for the deployment through go through now in order to understand what how the policies are deployed to the SP DHA we need to we need to understand few processes that are being involved so that there is a process called energy of W Manager which is responsible for communication with the SMC and also for communication for the SI of operation yesterday so these these process has two child processes called as configuration manager CCM and configuration dispatcher PD so consideration manager talks with the SMC gets the policy bundle gives it to the CD now it is a CDS job to separate the north part of the configuration and the leaner part of the configuration and give it to the snort and Alena and and hence the CD orchestrates the positive elements so now there are differences in the deployment I've spoken about the bootstrapping configuration for failover so that bootstrapping is the failover configured is being sent across to both the devices substance at that point of time since the create during the creation we don't have any of the unit as activists and way we need to spend those policies to both the devices the bootstrap one thing but now we are going to talk about the normal deployment wherein one is active other is standby so SMC will send the policy DB to the active unit the CCM will accept the file now this this this file will be sent across to the standby unit now now norm there's no this this policies will be after the active first once this is successful on the active so this is not site configured to apply on the active first and if this not side policies are applied successfully on the active unit we will send that we will signal the standby to apply the sort part of the config so once both the snorts are upgraded then we will say see signal the Leena's to apply the conflict together on both the f3 so for what happens is first not on the active is updated then not on this standby is updated now once these start is a breed if successful will update the Lina configure on both the side simultaneously because similar to a say this is Lina's in the CLS things happening so yeah so the Lina update happens together whereas this not happens first on active and then on the standby that's the key point to remember yeah yeah so long example we're in the standby policy so if let's say this not on the time is down so if the start of the standby is down we have first before this ever applied concept on the actives not but then we'll have to roll back this config since this not on the on the standby is done also if the Lina config is not applying if it is feeling then then also we have to roll back all the configuration so these are the few failures rollbacks scenarios where in you know the positive place feels in with completed rollback me consideration so basically if they if there is figure on any part like application on the snort on the active or application of this mod on the standby or on the Lina failures on both then we will completely rolled back the configuration so that's the key point so let's move to the troubleshooting section of monitoring commands that we have of the commands for the monitoring of the FG DHN so so this is so fellow state this is similar to so pharaoh state on the asus failover it will talk about the current state of both the units and it will also tell the reason for last failure so it gives you an idea so what was the last change and why why that happens next command is Sofia history this is also similar to what is shown on the AAC it shows the transitions from state a to state B and the reason for them so this is required in cases where and you know people come up asking for root causes for the reason of failover so we could just compare these outputs on both the devices and correlate the facts to understand they should better so this is one-button output so then the other output is the show failover output this is like the mother of all output because it will have all and each and everything listed in the serial number the status the interface status how is the interface monitoring normal laws beating or a dis field so all those things will be deploy will be shown on the sofa low it also have the snort in the de stateís along with the this the update statistics of the street full failover length one important command that is available from the click the caption command so this is similar to the capsule comin on the a severe ami you could capture keep allies on the interfaces to understand the reasons for monitoring failing this packet protocol 1:05 similar do I say bootable on the a sa so capsicum one can be used in various situations let the customer comes up asking one of the interfaces is constant monitoring is constantly failing I need to understand why so the best thing to do is just take a capsule on it understand to see if you are receiving keep allies for that time when the finger is happening if you are receiving then why are you failing over all those questions can be answered using the captain for months so now there are certain log first that V or intact check when there is an issue one on the on the FD eh-eh so there are two important fights that I would love to talk about first this process underscore yesterday of dot lock and process underscore stderr dot lock so these two logs have the the stages the transition stages the FSM by FSM I mean the finite state machine locks so the device transitions from you know active config applied to active from standby to active from absent to coal standby or asking to know active so all these transitions these transitions are mentioned and described in this logs if you have any issue related to you know device being particularly stuck on a particular state then we can go into this logs in or try to understand what exactly is happening this is under TD wire lock this file office present on the wire log another file that is important is the energy of W manager lock so this file talks about the various stages of the poles to deployment happening on the f3 so start engine as I mentioned before n gfw manager is process comprises of two parts CCM and CD TCM deals with the communication with the SMC and CD deals with a know applying policies on the snort and the lien up so but ng up W firewall talks about both CCM and CD policy applies so this includes getting the policy from the agency initiating the balls would apply posit deploy of the of the pulse DB application of the snot config and application of the lien of conflicts all of this are being will be talk will be you know describe an injectable manager lock so any thing related to pulse will deploy or NES a functionally you can just look into this logs to identify what exactly is happening so these two locals are very important now so the main Orchestrator in sa is the CD conclude dispatcher so consider dispatcher receives a lot of events from lino of the local unit and the remote unit so um so every time it receives the even it writes that to a file and that file is stored under ng of the blue wires cisco and general manager store assisted so this HH state is the state of the state of the unit the silver state of the unit which is which is pulled by the SMC to display primary active and taking the stand on the on to the GUI so this is an important location so if fsnc is showing some let's say if you do Sophie lower status on the firewall and you see secondaries active but in the on the primary on the essence your thing secondary standby there is a mismatch right so you can just come here and see the file what does this file what is this file talking about it is wrong or right so mostly SMTP output from here if there is a problem with soda it has a fancy declaring a wrong state as a workaround I mean a week we have like seen that you know changing deleting that file and adding it or resolve these issues so now the next stop step is if you look into all this locking still not able to figure out what the problem is the next step is to contact act we could generate the double should file for generating double should finally need to go to system health monitor click so this window is is the drop down when you click on that you'll receive the devices with normal status click on the appliance and you get the next stream screen to generate troubleshoot click on the generate about settings files generate the double shoot and once this task is queued and completed you will see it under the FMC task manager and you can retrieve this file and upload this to the case and wait for taxes points so so that is all from my end or under SP DHA I hope you have a few understood most of the points that were covered I will now invite swings II to take over and continue with the fire power management essay or feature you you hello everyone this is she may be medicine man from Cisco Tech and today we'll be discussing the fire power management center high availability to give you a brief introduction about myself I've been working with risk over the past two years as a tack engineer we primarily deal with the fire power ng IPs and ASM and third grade appliances so today we'll be concentrating on the fat burners and central high availability so the main agenda or focus for today it's going to be on configuration and maintenance and troubleshooting practice practices that are you know advised if you have an F and CH a checkup in your network so I'll let you read the agenda for a couple of minutes then we'll move on to the next slide all right so before we start let's understand why we need the FMCSA the purpose of high availability is to allow us to have two devices which can maintain both your event data and the configuration information and in case one of the devices fail the network monitoring can go on uninterrupted by using the others other device so let's understand how the FMCSA basically world doing exceptional 5 3 & 5 4 there were a lot of issues with the Hetchy and the developers decided to you know take change the data bases and make it make this process much more effective and on 6 1 0 and about FMV hey check out a facelift and came back up new so which means that between the versions 5 4 & 6 1 0 which are 6 0 and 6 v rho x series FM CH option was not available in case you have an HJ in 5 for X and you're looking to move the HJ to the later versions what we would advise is to bake Hetchy on 5 4 x upgrade all the weight of 6 1 0 and then set up the Hetchy again 1 6 1 0 before setting up the hatches there are three main things that we need to check the first of the hardware SMC is not supported on virtual environment so the hardware on both SMC devices which are intended to be put in a chip must be identical the software versions must also be the same when I talk about software the major minor and maintenance releases should be the same and also we are the best practice we should ensure that the VDB SRU versions match on both ends this is to avoid issues with configuration sync and a lot of other interruptions that met because if it's not ensure and posters with it we also need to make sure that the valid licenses are purchased and they are added code to the correct device so by talking about licensing that can be two different mechanisms or methodologies that can be followed one of the classic licenses and the next one is a smart license so while using smart licenses five full series we would have added those separate individual licenses for all the devices on both the active and standby fnc before proceeding to set up the hea otherwise this causes caused problems during synchronization however on the six ones with six one zero series in about the only light that the licenses need to be installed only on the primary SMC and this will be replicated on to the secondary FMC during the hea synchronization process moving onto smart licenses at any point of time there is only one SMC which contacts the smart licensing satellite as in the UUID of the active unit is tied to the smart license satellite which means that when I'm switching over to the searched and by unit the rules the other SMC would contact the Smart Search licensing satellite and get the licenses for all the devices for the purpose of simplicity and as well as to avoid a lot of confusions we are going to be discussing Hetchy features only on SMC six one zero above there might be a small mention or comparison to 5 for X but they're going to be dealing primarily only with 6 1 X about the next thing that we would we would have to keep in mind is the registration of the devices so what are the best practices that need to be followed when we are setting up the FNC Hetchy would be that they remove any devices that well if they are registered to the secondary FMC these need to be deleted from the UI because this would cause problem during the setup as well as these devices need to be moved over to the primary FNC apart from this any configuration that is present on the secondary FMC will be wiped off so import or export any policy that you would like to retain or any configuration that you would like to retain move it over to the primary SMC before setting up the Hetchy and like I mentioned if the this is a new setup registered all the devices only to the primary or the active SMC then poster H is set up if you're having issues with the night not translational if you have not in between the devices and references and you're facing some issues due to this there is an option to assign a different not IP address on the head a standby standby page so in case of any issues with the registration fail failure it is advisable to remove the device from the SMC primary offensive and try registration again to the 5f primary assembly so that this process is initiated again so the one major requirement to set up or register any devices to the SMC would is that both 8305 is where is the port that is used for communication between the primary FMC in the second a fancy as well as sensors or sensors are nothing but your ng IPS or your FTD devices or it can be any device which is capable of could be managed by the FMC so now that needs to be both a 3:05 open on all all ends so that the communication channel can be set up accurately to tell you a little bit more about dissect tunnel this is nothing but a secure tunnel which is established through which all file transfer configuration transfer event transfer these all are passed through their system so this is something that is very important for setting up the headaches all right so then this brief overview of this process that we that we spoke about on the active SMC we add the add the device it provides the details so the for the device and then you start the registration so the active SMC will then initiate a discovery process and once the device has successfully discovered it the active the FNC or the different center ask to stand by SMC to you know add itself as an additional manager on the device now during the next synchronizations cycle the standby offense SMC would then ask for a registration to go to the sensor and after this those the sensor would be successfully on both the active and the standby unit so once is a successful events are sent out continuously to both the primary and the secondary sensors what are the issues that can be reported during the registration there are two error states that it can transition to one it's a local miss or the remoteness localness is pending registrations or devices that fail to register on on my cell for the act of the FMC and the remoteness would be on the remote F and C if the if the devices you know tending registration or not not getting added so these are the two errors that can happen these are mostly due to both 8005 not being open or some communication issue between the SM between the either one of the FMC's so this could be the primary reason for why registration could fail to one of the devices great so moving on to discussing what are the main rules or main terminologies that we'll be using throughout the presentation we have the rules which are defined as the primary and the secondary the thing to keep in mind is that the primary is where all the configuration is maintained so during the setup of the setup of the FMCSA if you elect one of the devices is a primary device this is where all the configuration and the device needs to be registered to the secondary will have all data wiped out and this is something that we should really be careful while setting up the FMCSA apart from that there are active and standby status so the primary would all will be the first active device and there is an option to change the rules to active or standby and they stole the based on the role it's a you know the SNC if in case the primary fails then you can promote the secondary to the active unit so this is the these are the terminologies that we'll be using most commonly on the on on the throughout the slide moving on to event processing so we have spoken about configuration so let's talk about eventing which is the next most important thing that the SMC is used for so there needs to be separate management IP addresses on both the FMC's and these will not be exchanged or swapped to swap during the Hetch a process like like a shuffle of mention on their sketches it was quite different but the the there is only one active and at any given time unless there is an issue the other unit will also be will always be in standby since they have two separate management IP addresses we need to make sure that all the communications that need to be permitted out of the FMC's management interface are replicated on both ends by this I mean allow access on the firewalls to ample malware clouds for disposition checks for file up to upload to thread grip for analysis as well as for the URL category download to write log database si reputation download so all for all these databases download we need to permit specific access to both the management IP addresses let's talk about how URL category would work so we need to manually download ensure that the databases are download and up-to-date on both both the active and and the secondary FMC so since the transition from active to Samba is not automatic and this has to be manually done during the time of failure ensure the secondary is active only then will it start communicating to the cloud to get all the disposition and the information that is needed the next main important thing is that if you have user based policy setup and just learning the user information from some identity source like user agent eyes TSA agent or captive portal they would temporarily fail and the reporter and the users will be reported as unknown until the time the failover becomes healthy and then leave the degraded state and the second and the second race promoter character and then it will start discovering the identity information again and the use of these policies would start working coming to configuration management like I mentioned the SMC would enter a degraded State in case of a failure and the Santa if something has to be manually promoted and only then will they check the degraded State so what are the configurations are synced between the h8 devices during the time of setting up of a failover or regular configuration sync process I've listed the configuration that would be sent over the main the only thing that I would probably check is that if there are any custom their mediation modules that are present only on the active SMC make sure the the primary FMC's contamination module are also configured on the secondary FMC to ensure continuous working of the remediation module ok so let's move on to discuss the architecture so black mentioned earlier those sensors are the devices which are continuously sending out events to both the active and the standby SMC now the event data is stored in MySQL database on RN and there are some other non configuration related data that might that might be present on MySQL databases as well so during the setup the setup of the HEA there is there are two processes that happen within the external one is the transaction framework where in any data apart from the config like licenses or any files that will need to transfer will be sent by other transaction frame frame one and this is unidirectional from the active to the standby FMC the same way there is a configuration database on this entry which is called as side this now this these to communicate those IDs on the activation see and decide based on the stamp is MC communicate through Starbase Marini through which the configuration data is passed on from the active to the secondary of MC to make sure that there are of the non conscious data which are mean which might be needed to be sent over to the standby SMC there is a process called symmetric TS which converts the non configuration related data to cyber databases as well so that this can also be passed through the service modeling process so like I just read reading this again there are three synchronization mechanisms one is the sideways mirroring and the transaction framework which are in between the two FMC's and there's something called symmetric BS which is running inside for to convert the non-conflict related MySQL database to service all right so let's move on to check what what would be considered as healthy on the Hetchy when when I have and had she set up what are the processes that on the background should be running let's let's let me stop sharing and take you back to the take you back to the devices that I have set up in Hetchy so if we take a look at this let me run through the processes again the first main important process is s external make sure that the s external is running without any any issues and that the exceptional successfully setup the second process that we're checking to see if it's running properly is s FIP proxy this is a very important process again because a lot of data is passed through a substernal why is fib proxy this is responsible for opening up the ports on internally which are responsible for for this transfer to take place as well as there are two other processes that I would check is a Sybase so the Sybase would be waiting on waiting state on the standby FMC and it would be on the active State on the primary SMC this will also be this this would also not be present and then it will not be running on a standalone efficiency device so this was run only on the active SMC of the Hetchy so the last process that I will be checking is symmetric so the symmetric BS is like we mentioned as the engine that is responsible spoken converting a few non configurator data to the side a so that can be passed over the hele so now this should be running you will see this process running even on a standalone SMC so these are the processes that I would check and the same we can check on the active SMC as well to make sure that the hatch is healthy these are the gentle processes that I will be checking and like I mentioned the side disappear arbitral the process would be running on the actives F&C so this would be a good way to identify which is the active SMC by looking at the CLI all right so moving on to the the processes we have discussed what are the important processes that are required for the synchronization next let's move on to discuss how the hea establishment happens and what is the flow that happens in the back end when the FMCSA is set up so the first thing is there is s external is again the process which is responsible for ensuring continuous transfer of data and internal tunnels are all set up on top of the exit tunnel so once this is set up successfully the transaction is initiated two copies files licenses and all other information are transferred once this completes the Sybase Miller angulated changes are done which is nothing but the configuration so all these are passed passed over there's a tunnel as well once this is complete a periodic sync is ensured between the two FMC's so that there's something called the synchronization demon or sync sync D which is responsible for periodic you know filed application and this is also something that is responsible for hearing hello hello or exchange of hasl messages between the FMC h's all right moving on to the part of setting up the FMC Hetchy there are eight steps that are involved in this let me take you to the to my lab device where I have an active SMC setup so that we can discuss this you all right so this is a SMC and happy that I've already set up now where I would check the nature information is under system integration high availability this is where the status and the of the hatches maintained and any operations that you would like to do is done from here what are the prerequisites walked up quickly through the checks that we would do before setting up the Hetchy the first thing is we would navigate to help about section and check whether the hardware the software version X REO and the Willoughby are same on both ends and then we will select a designated primary unit now on the primary FMC makes sure that all the devices are registered only to this and on the secondary if in case we need vices are already registered remove them from from the secondary export all configuration so we do this by by the option system tools there is import and export then you can take all the policies out of the SMC and sorry about the pause so let's move on on the SMC of the SMC we will be registering their devices to the active SMC and we make sure that all the devices are removed from the secondary FMV as well as the configuration is exported out of the secondary SMC and added to the primary FMC now once all this is ensured we can navigate the system and integration and make sure that we set up the primary device as with the role of primary SMC and the other one with the secondary FMC and during the registration process we would also be asked prompted for certain information this I will show you on a FMC that I already have which is not a part of a hitch here so under high availability option we would be seeing this FMC currently with the standalone status and entail you want to put this as the primary FMC we would be displaying this information here all right so currently it's a standalone as an Ohio ability is present so the minute you click primary the successful for the secondary FMC whose IP address the registration key and an eyetie ID so the knowledge ID is is nothing but a key that needs to match on both the primary and the secondary senses this is applicable in case there is an art or firewall in between the two fmcs that are intended to be set up in Hetchy and this means we need to make sure that the notch ID is the same on both the primary and the secondary fencing so yeah you you okay so let's quickly skip these parts we've already discussed it so on the high well building in secondary we we recommend that the high ability first me set up on the secondary unit and then move on to configuring the primary so on the secondary provide the IP address of the SMC and the registration key and then we want to set up the set up the same on the primary SMC as well and click on register so once this is done there will be a prompt warning displays asking whether she only want to set up Hetchy will proceed to sell aps and during this process it is completely expected to see a lot of messages pop up on the task manager as well as the system UI mentioning that you know the certain process will exaggerate or some importance of being refreshed this is called completely normal during the initial stages of the FMC Hetchy setup another thing to remember is that how long the most commonly asked question here is how long does it take for the FMC Hetchy setup to be established now this really depends on the databases because like we said there is event and the configuration database so what we do is is set up the set of the variable someone requesting to share from step one let me take it take you back to that and so that we can see from step one what are the things that need to be implemented so yeah alright so on the step one we check that this is a snapshot of the help about page note that like I mentioned earlier this F MCHA setup is not possible on virtual machines it's only possible on hardware this is just for snapshot so make sure that the software versions are same and then once this has been confirmed let's move on to setting up the head chain which is under system integration high-availability which as I showed on the UI so it's configure the high availability first on the Gendry input the selector role as secondary input the primary host and registration key and that ID if applicable and then let's move on to setting up the primary SMC so we will navigate to the UI so this is nothing but a snapshot showing that the registration of the hi everything was set up successfully on the secondary now we move on to setting up the high availability on the primary we will navigate the system integration we want to hire with a tab on the primary essentially select the role of this fmcs primary and then said at the secondary host IP address here and at the registration key that ID is required and then go ahead and click on register so once this is done there would be a prompt asking you whether if you want to proceed with this click on yes and then there will be a lot of tasks displayed on the health health as well as the FMCG why and the FMC status will be degraded until the complete checkup is done this is to be expected and coming back to what I was originally talking about it there should be a good bandwidth between the FMC's for the configuration thing to happen really quickly and depending on the database size it might take it might take how much ever time it might require to transfer all the configuration files during the initial setup apart from that the device is also the FNC would also start sending out registration requests so the device is the secondary SMC and the registration between the devices would also happen during this time so once we have set up everything and we would like to verify that you know the hea has been set and set up successfully you would navigate to high availability tab and check whether the summary the under the summary the state is in the synchronization have a green tick mark this is expected expected output that that we can see on both the primary and the secondary assembly moving on to discussing about the actions that you can perform on the FMCSA the first one is switch peer rules let me take you back to the lab device so that we can take a quick look at where this option is available and what happens when we when we do this so when you click on the switch PA rolls it would prompt you asking to whether you want to continue performing this I would go ahead and select yes and this would would initiate a lot of things on the background so one more thing that we can take a look at while this is happening is that if you see there's no deployment option here this is the standby the FMC that I elected as a standby so there is no option to deploy make any configuration changes that you would like to hear so this page will display only information regarding the Hetchy as well as a few other licensing and device related information all right so once I select yes to the prompt you will see a lot of messages appearing on the task on both both the both the FMC's so let's wait for the synchronisation time to expire after which the doing the next thing though this is going to be communicated over to the second day of the standby SMC as well and you will start seeing a rule change reflect on both all right so you see the problems that you see here are quite normal it's advisable to have and advise to have some patience while well switching rules or breaking Hetchy or setting up Hetchy and like I said it really depends on the database size server size and the operations are run in the background so attack cannot have a good estimate on how long this process or each of these processes will take so I have done a previous switch switch roles and you can see that once it's done it would give you a green status saying that the FMC switch role was successfully successfully completed so this is what we are waiting to see and this might takes time so we will come back to it later moving on to the next job that next option that you have on your head shape age is the big Hetchy option so while clicking on the brake HJ again there is a warning displayed requesting to check whether you know the you want to proceed with this so I would say yes to this if I really want to break the HEA and then move on to selecting what happens to my devices so at a point of a business successful hatch is established there is a active external communication between the devices and the primary FMC as well as the devices and the secondary FMC now through this channel events are continuously sent out so during the time of the registration or the breaking up of the hekawis me to decide what happens to the devices that are connected to both the hatches edge a units so there are three options here one is that from the unit in which you are breaking the HEA you can choose to manage devices on that console or you can choose to manage the devices on the remote console or you can stop managing the devices on both using both their senses so these are the three options depending on what we select the devices will be deregistered from that corresponding FMC or will be the B register from both the offenses moving on to the next feature which is called as pause synchronization so this is self-explanatory the the name indicates that it's got the post of synchronization between the primary and and at the second a FMC so during the fourth pause synchronization the point to keep in mind is that if we are pausing the synchronization on the primary FMC resume can be done on both the primary and the secondary FMC however by pausing the synchronization on the secondary unit the resume can be done only for those secondary from the secondary FMC so this is something to keep in mind and not worry worry about in case you run into the issues scenario wherein the synchronization is passed from the secondary but I'm not able to resume the synchronization from the primary this is expected behavior before we move on to the troubleshooting let's go back and see if the sink was successful and let's look at what happened on the UI so the switch role was successful however the databases are being switched and this is what and this process might take a little long long as as well so on a previous transaction you can see that the database switched roles were successful as a and I promoted this unit from standby to active so the primary and the secondary roles will not swap during the during the ritual action at any point of time I would not be able to see see any specific action indicating that the primary and the secondary is going to be switched over sir yes so the next feature that we've talked about was for synchronization I will wait for the H a to be healthy before proceeding to do this moving on to discuss troubleshooting or what are the things that we will look at when an SMC hit she feels and understand what is the problem so the first thing that we can follow is the visual inspection while performing any action like an upgrade or a backup or something specific to to a database change on the FMC the achieve status might go to degraded or might show up as field for specific reasons so the cases where this is expected or normal and there are cases where and this is not the expected behavior so the first step would be to understanding whether the HSA to the status that we are seeing is something that as a result of an action that was performed recently or was it was it done because of a failure on defin see so we would look at the health alerts to understand if one of the devices had a power failure or if one of the devices had some network connectivity issue which might stop it from talking to the other other FMC putting the H a and a degraded Brigade at stake the next thing that we can check is we saw an output of how the hedges should look like if if the hijae is healthy azzam we saw a green tick marks next to the status and the synchronization whereas here on the snapshot we can see that the status of the H is degraded degraded and the synchronization is shows up as a warning saying it's failed as well there could be different reasons behind why this status is displayed we'll discuss it in a later slide but a snapshot of this would be really helpful and the standing the reason for for why the H is currently down when you're engaging your tach all right so now that we have moved past the wishful inspection where do I look at logs on the FM on the fire site management center itself to understand the reason for the failure so the I would start by looking at action cue messages which are which indicates stage change it changes on any anything or any tasks that is happening so that will be displayed on your chinkyu law this is underwire law so we would be looking to see any Hettie related messages that can that can give us a reason for why the hell patient failed moving on we will also be checking under messages so the messages would print out anything related to the device itself so the processes which are running if they've stopped and for what reason so we can look at some critical processes that are responsible for the HEA and grab for any error messages that you see related to these processes or any failures on these related with the processes and that would give us a good information of why the failure is occurring apart from that there is symmetric tort law which can help us understand if there was a failure within with the symmetric DES which is the process that is responsible for converting on tables which are non config related data that are present on the MySQL tables to the to the Sybase tables so we can look at some any errors of specific to symmetric dot log and the symmetric 30s and then move on to sink d dot log so the synchronization payment is what is responsible for transferring files across the SS panel like it could be licenses or it could be any hae related hello packets which are missing so these can be seen on nursing d logs which are again under bar law and then there is mojo dot law this is related to any UI UI issue that I'm seeing on the FMC so I would take a look at module dot law apart from this there are a lot of other things that tack engineers can look into to understand what exactly happened during the time of the failure to ensure that we have enough data to troubleshoot the issue right when you notice that there is an actual hip issue of F and CH a and you would like to involve that to investigate this further collectible should files from both the both the actors and standby offenses because there are certain data which are which are present only on the FNC or only understand by fancy and both the troubleshoots are needed to understand what what happened or what went wrong on the on the UI so apart from this let's go back to the let's let's go back to the CLI so that we can take a look at the processes so make sure that the PM tool status are all green and healthy during the time we should be expecting to see running or waiting process according to the according to the process we are checking apart from that if the GUI is down this this is quite common while there is a break in the hea operations the GUI might go down the reason for this is because when well while the UI is displayed there is a high dependency on the Sybase databases as the arbiter process as a lot of engines that that are closely related to the processes that we are seeing here so doing in time of an issue and their fancy hatches in a degraded state it could be possible that one of both the UI's are not accessible so now how do I get out of this scenario where and I'm not able to access both the UI so I am not sure what happened to the FMC's that are in hatchet I understand there is a problem but I would like to understand what are the states that are in there are two scripts they are available in built on the SMC itself so the first one is troubleshoot underscore hatch ad C dot peer and the other one is managed and the school hid feed appears to run these scripts we need to SSH to the SMC and then enter the route prompt and we should be able to run these two scripts keeping it side by side for reference so on this I am already on this offense am already on the rooftop so there is a script already available on lessons itself this doesn't need to be installed so once you run this there is a little options display indicating what are the things that we we would like to check so troubleshoot it underscore HDD C dot P L is just a troubleshooting utility so there are not in there it doesn't generally cause any conflict change on the back end so it should be safe to use so let's let's take a look at option one so it puts up information on the current status and shows us a lot of information with regarding what is this what are the FMC rule which FM CM I'm looking at the status is healthy and I'm able to the databases are supposed to be up and running these you know healthy on on on my end this script can also be run on the secondary or the standard SMC to understand what is the current status then we can execute the database ping which is it's an attempt to connect to the system by unit and check whether the databases are communicable from both ends apart from that you can check the arbitral status which which which is the Sybase arbiter it shows up as running and healthy in this particular output and then you can also check the the TR connectivity so right here we would be needing the PRU UID and so I'm just going to enter now so we can see that the displayed information stating that this this this output would make more sense is passed on to the attack engineer because these all represent a certain value on the device itself or the parent which we expect to see all right so the last would be let me go back to the script the option file which is to print messages of the action queue so here again there is a dependency and it requests for a specific task ID so if you're looking for let's say a DC sync you can input input the specific task ID for this and then this would proceed to show information related to this again this would be something that that would make more sense to to understand what are the error messages that we saw that might have relate to the current state that the FMC is on so if I want to exit the script I would go ahead and use 0 this is an option to exit the script the next most important script we have already learned through the oceans as in what option 1 2 3 4 & 5 stands for the next clip that is inbuilt and present on the FMC is managed underscore h ad c-- dot PL I would advise caution while using the script is because there are a lot of changes that can occur to the SNC databases when while while running this and selecting an incorrect or non intended option so let's you I looks like there's some modification on the script on my on my primary SMC but so let's move on to discuss what are the things that he would what are the options that we have while using the management of scores hed0 to appear so again you can you can choose to show the Hetchy status and this would display the messages as well as you know they registered this as the secondary or the primary unit on an FM CH a so this basically is the UI equivalent script that runs in the background while initiating an hour action on the SMC H a UI page itself so a most common option that we would use is pause meddling so this would pass the this opposed the transaction between the two FMC's so my SMC is now healthy and a poster role change now what I have done is executed a possible inning let's look at the UI so now those the date resumed synchronization is auction is available only from the standby fmcs we discuss because before because we ran the script to pause the synchronization on the on the standby SMC so I can't choose to resume the synchronization again and this would start the sync between the SMC be active and the secondary units okay the while using option 9 or 10 let's be very cautious and not inputs of a number that might cause a break in the hea operations completely and end up leaving the Hetch a in a in a world you know much more degraded state than it was initially so awhile to troubleshoot underscore HEA defeat of PL is relatively safe to use manage and let's go ahead JDC got plz subscrip that could be avoided and you know there's to be used as a last resort moving on to the most common issues that we would observe while using while looking at the fnc h a in a degraded state the first one is a missing UI so either of the SM FMC's you I could could show 500 internal error or not load the UI so the general things that have be boot churches this is definitely a UI related issue so there is a HTTP and the score error log which is present under log HTTP d and this work shows information on why the UI is unable to load up there are some specific error messages that would indicate whether certain permissions are not available or if so process which is responsible for bringing up the UI is down so under this we can get more information on what exactly is preventing the HTTP page to load up apart from that the path that I've just mentioned VAR s FS chilidog start page data of Lima so the samel is a place where in you know is really this stage this data is really just important to display anything on the UI so touch typing in touch - touch command can also result in bringing up the UI however well you notice some error which related to the UI are not able to understand what those asset messages could possibly mean it is always advisable to you to collect the troubleshoot files and involve fat so that the back end processes which are running can be analyzed to understand the issue and then the next common issue that we can we would be noticing during a HAF MCHA operation is that the switch during a switch one of the SMC shows up as system processes are restarted and they do not come up at all after the hea switch role so what the there are three tasks which are which occur in the background while this switch role is initiated the first is that the local agency has to update its its status and reflect the new change in role and then it has the second the the other unit has to reflect this change as well once these two are done there is also Sybase are better which is responsible for making sure that all the follow-up tasks are done and that it's reflecting it states to this to ensure that that the currently active and the standby units are reflected so once this is done and the and we can check the wall log action queue messages to see any messages related to database switched roles or any errors or failures that we have seen and then obviously you can run manage underscore h ad c dot PL script that we just discussed and choose the options I believe footpaths meddling and once the mirroring has been posted he'll give us a move their side is the mirroring that goes on than the background is the this process is there there's going to be no dependency on this process and then we can proceed to in investing as to why the UI is not coming up by looking at these error messages looking at the processes which are down so like I showed before p.m. to status and grapping for GUI will give you all the processes that need to be running just just so that we have it for reference let me pull this up again so ya option file for pause meddling so once you have done the done that we can check the GUI processes to understand if that although all the processes are healthy and in a good running state as well as look at the HTTP error logs at some time we mention and look to see if there is any specific error messages that we are seeing in action queue and where log messages that could indicate the problem you all right so once the GUI is up assuming we fixed we've identified the problem and one of the law messages we are seeing we have identified the reason for why the processes are down we can take steps so corrective actions to ensure that the UI issue is fixed and after this is done we can check for side rails issues if the UI is fine but there are some specific error messages that you are seeing related to Sybase we can fix that as the next step and then we can continue to resume mirroring and this would this would start the transaction the synchronization between the two FMC's and they would resume the healthy status and we should be able to see both the UI so once this is successfully done so we have discussed switch roles and UI gone missing during due to some reason and 500 error messages displayed display because of some permission issue on the backend so the next common case scenario that we might run into a database synchronization failures so then there are two different databases on the on each FSM SMC and there is a process running to make sure that there is a healthy communication between the MySQL and the Sybase as well as there is a lot of processes which run responsible for communication between the two FMC's itself so any one of these could cause issues with database synchronization not happening so the most common symptoms of the problems that you can see would be the SMC hash a page would would would never show a green tick mark and even after that it resumed synchronization is done and the SMC mint shows system processes are restarting like we saw on the UI Jui issue that we discussed before and a chair breaks big failed and one of the devices did not come up after the break so these are all you know side effects or symptoms that you would notice when there are some database failures happening on the backend so again the first place I will check for any any issue with related to her chair would be the action queue and I would grab for error message with regards to Dell you think and I know and and then check if all the processes are open TM tools that will be the next step and then look for any specific decide based on the process STD out dot law as well as the error log and make sure that there is a proper minimum network bandwidth maintained we will advise around five AP is at least between the two SM seems to make sure that the network has been of language to transfer if in case it's a huge database on both the devices a lot of policies a lot of events then it might be recommended to have some network better network bandwidth between them so this can be this can be a call that can be taken post looking at the normal operations and checking to see how long the initial had say actually took to be set up and these are some things that can give us information on on why the database synchronization could not be working or happening apart from this there are failures that can happen right at the start of the HJ establishment so a change stablishment can fail with the following error messages so one is a message saying that the peer already exists or on the Hetchy basis or sub sink sink is failed or degraded or a warning saying that the peer has fewer devices so starting from the last one peer has fewer devices this indicates a there are local or a remoteness this would ideally be remoteness so the other other SMC unit does not have the same amount of sensors that are registered on the active or the primary I fancy unit so this might mostly be due to communication we would check the connectivity and then if in case there is a notch ID that is required we would input those details understand by fancy and move on to fix this issue by troubleshooting like activity and then if we the last resort that can be attempted is to delete those devices from the primary and reattempt the registration and during this time there should be as long as the hatches and a successful or healthy status the SMC should start talking to the sensors again the second day SMC and attempt to be established the communication channel and this would mostly cause the issues to be resolved when it comes to local or remote messages then moving on to degraded status when when there is when there is a error message with degraded status which is displayed for a really long time then we would need to investigate the logs mentioned to understand you know what are the cause what could be the cause for the synchronization or the to feel again the other of other status that we can encounter is a sync fail so on the thing failed you there is a there is the synchronization Beaman which is responsible for communication between the two or the synchronization between the two FMC's in this process if there is any specific error we can look at action queue as well as the sync d-logs to understand why the synchronization might have failed so another error message that we can see is peer already exists which could be a result of earlier registration mall session of their devices in an FM CH a with a different with a different FN c or a break which was not successful before you know the attempt to re-register there some things and hatches established so during this error message where am you CPR already exists we can run a couple of scripts on the backend to understand to collect a you IDs from both the FMC's and and remove the tears from the corresponding databases where this information might be stored and then proceed to try the registration again so these are the these are the common issues that we would generally encounter while the HAF MCHA is an operation or while during the initial setup then moving on to the next major operation that can be performed during normal working scenarios let's say we have two SMC devices which are set up in Hetchy and there is a regular task with the scheduled backup the devices so while the SMC devices are a chip backup is being done it is normal to see the synchronization between the peers is paused this is to avoid confusions because when initiating a database backup and there's there are some data based tasks that are running in the background this is not really advisable so this is a mechanism by design so this should initially pause the synchronization and this would leave the leaves or hatches in a degraded State so during the time of the backup it is expected to see degraded hey chief states on both both the active understand by units and one store once the backup is done the hatches should resume back to its normal state one more thing to note is that during the time of this backup we can use the active SMC but Stan the agency would not be available to use during this time moving on to the next major challenge of the question that is in everybody's mind how do I upgrade devices which are in H a you know which are set up in Hetchy so let's talk about the process first so what happens is that the initiation of the upgrade on both the units is not automatic we have to manually put the upgrade files in and start the upgrade process so what we would advise to do is upload the files on both the units and you know pass the mirroring and understand by continue upgrading the SMC and this would leave the hijae in a degraded state as an active unit would still be the active unit where the but the status would be degraded and then the upgrade on the standby is completed so once we upgraded the Santa has been completely upgraded we would see that it comes back up as an active device as well so both units now are an active and a degraded state now this scenario that we are seeing where in both the SMC head units or an active it's it's called does a split brain this is the terminology that we use to describe the scenario and then on the active or the degraded SMC the primary unit I mean you can continue to upgrade initiate the upgrade process so that again would transition to a standby rule post the upgrade has been completed and the mirroring would be resumed so we can promote one of the one of these devices to active once the upgrade has successfully completed on both the both devices to continue you know a normal operation because until both the units show up as active active the head shave would still be in a degraded State so the heavy state was initially healthy during the time of the start of the upgrade would would resume to its healthy state only after both the units have been upgraded to the same version and have been promoted to the correct rules only then after a successful mirroring would we see the status being reflected as healthy so this these were the steps that we discussed so the upgrades are done in a serial manner so pause synchronization and then initiate upgrade on the on the on the secondary understand by you and once it is done and you should upgrade on the primary and promote one of these devices are active so this would be what we'll be using the other scenarios on which FMC might enter the split brain condition or become active active there are heavy breaks or when there is a power outage or some network connectivity issue between the two devices and this could result in the FMC is becoming active at though so we can resolve but resolving split-brain is very simple just need to promote one of these devices as active and this will be prompted by the system so so only what we need to ensure is that if one of those devices never come back up then there is a problem that needs to be investigated if if they are back again and both in active active it is very simple to promote one of them Istanbul so this would not make a major impact on the on the Hetchy and should be something that is easily fixable before we move on to the question and answer any questions that you might have let's take a look at let's take a look at the hea devices that we set up again and so briefly talking about the entire process i would let's run through a quick demonstration on how the hea would be set up and we would look for any issues so the on the UI itself healthy health alert but no with related any tasks to the health high availability successfully completed this is something that I would normally expect to see apart from that what we discussed was the deploy button will only be available on the on the primary and not on the secondary device and also another thing to remember is that while the before setting up the HEA ensure that the versions are are correct or match on both ends and that the hardware is safe the next thing we would do is to import or export use this option to import and export all configuration that you would like to be retained on the secondary FMC and once this is done ensure that all devices have been deleted deleted from the device manager one page so this is the import-export where and you can select the policies that you would like to be retained and exported out and the next step is obviously the registration make sure that there are no devices initially registered on the standby offenses so after this we would also move on to checking whether there are any licenses that might have been left over on the on the classic management a license page so the thing to remember is that when if you have some additional licenses on the system by FM C and F MCH a setup is done but there are the classic licenses that are used on the stand by something would never be used and you won't be able to see the me on the UI but you might have issues releasing the licenses for use on another device so it's always recommended to delete all licenses on the classic and the classic licenses that we have um that you have on the device however on smart licensing this process is automatic it releases any licenses that might have been added to the stand by FM C and these are available both reflecting on a smart account to be used for another for other purposes so this would still got the licensing after these checks or are done we can proceed to configure we can proceed to configuration of the hatchway which is under integration and we would we would follow the process of setting up the high availability like we discussed and once we have set up the set up the primary and the remote here if you would wait for the status and the synchronization to go back to healthy and this might take time it depends on the network bandwidth there is no date of timeline that can be defined here and once this is done we should be able to use any the head shape for normal purposes so events are shared all on real time between the from the devices to both SMC's in case you're not seeing a specific events coming in on the there are seems to be some missing events it might mostly be due to some specific issue with communication from their device to the FMC so that would be something that we would check the next thing to ensure that the persons there are two separate IP addresses on the management interfaces and sure that there is continuous connectivity to all external databases that the SMC might need to reach out to to ensure a healthy operation so these are the basic big checks and on how to set up the high availability and what is the health East status and what are the error messages that you could see or would observe during a time of a break-in this operation you okay so before we wind up I would like to run through the process of setting up the SMC Hetchy on one on the lab device so that we can watch the live logs [Music] you all right great so we've set up the hedge here now the reason for showing this is to look at what are the messages that have that occur on the background so you will see a lot of error messages with related to certain processes going down and certain processes coming up there just to make sure that the head shape is set up correctly and that we collect all logs that we might have during the week we can run the command pigtail deployed during the time of the registration and this would you know show up a lot of information on what exactly is the cause for why the HEA was not successfully set up so this is normal to see a lot of error messages or synchronization failures during the time of the FM Zha setup so it's it's advisable that that we wait until this is successfully eaten so this census process itself is going to take quite a lot of time we would not be waiting to see the complete results of this and I would do the session open for Q&A in case you have any further questions you can post some of the chat and then we'll be happy to answer the same so this is me so we'll be signing off today's FMC and actually HJ presentations and I'm really thankful for everybody patiently attended the entire session thank you you oh ok so we will have the WebEx open for another 5 minutes if we have any outstanding questions you can put it on to any and post that will have the session blue hood we'll share the presentation material in in another within the next 24 hours and once you log out of the WebEx session you would get a survey upon to wait the presentation so do rate and send your feedback so we leave it open for another 5 minutes and then we will close it up thanks for joining you

Channel: White Circle

Views: 4,307

Keywords: Cisco, FirePOWER, Troubleshooting, Best Practices, white circle, ftd, ngfw, tutorial, security, step by step, webEx, live, demo, dcloud, webinr, how to configure, how to, ftd demo, cisco security, firepower troubleshoot, high availability, threat defense, FTD HA, configure FTD, HA, FTD Licensing, license, troubleshooting, asa, cisco asa, failover, active, standby, stateful failover, firepower manager, failover link, primary, secondary, firewall, AVC, AMP, URL Filtering, FTD VS ASA, FMC, threat, defense

Id: VviRijsysCM

Length: 157min 35sec (9455 seconds)

Published: Tue Dec 12 2017