Fortigate IP Routing Features - What You Need To Know!

throughout this video we're going to be going back and forth between the lab and this topology but just to give you a rundown of the topology uh 4ate 1 is our main site it connects us to the internet via two separate isps iSpa and ispb and of course Downstream to forgate 1 we have two small branches connected by 4ate 2 and 4ate 3 according to this table that is on the diagram we're going to route from 4ate 1 to 4ate 2 4 Gate 1 to 4 Gate 3 we're going to have static routes defined so that we have endtoend reachability between 40 Gate 1 and the remote sites and then we're going to configure bgp and fate 1 is going to advertise 1.11.2 4ate 2 will then advertise 2.222 as well as 2.2.2 do4 into bgp whereas 4ate 3 will advertise 3. 3.3.2 into bgp forgate 1 will then also advertise 1.11.3 into OPF fate 2 will advertise 22.23 as well as 2. 2.2.4 and this is on purpose because I'd like us to observe and see what happens to this prefix when it's advertised by both bgp npf we'll take a closer look and see with this prefix 2.2.2 do4 how is it going to be entered into the routing table which protocol is going to be preferred so then let's jump on to 4 Gate 1 and start configuring our interfaces we're going to start first with Port one and two connecting to the internet and for that we go to network interfaces Port one connects us to iSpa so I'm just going to call this iSpa make that a when type interface and the IP address is 17216 10 and we are2 in a /27 network I'll allow ping on this network and I'm going to copy this because I'm going to need to use it a little bit later Port two connects us to ispb and I'll call this ispb and it's also a when type interface and the IP address there is going to be 1721 16202 that is Port two I'll enable ping on this interface and that looks good Port three connects us to 40 gate 2 so I'm just going to label this to 48 02 and the IP address for the segment is 101601 and 481 is1 /30 and for this interface and actually both Port three and four I'm going going to configure or I'm going to allow SSH and ping let's do the same thing on Port four I'll name this 240 Gate 3 our interfaces are configured now it's time for verifications this looks good so I suppose the next thing is to create our static routes and for that we navigate down to network static routes and right now we don't have any and if we go back to our dashboard and look at the network monitor we can see now that the number of connected networks has increased we now know of five networks which are all of them of the type connected because they directly connected they're directly configured on our firewall so let's create our first and second static routes the first static route is to iSpa Gateway would be 17216 16101 and it immediately picks up iSpa Port one interface and the second is to 17216 120. one which is associated automatically to ispb Port two I didn't change any parameters I didn't change any other values I just went with the defaults now if we have a look at our dashboard our Network monitor we can see now that we have connected routes as as well as static routes and connected routes there's five of them static routes there's two of them if we have a look at our static routes it's these two networks that we just configured we now need to test reachability to see are these interfaces actually up is there service on these two interfaces cuz we might need it later so to do that we need to do a ping and Source it from each one of the interfaces respectively exact ping options Source from 17216 do10 do2 and then we're going to Ping exact ping 8.8.8.8 and we have reachability via the 1721 1610 interface now I'm going to change that source to 20.2 and then p 88.8 again and through this interface we have reachability as well so it looks like our static routes work but let's have a look and see what our routing table looks like from CLI get router info routing table all we can see that we have these two routes with a legend of s that means that these are two static routes Okay so so now it's time to configure 40G 2 we're on 4G 2 and so far we only have one connected route we go to network interfaces we're going to configure Port one and since this is facing 4 Gate 1 I'm just going to call it to 40 gate 01 forgate 2 is dot2 on the segment and of course I'm going to do the same thing allow ping and SSH that looks okay let's have a look at the routing table from CLI get router info routing table all we only have two prefixes which are directly connected networks and we actually now can create a static route to do that we go on static routes we create new and gateway address 10.1 16.11 which is our next hop um 40 Gate 1 and we can see that there's our static route there okay so one of the things that I want to do is like we said from our table we said that we're going to Route these IP addresses in the static column on this table so we want to be able to reach from 4ate 1 we want to be able to reach 2.2.2 do1 which is an interface on forgate 2 we also want to be able to reach 3. 3.3.1 also an interface on 4ate 3 in addition to the configs that we have in place and the existing static routes on 4ate 1 we might as well create two additional static routes pointing to these networks before we go and configure 4K 2 and 3 themselves so the first static route would be to the loop back of 40 gate 2 which is 2.2.2 do1 the next one is to 40 Gate 3 and the network there that we want to reach is 3.3.3 do1 sl32 our next top is going to be 10.1 160. 0.2 which is IP address of Port one on 4ate 3 and yes it picks up the correct interface now we have all the static routes that we need as far as fate 1 is concerned we're on fate 2 let's configure Port one interface of 4ate 2 and this I'm just going to name 2481 and the IP address is 101601 where2 office /3 Network enable SSH and ping what I haven't done yet is to create the actual loop back interfaces themselves I'll come back to this a little bit later so for now we have our underlay interfaces let's go to 4ate 3 we go to interfaces and configure Port one I'm going to also label this to 4ate 01 allow SSH as well as ping I'm going to create a static route pointing to the loop back of 1.11.1 sl32 via the next top of 10.1 160.0 do1 being the port 4 interface on 4 Gate 1 it picks up the correct interface I believe I need to do the same thing static route on 40 gate 2 point to 1.11.1 sl32 our network is 10160 one and the next hop is Sport three interface address of one and it picks up the correct interface okay so what I meant earlier that um you know the reason I haven't created the loop back interfaces yet it's a manual process and it's a lot of work um not just to create the local um the Lo back interfaces but what I've decided to do is I want to be very granular in this lab I want to create all the interfaces on 4ate 1 meaning 1.11.1 1.2.13 I want to create all these interfaces as address objects and then group them and call them forgate one addresses and then do the same thing for 40G 2 addresses uh loop back addresses 2.2.2 do1 1.2.3 as well as uh 2.4 and then group those and call them 40 gate 2 addresses and then do the same thing for 40 Gate 3 so that when we start creating security policy we don't use the any any we actually reference the address objects that exist and so here's our list and as you can see it has loop back one address and the address groups at the bottom so what I'm going to do is just be able to copy paste the whole thing into into the F gate to create these objects and we'll start with forgate 1 and then move on to forgate 2 and then forgate 3 let's have a look at our policy and objects and see if our addresses are there and our addresses are there as well as the address groups this is on 4ate one forgate 2 we go and check on addresses and our addresses are there as well as the address groups and I believe the same for 4 Gate 3 I feel like there's something that I've forgotten to do but let's test before we can test we need to create the security policy to allow the um ping so what I want to do is allow ping and SSH so we need to create explicit policy for this let's start with 4 Gate 1 first and go to firewall policy I'll just call it allow ping and SSH oh um another thing that that I almost forgot so what's going to happen is we need to be able to specify the destination interface the source and destination interfaces and right now we can only specify one incoming interface or out outgoing interface and if if where the destination is uh loop back one loop back two loop back three multiple loop back interfaces we won't be able to do that so the other thing that we need to do is to allow um multiple interfaces in security policy so I'm quickly going to enable that feature in feature visibility and go to multiple interface policies go to 4ate 2 feature visibility multiple interface policies and do the same thing on 4ate 3 as well so now let's go back to forgate 1 and create our security policy allow being an SSH and incoming interface we want to allow incoming traffic from from both Port three and Port four an outgoing interface would be oh I don't have the loot back interfaces it looks like we haven't created the loack interfaces on 4ate 1 yet okay my script didn't include creating the actual interfaces um it looks like I only created the address objects but not the interfaces themselves which is not a problem we can now create the loopback interfaces for 40 Gate 1 okay now I'm back on 40 Gate 1 loop back one 2 three interfaces now created so as I realized they're not actually they were not part of my script 4ate 2 also has lopc one to 4 and 4ate 3 as well has LC one to three so now let's go back to our security policy and update the policy we have the intention of this policy is to allow ping and SSH inbound from 40 gate 2 and 40 Gate 3 so the in inbound interface incoming interfaces would be Port three and four and outgoing interface would be loop back one 2 and three now that looks better and the source is all addresses on forgate 2 as well as all addresses on 40 Gate 3 and the destination of courses any address in the 4ate 01 address group for icmp and SSH this looks okay to me and we can now save so now we're going to do the same thing on 4ate 2 create a similar type of policy policy new allow paying in SSH the incoming interface of course is going to be Port one and outgoing interface to the loop back interfaces would be the loopbacks themselves including Lo back 4 and the source would be all addresses on fot Gate 1 and the destination is all addresses on 482 and the service would be allm as well as SSH if we discover at a later stage that we want to do something else and permit some other service or some other application we can do that but for now this looks okay to me we do the same thing [Music] on 4 Gate 3 firewall policy create new allow ping and SSH and the incoming interface of course would be Port one outgoing interface it's our loot back interfaces and our source Fate One addresses destination fot gate three addresses we allow icmp as well as SSH okay so now our firewall policy is in place that means we are ready for testing okay so I'm going to do the this test from 4ate 1 and um I'm going to Source the traffic from 1.11.1 and I'm going to Ping 2.2.2 do1 and the traffic is permitted and I'm going to Ping to 3.3.3 do1 and the traffic is permitted and I guess just for for the sake of completeness let's see if traffic initiated from 4K 2 and 4K 3 would actually make it to uh the loop back interface of 40 Gate 1 exact ping 1.11.1 and this traffic is not permitted let's see why not do we have a static route first of all yes we do have this we we do have a static route wait a minute I'm actually going to do this test again just to pay a little bit more attention but while I'm doing that I'm going to do diagnose sniffer packet any exact ping 1.11.1 the traffic is making it to 4 Gate 1 I'm going to go back to 481 and look at the interface itself and see why are we not seeing a response resp so the problem is as it turns out um 4 Gate 1 doesn't have a route to 2.222 so I'm going to do this ping test from 2.2.2 do1 and check and that is permitted I'm going to create a static route to 2.222 I prefer that to be 2.2.2 do2 and this to be 3.33 it's just easier to work with Okay so let's do this test one more time ping options source 2.2.2 do2 1.1.1 and we have reability there I'm going to do the same test from 483 3.3.3 and ping 1.11.1 and the traffic is permitted as well so so far we've been able to prove that our static routes are in place we have security policy allowing this traffic and the next thing that I want us to do is bgp pairing between 40 Gate 1 and 40 gate 2 as well as 40 Gate 1 and 4 Gate 3 and then have a look at what the what what the routing table is going to look like after that since we are on 48 1 we'll be we'll start our configs on 40 Gate 1 just as a reminder we said that 4 Gate 1 and 4 gate 2 they going to have an ebgp neighbor ship meaning it's an external um bgp peering where 4ate 1 will be in the autonomous system number 100 with the router ID of 1.11.1 and the neighbor is going to be 4ate 2 with an IP address of 10.1 60.2 the remote As would be 200 for forgate 2 and so the next networks that we want to advertise into bgp we said that 4 Gate 1 according to our table 40 Gate 1 is going to advertise 1.11.2 sl32 we also have to advertise the directly attached networks on Port three and four since this is where we're going to be running bgp and that is 101601 and 10 101 160.0 and 101601 101 160.0 do0 as well as 101 16010 and 111.2 that's what we're advertising into bgp this looks okay to me I believe we can now go to 4K 2 and configure bgp and for that we go to network bgp once again 4G 2 is in autonomous system number 200 and we have the router ID of 2. 2.2.2 from forgate 2's perspective the neighbor is 4ate 1 with the IP address of 10. 160. 1.1 and the remote As of 100 and the networks that we're advertising let's actually start with our directly connected link 10.1 160. 1.0 sl30 we said that we're advertising our Loop 2 interface 2.2.2 do2 as well as 2.2.2 do4 this is 4K 2 by the way so this will be 2.222 sl32 and 2.2.2 4/32 and this same prefix 2.2.2 do4 we're going to also advertise into OPF and I believe this is okay this looks this looks okay to me let's go over to forgate 3 and do the same thing Network bgp 4ate 3 is going to have an ibgp pairing with 40 Gate 1 so the autonomous system number there is going to be 100 and the router ID for 4 Gate 3 would be 33.33 and we appearing only with 4ate 1 so the IP is 10.1 160.0 do1 with the remote As similar to ours 100 and once again we are advertising the network that's directly attached that's 0/32 as well well as the loop back interface that we what that we said that we're going to advertise according to the table which is 3.3.3 do2 33.33 d32 all right so I'm going to check the bgp pairing between 4 Gate 1 and downstream neighbors um from forgate 1 at this um it'll show me both of them at the same time at least I expect it would get router info bgp let's just say BG bgp summary okay we have bgp paing worth 101601 do2 that's 40 G2 we don't have our bgp pering with 101 160.0 do2 let's see where we went wrong oh we haven't defined 10 160 0.2 we need to add that so what we have is 1.2 we need 10.1 160 .0.2 and 0.2 is as 100 similar to 4801 okay let's try this again get router info bgp summary and now we have both neighbors and the bgp peering for both has come up we can see that we're learning pre es so from from 10 16.2 which is 40 Gate 3 we're learning only one prefix and from 4ate 2 which is 10 1612 we're learning two prefixes you'd remember that from forgate 2 we we said we advertised 2.222 as well as 2.2.2 do4 so this looks good if we go to the dashboard on 4 g 2 we can see now that the the routing dashboard looks like it has static routes bgp as well as directly connected rods if we go to 4G 3 I expect to pretty much see the same thing um the more interesting routing table of course would be 40 Gate 1 when we look on 40 Gate 1 we can see a lot more prefixes and we can see that this is um bgp static routes and of course directly connected and before we look further into the routing table and the um route monitor I think we need to add the last protocol which is OSF let's quickly configure OPF um so that we have our complete routing table so that when we focus on the routing table we have all our ducks in a row once again I'm going to start on 40 Gade 1 go to OSF I'm going to use the same router ID so 4ate 1 is going to be 1.11.1 I'm just going to use area zero not going to change anything there and the networks that um forgate 1 is advertising 1.11.3 sl32 and that's about it and the interface we want to participate in OPF would be Port three and four I'll just call this port Port three and then select Port three interface I'm not going to change any other values I'll add Port four which leads us to 40 Gate 3 and I'm not going to change any other parameters here so just to recap we have our router ID we have our area zero we have our physical interfaces as well as the networks that we want to advertise I believe this configuration is complete and now we'll quickly hop on to 4K 2 jump to networks go to OPF and do pretty much the same thing router ID for 4K 2 would be 2.222 once again area zero the networks that are going to be advertised by this device would be 22.23 as well as 2224 sl32 we're going to advertise as well 2.2.2 do4 sl32 and this is for gate 2 the active interface in OSF is Port one port one select that and I believe we're done I'll go into 4 Gate 3 go to to network ospf router ID for OS for 40 Gate 3 would be 3.3.3 do3 our areas is area zero so 4ate 3 is advertising 33.33 sl32 into OPF and of course the only interface that's active would be Port one that's our always PF interface and notice I'm going with defaults I'm not adver I'm not doing any other configurations that is for another lab some other time okay so now I expect that our our firewalls have fully converged let's go back again to 4ate 1 and look at the routing table from the OPF side of things get router info routing table OSF no router available get router info OSF OPF neighbor and it says I have no neighbors okay once again this another thing we need to do your OPF will not converge if you don't advertise the directly attached Network which is um exactly what I've done I didn't advertise the 10160 network and I need to do that that from 48 01 I'm going to advertise 10.1 160.0 sl32 as well as 10160 1.032 no sl30 so now I've advertised the two interfaces Port 3 and four 101 160.0 sl30 and 101601 sl30 10.0.0.0 sl30 okay so now I expect that we'll see something different when we look at the OPF neighbor ships and the routing table get router info OSF neighbor neighbor 3 is up let's see why neighbor two is not up yet get router info OPF neighbor um maybe it just took time um let's have a look again get router info OPF neighbor yeah so now we have both 40 gate 2 and 4 Gate 3 in the full SPF State let's look at the route monitor now we can see that we have in addition to our directly connected networks from 4ate 1 perspective this is the networks how many prefixes we're learning from each routing protocol so if we go on onto OSF we'll see that it looks like we are only learning from OPF 2.2.2 2.3 which is a prefix coming from 4 gate 2 I don't know why we're not learning 3.3.3 do3 um let's have a look let's do a r look up and then see where 3.3.3 do3 takes us oh 33.33 is learned via static I remember I changed that out of convenience but we should actually be advertising 3.3.3 via OPF so then instead of um 3.3.3 do3 via OPF what I'll do is create create or advertise 3331 via OPF from 4ate 3 let's have a look at that yeah so this would never work because um a static has a higher administrative distance but this is exactly what we're going to be talking about now so I'll change this to 3.3.3 do1 so that we have one static prefix being advertised and um or not really advertised one statically routed prefix and one dynamically routed prefix um per protocol so now when we look back at OPF maybe I just need to refresh this our routing table has converged and the 3. 3.3.1 prefix has come across as an OPF Network and we can see it on the route monitor now let's let's actually pay a little bit more attention on on the on the routing table V the route monitor we know that we're not even going to pay attention to our directly connected prefixes I think the thing to have a look at first is the routing decisions and how to interpret the routing table as we can see that all the directly connected networks have an administrative distance of zero and I went with the defaults I didn't change anything with my configs this is directly connected and then when it comes to the static routes we saw that we didn't change any Matrix we didn't change any other config and so by default all the static routes have an administrative distance of 10 so this means that in terms of preference the 4ate would choose the routes that cost less meaning that have the the lower value with regards to the administrative distance and in this case it's directly connected if the forgate has a path via directed uh directly connected interface it'll choose that path if it doesn't and there's a static route it'll choose that that that prefix via that path via that static route so the static route would come after the directly connected interfaces and after that we would learn from bgp and bgp has an administrative distance of 20 and you'll notice that this bgp um metric um this network comes from 4 gate 2 remember we said that 4ate 2 has an ebgp neighborship with 4 Gate 1 that means ebgp has an administrative distance of 20 after the static routes the the 4ate would prefer any route learned via bgp specifically ebgp and the next preference of course would be OPF because OPF has a higher a significantly higher administrative distance of 110 so between the two prefixes if the same network is being advertised by OPF n bgp like we did in our table where we advertised 2.2.2 do4 for in in both bgp and OPF we saw that the prefix came across as a bgp prefix and there it is 2 2.2.4 it's registered in the in the routing table as a bgp prefix instead of an OPF prefix because when OPF presents it it presents it with an administrative distance with an administrative distance of 110 and of course the lower is better 22.23 is an OPF prefix coming from 40 3 and last but not least is the ibgp which is the interior bgp that has an administrative distance of 200 so all the theory about route lookup route calculation path selection pretty much boils down to administrative distance and the defaults are good enough you are not meant to change the defaults even with static routes so with our static routes an interesting thing we have here is that we have two IC routes with the same administrative distance to the same network now how does the Fate choose which prefix is going to take precedence or you as a network engineer how do you decide let's say in this case you want for iSpa to be your primary link how can you ensure that all your traffic is going to be going via iSpa the best thing to do is not to change the administrative distance I don't like to change the administrative distance and Fiddle with those values instead if I know that iSpa is going to be my preferred path the thing to do the recommended best practice is to change the priority so of course lower is better and I'm going to change this to 10 this is iSpa and then make ispb to be priority 20 so now if we look at this from the routing table get router info routing table static we can already see that we have 10 for administrative distance and for priority the first prefix via 1721 16101 next hop has a lower priority and when we do let's say we want to go to 8.8.8.8 and we want to know which way we're going to go let's use the the guey for this we go to the route Monitor and then we use the route lookup utility so let's say we want we want to go to 8.8.8.8 as you can see the 40 gate will highlight the path that the traffic is going to exit out of and in this case it's going to exit out of um Port one and we can very easily change this around and lower the priority and make it five for ispb and when we do the route lookup again we want to check what is the path which which interface is going to be our ESS interface which path the forgate is going to prefer 8.8.8.8 and this time you can see it's going out 17216 20.1 so this is effective and because of this value because of the priority there's no need to modify the admin administrative distance and I hope this is very clear the other thing that I wanted to um put across is that the RB table the router information base it's considered to be the standard routing table and I've been doing this throughout the lab but the way you display the rib table is through get router info routing table all this is a standard routing table and this is made up of all the best paths to each of these networks that are listed on the writing table here so the the firewall will select the best path and install it in the routing table and that is considered to be the router information base now you might be asking what what then is the difference between the router information base the rib and the Fib the FIB is everything that comes out of the rib and filtered through some system specific parameters to make up an index of routes that is used by the firewall to forward traffic it looks very different from the standard routing table even though it contains information that was extracted out of the routing table out of the rib and the way you display the the FIB on the fot gate is get router info kernel and I think the screen is a little bit I'm going to SSH to the to the firewall um so we can see this properly so that is get router info kernel like I said it's the same information but it is enriched it has far more columns and far more detail the phate actually uses the FIB for forwarding decisions so when they refer to the route lookup it's in fact the the FIB lookup and so that was the rib and the fibb um the other table that I want to show you is the session table and how the session table gets populated once again we'll log on to the to the firewall the way to display the active sessions on the on the foot gate is diagnose system session list and here you can see all the sessions that are currently active and if you know what you're looking for you'll be able to use filters and find what you're looking for so as an example I'm going to start an SSH session [Music] from from 4ate 2 to 40 Gate 1 and then so that we can search using um say Port 22 as a destination port to identify that active session on for Gate 1 so I'm going to SSH from 4ate 2 to 4 Gate 1 to create the session exact SSH admin at 10.1 160. 1.1 okay now we're sshed we are connected onto 40 Gate 1 now let's see there must be a session on the 40 gate on 4ate 1 and let's now try to find that session and the way to do that we are back onto 4 one we go diagnose system session filter we want to filter with any one of these parameters but the easiest for us to filter with would be the destination Port so I'll just say filter with destination Port of 22 which is the default SSH port and then diagnosis session list and we can see protocol 6 which is our our TCP protocol and we can see that we have this line over here that says this traffic is originated from 10.1 16012 which we know to be an IP address of 482 coming off this ephemeral Port going to 10.1 16011 which is as we know Port 3 interface of 4 Gate 1 on Port 22 and then we see traffic in Reverse from 101 16012 from Port 22 back to that ephemeral port and furthermore we know that this traffic was allowed by a policy and the policy that was responsible for allowing this traffic is this policy ID over here which doesn't make too much sense to me typically you'd see um singled digigit numbers but this doesn't make sense to me but yes this is the policy ID that is um allowing the traffic show firewall policy I'm curious to see what I'm going to find when I type when I copy paste this value yeah that policy doesn't exist there's only one policy and I would have expected for this to say policy number one because there's only one policy on the firewor at the moment so that was the FIB table the rib table as well as the session table and the last thing that I want to demonstrate in this video is the reverse path forwarding with reverse path forwarding let's say for instance you're connecting from 4ate 2's loot back interface with IP address 33.33 and you're connecting to 40 Gate 1 in fact this did happen to us earlier I didn't have a static route pointing back to 4 Gate 1 1 we didn't have static route 3. 3.3.1 pointing to 4G 2 and when I tried to connect to 40G 1 that traffic just died it didn't get anyway in fact I want to do this again but the theory is if you're coming from 4ate 2 connecting to 4ate 1 from an address that forgate 1 doesn't have a path to doesn't know it's not advertised by any Dynamic writing protocol and there's no static route for it if it doesn't have a path back to the source if we're coming from 3331 but 4ate 1 doesn't know how to get to 3. 3.3.1 that traffic will be dropped by RPF reverse path forwarding so let let me demonstrate that I want to remove that that prefix from from Dynamic writing protocol so that 4ate 1 doesn't know of that prefix anymore so from 40 gate 2 we want to use let's say 22.23 I'll delete that and then now let let's check if 4ate 1 knows of 2. 2.2.3 get router info routing table all grab 2222 exact being 2.2.2 do1 okay so it looks like we don't know of 2.2.2 do1 so I'm going to run a diagnosed debug flow on 4 Gate 1 diagnose debug flow filter let's filter by an address 2.2.2 do1 diagnose debug flow Trace start I'll say 20 diagnose debug enable and then I'm going to Source traffic from 2.2.2 do1 I'm just the Ping 2 2.2.1 exec being 1.11.1 which is an IP address on the 40 gate on 4 gate one and immediately we can see that we know we don't have a path to 2.2.2 do1 and as you can see reverse path check fail and the the traffic is dropped there's not much I want to say about this anymore and um so far we have covered um quite a lot of things and so let's recap we we we looked at the rout lookup process we looked at the eal cost multipath we also look at the router information base and the difference between that and the forwarding information base we know that the the FIB is made up of entries that come out of the rib and we looked at the session table and and how the session table is populated and um what you need to know about the session table is that the 40 gate looks at the first packet that the sender um sends that goes over the 40 gate and also it looks at the traffic coming from the receiver but only once so it essentially does two lookups and and that's it and that's how it builds the session Table after those two entries are known from the sender and the the the recipient uh return traffic the route lookup doesn't happen again so the session table is built and all the subsequent flows would be associated with that session and then we had a look at the reverse path forwarding and how it works we looked at the path selection from the 4 gate and um in view of the different routing protocols bgp ibgp ebgp OPF and static routes and this concludes it for this video it's been quite a mouthful but I'd like to thank you for watching until the end and um thank you for supporting the channel I'll catch you in the next video

Channel: Static Route

Views: 2,580

Keywords: Fortigate firewall setup tutorial, Basic routing configuration Fortigate, Fortigate firewall routing explained, Routing policies on Fortigate firewall, Fortigate firewall gateway routing, Network routing with Fortigate firewall, Fortigate firewall static routing setup, Understanding routing tables in Fortigate firewall, Fortigate firewall routing best practices, Configuring OSPF on Fortigate firewall, bgp attributes and path selection, fortinet firewall videos, fortigate

Id: jiCOWHA-gWw

Length: 52min 15sec (3135 seconds)

Published: Fri Mar 15 2024