1. DHCP Services
In this lecture, we will see how to setup the Palo Alto firewall to provide DHCP services to the Trust segment depicted in this diagram here. So I have the firewall, and I have the Trust interface, which is Ethernet on. And I am going to configure this for 10:00 and provide TSCP services to the workstation and the server behind it. We will see how to set this up in the lab. So, first and foremost, I’m going to set up the firewall here via Ethernet. One of them is going to be my trust interface. I’m going to select the virtual router with a Layer 3 interface. I’m going to choose the default virtual router security zone. I’m going to create a security zone called Trust and click okay. Then comes the IP address.
I’m going to provide the IP address (10.124.124) and then click okay. And then basically, this interface is set up for the trust zone. And now the next thing we need to do is provide DSCP services. Click on the DSP tab, click Add, and then we’re going to provide the interface information. Ethernet The first is the IP pool. I’m going to create an IP pool here, ten (1010) through ten (1010), and you can specify to ping an IP when allocating a new IP just to make sure it’s not in use. And then the lease is not unlimited. The lease will expire in one or two days, depending on your requirements. And then under options, you need to specify the gateway, which in this case is the firewall ten, the subnet mask 02550, and the primary DNS. In my case, I’m going to choose ten, 10, 100. This is my server on the inside. This is the primary DNS server. So in this case, the server is 10, 10, 100. The workstation is going to get an IP address from DHCP, and the DNS services are going to be provided by the server. and we’re going to enable this. You can set up additional options. primary wins, secondary wins, secondary NTP, and so on. Click okay. And then we basically got to the Ethernet interface here.
Make sure we bring this up by specifying that it’s up. Okay. And then we’re going to commit. This is my lab workstation here. It’s currently on the network without any IP address, and it’s sitting on the same virtual switch as the inside interface of the firewall. As a result, it currently lacks an IP address. Once the firewall pushes the configuration, we should get an IP address here that is 10 or higher. Right? Completed successfully. Ethernet one is now operational. We’ll open the interface by clicking on it. You’re going to click on status details to figure out if we have the IP address. Not yet. Let me disable it and enable it again. The network label is Lab Trust, and the firewall lab DC is Lab. Pan One. This is the firewall. Ethernet One is going to be in the lab. It’s incorrectly specified here. So lab confidence So I’ll set that up in Lab Trust. And the first interface is the management interface. The second interface is Internet one, one, two, and so on. So it should now get an IP address and select status details. And we see here that 10 is the IP address provided by the Palo Alto firewall to the client. Just to recap here, you need to go under SAP and set up the SAP server services and provide an IP address range, provide the network information, provide the IP address range, provide the options that specify what the gateway is, subnet mask the primary DNS, and so on. And that’s how you would be able to provide this information to the clients and have firewall access because of the VCP server.
2. Default Route
In this lecture, we will see how to create a default route on the Palo Alto firewall. And this is the foundation for static routing. So we can have more discussion about static routing in a later section. But for now, we have this Ethernet 1 3 that connects to the Internet, and the zone is called Untrustone, as well as IP addresses. The router, which connects to the Internet, is then in front of you. So the first step is creating the interface. So Ethernets one, three, and four will be our untrustworthy networks. I’m going to call it Untrust One. So go on, interfaces. Ethernet 1, 3, Click on that. It’s going to be layer three: virtual router, default security zone, creating a new security zone called Untrustone, IP address one, accurate, and bringing the interface up. And then we go to the virtual router and click on default, and then under static routes we’re going to click add, and then we call this default zero. This tells the router that you don’t have any specific routes to send it out. Ethernet, and the next hop would be an IP address, and the IP address is the IP address on the router, and then click okay.
And then click okay. So in order for us to test this out, we need to have a policy in place. So I’m creating a simple policy. Click add. I’m going to allow pretty much anything, and any do, any commit, click that. I’m going to go back to the firewall console, and I will log in to the console, and I’m going to ping eight dot eight dot four dot four. Well, in order for me to specify the interface, I’m going to ping source, sourcing it from one one, which is the untrusted interface, and then host eight four four. This should ping out to the internet, and you should double-check that you’re on the correct interface. Then this is 11121, and that’s going to be on Lab, on Trust 1. and let’s try the thing again. There you go. The default route is a fundamental, basic static route, or the most basic routing that the full auto firewall can support. If you don’t have any route for that specific destination, then basically use the default route. The default route itself is just zero. Interface will be released in the next pop.
3. OSPF Routing
In this lecture, we will see how to configure OSPF on the Palo Alto firewall. We created another firewall here, and we have two interfaces: the trust interface that connects to the existing firewall, and then trust two, which connects to another segment here. And we want to enable OSPF between those two firewalls to see how OSBF gets configured. So I’m going to go ahead and configure this firewall here, the trust interface, which is going to be Ethernet one one. It’s going to be ten 10253, and then I’m going to configure trust two, which is going to be ten 20 one.
And we will have a router here, and we will test connectivity using OSPF. This is the new firewall; Ethernet One is going to be Layer 3, and it’s going to be in the virtual auto-default security zone. I’m going to set this up as trusted, and then the IP address will be 10-253, and Ethernet 1 2 will be Trust 2. Trust two’s IP address is ten 20 124.On the virtual router, we’re going to go to virtualrouter here, click default, and then go to OSPF. And then we’re going to enable OSPF. We’re going to give it the router ID of 10, 10253, and we’re going to uncheck reject the default route to accept the default route. So the next thing we need to do is add an area. So we’re going to call this area Zero. It’s in decimal format. The type of area is normal, stubborn, or NSSA. We’re going to choose normal, and then the interface that is under that area will be interface. Ethernet one will enable this, and you can specify the link type as broadcast point-to-point or point-to multi point.We specify broadcast, and then we’re going to specify an Ethernet one too, so that the other firewall will know that this segment exists, and then click okay.
So you can specify under ethernet one or two that it’s passive, or you can specify passive, meaning it’s not going to be receiving adjacency on that interface setup for OSPF. Click OK, and then we’re going to create a policy to allow everything across any destination, any action allow, and then we’re going to commit. And then on the original firewall, we’re going to go to the same place, we’re going to specify the shoes USBF and then enable, and we’re going to give it the router ID 1021, which is the interface on the inside area. ID normal area range is going to be interface ethernet one one two, which is the inside interface, and ethernet one two because we’re going to advertise the DMZ, but since there are no routers in the DMZ, we’re going to specify this as passive. Ethernet one two is going to be passive. Ethernet one one is going to be not-passive because the Internet one one is going to establish a neighbour relationship with this firewall, and then in the advertisements that we are going to run, we need to advertise the default route. We’ll allow redistribution of the default route under export rules. So this way, the other firewall would know that to reach the internet, it needs to connect to the other firewall. And then we click Okay. And then we’ll commit here, and this was committed. So we’ll open up the second firewall and see if we have an OSPF neighbour relationship. We can see the virtual router, the routing protocol, and the OSPF neighbor. Ten ten one is the default neighbor. It sees the other neighbor.
And if we do show the routing route, totalroute shown, we see the route for the DMZ, but we don’t see the default route. Well, we don’t see the default route here. So there’s a step missing here. Even though we checked here to see if export rules would allow redistribution of the default route, we still need to redistribute the default route. So we go under redistribution profile and then click add, and then we specify redistribute default redistribute general filter. We can filter static destinations to be zero and priority one, and then click OK. So we specify the name of the filter default redistribute here, and then we cannibalise as external type one or external type two. It doesn’t matter. External type 2 would be fine. And then click okay. And now we see the default route redistributed. So we basically had to go in under route redistribution and create a redistribution profile for the static route default, and then go to export rules and add that distribution profile for it to redistribute the default route into SPF.
And now we are able to get the default route for that downstream router on the land router. I have an IP address on that interface behind trust two. The answer is ten 20254. I am going to put this in its own VRF. So just to prove that we can get to the default route to the internet, I’m going to create a default route on that DRF and tell it, “Hey, your default route is the firewall interface; this interface can also get to the internet.” So just to recap here, if I go to the virtual router, which is also something I want to show you guys, let’s go here and then click on more runtime statistics under SPF. I can see who my neighbours are, and I can see the summary of the OSPF configuration under routing. I can see which routes are received by OSPF. Route 101 is shown below. 200:24 is advertised to OSPF. The other firewall advertises ten and twenty. We believe it is within ten years. Page 10253 is up next. The redistribution profile is used for you to redistribute if the default route has to have a redistribution profile.
4. BGP Routing
In this lecture, we will see how to configure PGP to receive routes from the service provider. Currently, the firewall is statically confirmed with the default route pointing to the ISP. So we are going to change that so that the firewall is considered BGP and there is a neighbor relationship with the ISP router. And then that’s how our firewall would receive BGP advertisements, which include the default route. So in our firewall here, we’re going to click on the default, and then we’re going to go to BGP, and then we’re going to enable BGP.
We’re going to give it that router ID one, and then the Es number is 65,002. Then we can uncheck reject default route and select install route, which will install routes under the peer group. We can add a peer group, and then the type of peering is EBGP because it’s in a different PGP area. We are establishing neighbor with the peer you’re going to specify as peer router. Give it a name. The number of peer autonomous systems is 65,001. Ethernet is the interface we’re going to peer with. The IP address on that interface is one one. Peer address is one, one, two. And you can add an authentication profile if you have authentication with the peer and the service provider. But in our case, it’s not. So now it should be configured with a peering relationship with the service provider. Since we are going to rely on receiving the default route from the service provider, we’re going to remove that existing default route. We have here, statically specified and under the redistribution profile, When we created the distribution profile to redistribute the default route, it was static. So now we’re going to change it to BGP, the source of the route, and everything is ready. 65,002 is the autonomous system number, routerID, and ISP is the ISP IP address. And we’re going to go ahead and click okay and then commit. It’s complaining that the VGP router ID is different from the OSPF router ID, which is fine because those serve different purposes. So it’s just a warning.
We’ll click okay and then on the more run timestamp to see what comes up. Here we see the default route information received from the BGP neighbor. If I click on the PGP tab, I am seeing a peer ISPA router, and the peer status is established. The duration is 26. The default route is based on the local route information received from this pier. IGP is the next hop after origin. So I also redistributed this route into SPF. So that route should be visible in the internal firewall. I should be able to see this route in OSPF. So I’m going to go here, under “Network Virtual Router,” for more runtime statistics. And here I see the default route exists, pointing to the inside interface of the perimeter firewall. The Internet is using this default route to prove it out. I’ll go to the internal router and ping from prfrust two eight. And this proves to us that we are able to access the Internet.
5. BGP Advertise
So we had the service provider point “five dots,” “five dots,” “five dots,” “zero slashes,” and “24” to our Ethernet-1-3 interface previously. The untrustworthy interface The hypothetical company for which we are establishing this network essentially wants to use the 50 across multiple ISPs, and I want to be able to advertise selectively from different ISPs.
So the service provider went ahead and removed the 550 from the routing table, and we are going to be redistributing and advertising those routes to the ISP. In order for us to do that, the route doesn’t necessarily have to exist. Simply create the redistribution profile under BGP, click add, and enter the IP address 24. When you check enable, it’s going to basically advertise this route even though it’s not in the routing table. You can set the origin as IGP, EGP, or incomplete. You can set the local preference. So, if I click okay here before showing you the internet router, I won’t have a route for five and fifty. My firewall will begin advertising 5/50 once I click OK and commit. There you go. See the $50.0 IP advertisement. Next up is one dot one dot one. And now the service provider knows to get to five-five, 500:24, and send it to the interface at one. And this basically applies to advertising your route across the internet. So to prove that it’s working, we’re going to go to the internet workstation here, and then we’re going to try to access 5510. The BGP advertisement works, and the service wire knows how to get to your advertisement.
6. Using Multiple Virtual Routers
Another topic we need to be aware of is the virtual router. So by default, the default virtual router is used for most of your interfaces. The virtual router in and of itself isolates the routing table and the interfaces that are configured as part of this virtual router. You are virtualizing multiple virtual routers inside your Planter firewall. We have a scenario here where this hypothetical company wants to get a guest network, and this guest network should only have access to the internet and nothing else. So, to ensure isolation, we’ll configure the guest network to use its own virtual router. We call it “Virtual Router Guest” and prevent it from reaching any of the ten networks or any of the RC 1918 networks by using discard routes, which will get you familiar with discard routes. So the first thing we need to do is create the virtual router. Here I’m going to add “guest.” Okay. Then I’ll make this new interface for the guest network layer three, and there’ll be a short router.
We’re going to select the guest security zone. I’m going to create a new security zone called “Guest.” IPV-4 is going to be 192.168.1.1, and now this network is in the virtual router, Guest. I’ll return to the virtual router if I click OK; it’s now in the Guest virtual router. Now I’ll go to the Guest virtual router and configure discard static routes for any RFC 1918 addresses. So 1024 at eight covers all of the ten networks, and I’m going to click Discard. So this is going to be a Discard network. This means that if the virtual order out or guest receives any address with this IP address as a destination, it will discard the packet (172:16:00:12) as well as 192:168:16: this card. So the connected routes take precedence over anything else. This is the order of the administrative distance for different routes. Static is ten, static IPV six is ten, OSPF internal is 30, external is 110, and so on, similar to the Cisco outer. Now I want to tell this guest VRF to use the default virtual router so you can connect to the internet.
The next virtual router is going to be the default virtual router, and if you have any packet other than the ones listed here in the routing table, send it to the default virtual router default. Okay, click okay. And now, on the virtual router default, I need to tell it that hey, this 192.168.1.4 is reachable via the VRF, next VR guest. So this way, it knows that in order for it to get to this IP address, it needs to send the packet to the VRF, or virtual router guest. We need a policy for this traffic in order for the virtual router Guest to connect to the internet. So we’re going to add an app policy that will say “guest network original packet is from guest destination” and “untrustworthy destination interface Ethernet translated packet.” We’ll translate it to an address here of Guest Net for three so that those guest users can connect to the Internet. However, they won’t be able to access any TEN network, any 192 168 network, or any 170 216 RFC 1918 network. That’s a guarantee that they cannot reach anything outside of what we have for public network routing. This is in place. We’re going to go ahead and commit. Let me specify toping the interface in the first management profile that allows this interface. This way, the guest user can ping the management interface. I’m going to also check the response pages in HTTPS because I’m going to show you later how to authenticate those users. Click okay. Click okay.
And we also need to enable the interface. The up-and-commit interface is up. I have the router configured with an interface on this network. I should also be able to ping the Internet. I can ping the Internet. We’ll go ahead and look at the session here. Quickly take one more session out. Let me see the pink session here. Display session IDs seven, four, and three; everything is permitted. It’s using the network that we created, called the guest network. However, if I tried to ping any internal IP address ten, 10-1 from this router, it would be denied. So, even though it is allowed on the session, it is denied because it violates the card route card rule. It’s.
7. Multiple Virtual Routers NAT and Security Policy Example
The actual destin5n is f5dot, f5dot, five dot1032 Remember that the destination is basically the original packet destination not after the net before the net service is TCP 22, and then action allow and put this aboveallow everything, and then we can add another rule hereto block their access to the DMZ and trust. This way, it’s just specifically for the services accessed by the public. Guest block internal, with guest destination as the source. Either the DMZ or the trust’s inaction is going to be denied.
Put this above and allow everything. So now we specifically have a rule for the guest to access DMZ on public server 5510 and then access the trust on TCP 22 for the SSH order, and then go ahead and commit. And now we’re going to test the rule one more time and see which rule is hitting. The rule is being enforced. So I’m going to try the SSH one more time, and now I’m going to do “show sessions.” All I see in the new session here is 320. So, by displaying session ID 320, we can see that this is a trustworthy guest. It’s hitting the correct security policy, and then if we do ping ping VR f guest five, dotten, show session all ping session 330, we see that it’s a guest to the web server. Guest access to the web server DMZ is the guest.
Guest to DMZ is the security rule. The Nat rule is guest access to the web server. This example shows us how to use a virtual router to separate the routing between the internal network and other networks that you want to have isolated. But at the same time, we are able to use the Nets to specifically target traffic that is allowed access, like we did here. As long as you understand the destination, that concept, and the turn, you should be able to manoeuvre any of those scenarios.
8. Multiple ISP Failover Scenario using BGP
In this lecture, we will expand on the BGP configuration. We had a few lectures a while back to show you how to advertise and do path-dependent things. We have multiple service providers that prefer one over the other and influence the return traffic of one over the other. Going back to the diagram, we are adding another ISP service provider here in Ethernet Group 5. The IP address is 22.1, and we’re going to advertise the five-fifty to both ISPs and receive the default route from both ISPs. However, we will configure our firewall to prefer this ISP versus the other ISP for the default route to be used, and we will also advertise five hundred with no spat prep to this ISP and then advertise it to this ISP with spat prep pen. So let’s see how to do that.
So the first step is to connect to the Internet via a network of five service providers. We’re going to change this to layer three. We’re going to put this in the virtual default router and use the same untrusted security zone. Enter IPV 4 slash 30 and press OK. So now we have this other service provider, and we can specify allow things here as well. The service provider’s autonomous system number is 65 ten. So let’s first bring this interface up, and then we’ll go to the virtual router default under BGP. We’ll add another peer, the ISP2 type EBGP next top export next top use self, which basically tells the service provider that your next top is me for anything I’m advertising to you. We will add the IP address of the pier here.
The peer autonomous system number is 65-10, the peer IP addresses, and that will basically set up the connection. We’ll click. Okay. Here. So now we have two ISPs. We want to prefer one over the other. So we want to configure it in a way to prefer an ISP one. The first ISP over ISP two. We can use ISP 2 as a backup. So we’re going to create import rules. Let me redo this. We will basically specify to import “default,” add the prefix “zero,” and then “general.” We are going to specify that this is for ISP, the first connection, and we are going to specify that the action is “local preference.” You can use the local preference or the weight.
The weight is locally significant for the BGP device itself. We can use that or local preference, whichever we prefer. We’re going to choose a weight of 120 to make this more preferred. The route received from this ISP is more preferred than the route received from the other ISP. So here we’re specifying to receive the match by default, and then the action is that we are going to set the weight to 120. As a result, this is for the import. We’ll specify the export-import network, which will be five and fifty. We are going to export via ISP. On the second connection, we are going to export it with a S path prep, so we’re going to match the five dots to the five dots here and then action as path prepend two times. So we get a S path prepended to our autonomous system twice to make the route less attractive for traffic to come in on ISP 2. So we are preferring ISP 1 over ISP 2. By using the export and doing SPAT repent for ISP-2 connections, the import, we’re going to give it a higher weight for the default route. This way, the outbound traffic will use this route, and then the inbound traffic will use the first ISP under the redistribution rule. That is already in place to reduce five to 500:24. But now we are ready. We click okay. I had to reboot the firewall for the interface to be active. So let’s look at that and wait for it to activate. Let’s check to see if the interface is visible on the network interfaces. Let me see if I can bring it here from the ISP router that I have in the lab here.
Can ping it. Take a look at the BGP configuration one more time, peers; my configuration is lost. Let’s do this again. The peer ISP will be added, and the peril will be 65.10 interface IP address, where local Istwo one two is the ISP IP address. Click okay. Then we import, matching any ISP with your preferred local IP address of 120. weight of 120 ISP two. Then you can export five. Path determines the action, and you click OK. Repeat the process here; import and export will also be ISPs. So then we’re going to click okay. Commit, commit. Now we have the neighbour relationship showing up, and let’s take a look at the statistics here. So the BGP peer and then the local rib So we have two routes here. The default route received from ISP One was preferred because the weight is 120. So we see the flag here; that’s the preferred is received from ISP 2, and it is not preferred. So the traffic will go outbound over ISP 1. We see here that it’s getting received from two neighbors, and this is basically preferring the route from the next neighbor, which is exactly what we are intending to do.
I will go ahead and ping the IP address, and we’ll look at the file and see where it’s coming from. 192-6014 six, so we see here it’s coming in from Ethernet. It’s coming in from Ethernet 1, 3, and exiting Ethernet 1, 2, which is basically the intention. And if I try to connect to the internet, you can see from one of the machines here that workstation tried to connect to the internet or ping something on the internet, it’s coming from Ethernet and exiting out Ethernet. So we are preferring the routes going over the first ISP. However, if I shut down the first ISP connection, I’m going to simulate this by shutting down the connection to the first ISP shot. We will see here, and we’ll go back to the runtime stat here: BGP local rib. It’s going to take a minute for it to time out. It takes up to three minutes to time out. Okay, so we see now that the only route left is through the second ISP. So, if I try to connect to the internet from the workstation again, it should be crossing into the second ISB via Ethernet 5 from the first. It’s coming in on the correct interface, or I’m missing something here to get it to work correctly.
Okay, see if we can exit out the other interface, and if we try to ping the five dot ten, we should be able to ping 5510. You can see it approaching. Okay, so the reason why it’s not coming in is because the net that we created is tied into an interface. Because the network is connected to the interface Ethernet 1, it will not add it across Ethernet 5. So what we need to do is go back to the network that we had created and then remove the interface. So we’re going to go ahead and remove the interface. And now that we’ve specifically removed “Ethernet 1,” and this should apply to pretty much all of the nets that we created, we need to remove them all. If you have multiple interfaces, you need to remove the destination interface specifics; otherwise, it’s not going to work any.And then there’s any. Okay, let’s test out some of the nets that we have in place, from the trusted to the untrusted return net. We’re going to try that out. So on the workstation, we’re going to try to access it to prove that it’s working, and it works. And then we get an SSH from the outside (25, 510), and it works. Pretty much everything we had working is working now with dual ISPs and failover from one ISP to the other ISP, both outbound and inbound.
9. Multiple ISP Failover using floating Static Route
So in the last lecture, we saw how to use BGP for failover. There is basically seamless failover between two ISPs for both inbound and outbound traffic. I’m going to expand on that scenario to show you something relating to administrative distance. EBGP is 20 when administrative distance is set. When we receive the default route from the service provider, the administrative distance of this service provider route is 20 because it’s coming from EBGP. So we’re going to expand on the scenario that we had previously. We discussed having two ISPs fill in using BGP. We are going to failover using administrative distance. In this case, the ISP is two.
We are not going to establish a BGP neighbour relationship with them. It’s going to be just the first ISP, and then we’re going to specify the default route that gets received by BGP. is from the service provider. For the first service provider, we’re going to use the second service provider for the first service provider.But we’re going to be using the default route with an administrative distance greater than EBGP, which is 20. So I’m going to call this backup ISP zero, and then it’s going to be exiting over Ethernet. and the default route would be two. Two administrative distances would have to be something higher than 20.
We will make it 30. So, even though we receive the static route from the service provider, we will use this floating when the static crowd disappears. We call it “floating” because it has a higher admissive distance than the actual route we received from our ISP one.The actual floating static route will take over. So I have to clean up the configuration here and then commit. I’m going to bring up that connection one more time on this router. So right now, because I didn’t move BGP, I won’t be able to access anything. If I try to go to Thinka Order 4, I’m not unable to because I shut down the first ISP, and that should have worked because the default route is now using the second IC. So let’s take a look at the virtual router, and then we will look at more time stats. And it’s done. So my route is through two universities. I should be getting policy netted on the outside, behind the interface. So one thing stopping me from doing this right now is that I’m using the dynamic IP import and outbound pool, which is set to five five. And that’s not advertised through anything, right? So the traffic goes out, but there’s no way to return back.
So to fix that, I’m going to change the outside network to be using interface addresses, and it’s going to be interface Ethernet. I’ll put this up top. Two, one. Okay, so I’m going to hide behind the outside interface of my firewall. Let me revert that to its previous state, and I’m going to add a rule above it that says if you exit the Ethernet dynamic network to the interface IP address, so I’m going to add a rule. I need to raise it above the existing rule for outbound backup ISP original, trusted packet. Destination is a dubious interface. We’re going to translate it behind the interface IP address. We need to put this above this one; otherwise, it’s not going to work. So basically, I’m hiding the traffic behind the ISP’s IP address. I’m not using the number five. In this scenario, we just want to prove the administrative distance. Floating-static route Using administrative distance to basically use the second ISP in the event that the first ISP is unavailable. And if the first is unavailable, the default router provided by them will be unavailable. So we’ll use the default route, which is floating static and resides on my static routing with a greater administrative distance. The typical administrative distance from EBGP is 20 miles. I’m sending my administrative distance to theory, so let me commit.
That exceeds the capacity of ten, so I’m exceeding the capacity of the platform. Let me disable this one for now. And now I should be able to ping. Four four. Let’s take a look. At the ping here, there is probably an issue in my configuration here because I’m not advertising this BGP, so let me fix that. I’m not advertising the two in BGP. So the return traffic is unable to get to me now. I should be able to ping again now. I’m exiting out untrusted using interface ethernet, and I’m getting added behind the interface ethernet one-five because I changed the net and outbound backup ISP, and it’s matching that okay. If I bring up the connection for the ISP, let me bring it up. I should be going through the other interface. So if I look here at the routing table, if we look at the Morine time stat, we see here that routing table zero is now active on the first ISP, and its origin is BGP. And then there’s the backup route. The other backup route is inactive because of its higher administrative distance. So, using administrative distance, you can gauge the distance between different ISPs. However, you have to take into consideration the way the net will take effect. This comes in handy if you’re not advertising your network to the second ISP; you’re just using it as an outbound connection.
10. Multiple ISP Failover using Policy Based Forwarding
So in the last lecture, we saw how to use BGP for failover. There is basically seamless failover between two ISPs for both inbound and outbound traffic. I’m going to expand on that scenario to show you something relating to administrative distance. EBGP is 20 when administrative distance is set. When we receive the default route from the service provider, the administrative distance of this service provider route is 20 because it’s coming from EBGP. So we’re going to expand on the scenario that we had previously. We discussed having two ISPs fill in using BGP. We are going to failover using administrative distance. In this case, the ISP is two. We are not going to establish a BGP neighbour relationship with them. It’s going to be just the first ISP, and then we’re going to specify the default route that gets received by BGP. is from the service provider. For the first service provider, we’re going to use the second service provider for the first service provider. But we’re going to be using the default route with an administrative distance greater than EBGP, which is 20. So I’m going to call this backup ISP zero, and then it’s going to be exiting over Ethernet. and the default route would be two. Two administrative distances would have to be something higher than 20.
We will make it 30. So, even though we receive the static route from the service provider, we will use this floating when the static crowd disappears. We call it “floating” because it has a higher admissive distance than the actual route we received from our ISP one.The actual floating static route will take over. So I have to clean up the configuration here and then commit. I’m going to bring up that connection one more time on this router. So right now, because I didn’t move BGP, I won’t be able to access anything. If I try to go to Thinka Order 4, I’m not unable to because I shut down the first ISP, and that should have worked because the default route is now using the second IC. So let’s take a look at the virtual router, and then we will look at more time stats. And it’s done. So my route is through two universities. I should be getting policy netted on the outside, behind the interface. So one thing stopping me from doing this right now is that I’m using the dynamic IP import and outbound pool, which is set to five five. And that’s not advertised through anything, right? So the traffic goes out, but there’s no way to return back.
So to fix that, I’m going to change the outside network to be using interface addresses, and it’s going to be interface Ethernet. I’ll put this up top. Two, one. Okay, so I’m going to hide behind the outside interface of my firewall. Let me revert that to its previous state, and I’m going to add a rule above it that says if you exit the Ethernet dynamic network to the interface IP address, so I’m going to add a rule. I need to raise it above the existing rule for outbound backup ISP original, trusted packet. Destination is a dubious interface. We’re going to translate it behind the interface IP address. We need to put this above this one; otherwise, it’s not going to work. So basically, I’m hiding the traffic behind the ISP’s IP address. I’m not using the number five. In this scenario, we just want to prove the administrative distance. Floating-static route Using administrative distance to basically use the second ISP in the event that the first ISP is unavailable. And if the first is unavailable, the default router provided by them will be unavailable. So we’ll use the default route, which is floating static and resides on my static routing with a greater administrative distance. The typical administrative distance from EBGP is 20 miles.
I’m sending my administrative distance to theory, so let me commit. That exceeds the capacity of ten, so I’m exceeding the capacity of the platform. Let me disable this one for now. And now I should be able to ping. Four four. Let’s take a look. At the ping here, there is probably an issue in my configuration here because I’m not advertising this BGP, so let me fix that. I’m not advertising the two in BGP. So the return traffic is unable to get to me now. I should be able to ping again now. I’m exiting out untrusted using interface ethernet, and I’m getting added behind the interface ethernet one-five because I changed the net and outbound backup ISP, and it’s matching that okay. If I bring up the connection for the ISP, let me bring it up. I should be going through the other interface. So if I look here at the routing table, if we look at the Morine time stat, we see here that routing table zero is now active on the first ISP, and its origin is BGP. And then there’s the backup route. The other backup route is inactive because of its higher administrative distance. So, using administrative distance, you can gauge the distance between different ISPs. However, you have to take into consideration the way the net will take effect. This comes in handy if you’re not advertising your network to the second ISP; you’re just using it as an outbound connection.
11. Multiple ISP Load Sharing using Policy Based Forwarding
So in this lecture, we will look at using policy-based forwarding to reduce traffic across multiple ISPs. So in our case here under policy-based forwarding, we specified that we’re going to use ISP 1 for the traffic leaving from DMC and Trust. And then we want to create a policy here that says that if you are coming from the guest network, use ISP 2. We already have that in place, which covers the ISP’s two configurations or backup ISP here.
We should add the guest network to this. They get a portion of this, not in this way, when they exit to the Internet. Okay, so that’s the first step. The second step is to implement policy throughout the traffic, starting with the guest traffic source. We’re going to be a guest destination. It will be any forwarding. It’s going to be forward to Egress via Ethernet. Two are next on the list. Two. And since we’re not looking at filling over the traffic in this case, we’re going to basically pin the traffic from the guest network to go over ISP 2. Instead of not using it, it will only be used for guest users, and everything else will be removed. ISP one. That’s basically the policy-based forwarding rule in place that’s active all the time on the Ethernet network Ethernet.This is the exit for the guest user. It’s going to be there all the time.
The policy is “forwarding.” Basically, we have two rules. The guest user will go under this rule. I’m going to go ahead and commit to that. So I have this here on the router for the guest, and I’ll test SSH using that VRF. Well, before we do that, let’s show the PDF rules. We have this rule active all the time. We are going to bring up the other connection up.
So we see that the traffic from the trust and the DMZ is leaving Ethernet. the primary ISP and then the guest, leaving out the secondary ISB. Okay, so we see that the SSH session from guest is going to untrust show session ID 87. We see here that it got the Ethernet interface, and we see that it’s hitting the outbound backup ISP policy, and the policy-based routing is forcing that traffic over the second ISP connection. Let me SSH again here to verify that we can SSH to the router and show users what my IP address should be coming from. Two, two, one, there you go. So you can also use policy-based forwarding to forward traffic based on different things. For example, the address destination, the application, and the service you can forward differ based on different criteria. The second example demonstrates how to use it for no sharing between multiple ISPs.
