Policy Base Routing - Router unwanted traffic via low bandwidth link

Let's say UserA and UserB are connected to the R4 router.

IT team noticed UserA is playing games on the Internet. IT team wants to traffic UserA packets via a slow bandwidth link.

UserA -> R4 -> R3 -> R2 -> R1 (which is lwo bandwidth)

UserB -> R4 -> R3 -> R1

HERE POLICY BASE ROUTING

R3 configuration

# ip access-list standard PBR-ACL

# permit 192.168.4.128 0.0.0.127 ((which is USERB traffic))

# exit

# route-map R3toR1 permit

# match ip address PBR-ACL

# set ip next-hop 172.16.13.1 (the interface which is facing to R3 from R1)

# exit

# int s0/0

# ip policy route-map R3toR1

See... now the 129 UserB traffic going as per the proposed design. 

R3# debug ip policy 1

SUMMARY AND ERROR FIXING ACL

 

1. All the routers are configured and apply the EIGRP as the routing protocol.

a) Now its able to ping all IP addresses in the topology.

b) Ex: R1 can ping to R4 and vice versa.

 

2. But see the connection between the routers are having different size of bandwidth. Ex: From R1 to R2 = 128 BW. So when we traceroute from R4 loopback interface with its 4.1 or 4.129, the traffic path would be the same as it is getting higher bandwidth path as per the cost of EIGRP.

a) As a summary, it takes the path as from 4.1 network
R4 -> R3 -> R2 -> R1 -> 192 network.

b) Let’s say we want to forward 4.129 traffic via low cost bandwidth which is 64 as from R4 -> R3 -> R1.

c) Here we have to use the amazing feature Path Control - Policy Base Routing.

 

 

 

3. Let’s configure the R3 router.

 

# ip access-list standard PBR-ACL

# permit 192.168.4.128 0.0.0.127

We are going to permit the 4.128 network via PBR-ACL

 

Creating a route map to apply in.

# route-map R3toR1 permit

# match ip address PBR-ACL

# set ip next-hop 172.16.13.1

Apply this route map to the interface facing to R4 router.

# int s0/0

# ip policy route-map R3toR1

 

Now all done? Not yet, we allow only 4.128 network via ACL. Last line implicit deny rule apply by default and it will not allow the 4.1 traffic and deny 4.1 traffic.

 

So we need to create another ACL to allow 4. network traffic on R3

# access-list 1 permit 192.168.4.0 0.0.0.255

# exit

 

Let’s see the router now.

 

 

Now let’s test this.

# debug ip policy 1

 

 

 

See, now the 4.129 traffic go via R3 -> R1 instead of going towards to R2.

 

 

Ping from PC1 through ASA to PC3 and XP http to DMZ Web Server

  

• ASA outside = 209.165.200.226/28
• DMZ Web server = 192.168.2.254
• PC1 = 10.10.10.100
• PC3 = 172.16.3.100
• XP = 172.16.3.10
• Outside XP network shoud route via default route 0.0.0.0 0.0.0.0.0 172.16.3.1

ASA

# route outside 0.0.0.0 0.0.0.0 209.165.200.225 1

Now ASA can ping PC3

Ping Pc3 from PC1

ASA

# object network inside-net

# subnet 10.10.10.0 255.255.255.0

# nat (inside,outside) dynamic interface

# class-map inspection_default

# match default-inspection-policy

# policy-map global_policy

# class inspection_default

# inspect icmp

# service-policy global_policy global

NOW PC1 able to ping PC3.

--------------------------------------------

Configure XP user to connect Web Server at DMZ

# object network dmz-server

# host 192.168.2.254

# nat (dmz,outside) static 209.165.200.227

# access-list OUTSIDE-DMZ extended permit ip any host 192.168.2.254

# access-group OUTSIDE-DMZ in interface outside

Now able to ping WEB server and can http://209.165.200.227 from XP user.

---------------

If want to ping PC3 from DMZ

# object network dmz-net

# subnet 192.168.2.0 255.255.255.0

# nat (dmz,outside) dymanic interface

BONUS TIP!

#access-list TEST line 3 extended permit tcp any host 192.168.2.254 eq telnet

Add IP to block or allow with a port.

Cisco FMC and FTD Firmware Upgrade - New Interface 2022

  

FMC and FTD Firmware Upgrade

1. Check the TAC support.

2. Send SOC for firmware recommendation.

3. Propose patching date to the customer.

4. Open a Cisco TAC case.

5. Send email to customer confirming the date.

Procedure (1) FMC

1. Take back up from FMC and FTD on both devices.

2. Download the back to a shared location.

3. Send an email to the customer before the outage.

4. Click on Systems > Update to install the firmware on FMC.

5. Run readiness check for errors. Readiness check: this will take 10 minutes. when starting it, nothing will progress, but after that, it starts to show the progress bar.

6. It will pass the check and then you have to press the install button. When clicking on the install button, it will directed to update/System page. Then you can see the task tab to see the progress.

7. This will take 60-90 minutes to reboot the FMC. Meantime, the web GUI disconnected. We can ping the IP. But cannot log in using our domain credentials. I used an admin account. (The login page looks traditional). When you log in, you can see the progress.

8. There isn’t any network interruption. Installation (may take 60-90 minutes)

9. When rebooting the FMC, you cannot access it via your credentials. You have to log in via an admin account. Then you can see the progress. (Here, at 9% it took 30 minutes, and then 22% took another 30 minutes).

10. When rebooting the FMC, a msg popped up on the WEB screen saying the system is rebooting.

11. This time you cannot ping, So put a continuous ping and verify the FMC connectivity.

12. Once ping success, after a couple of minutes you can access the FMC via WEB with your credentials. When the page is refreshed, it will take a little time to load the page. Then you can login via domain credentials.

13. Verify the upgrades firmware.

14. Send an email to the client.

Procedure (2) FTD devices.

1. System Update and install.

2. It will install the firmware for the secondary device as it is.

3. This will take 30 minutes to upgrade the secondary.

4. While installing the process you can see, retry, and remove maintenance messages. Don’t panic here. It takes time and finishes the installation for secondary. Meantime you can see it has been upgraded to the new version.

5. Rebooting the FTD.

6. Then this happens to the primary device.

7. When rebooting it goes to secondary due to HA.

8. After completing both, you can see the upgraded version on FTD in the device tab.

9. Then you must deploy the policies if it's available to do so.

10. Here, you can see the warning and error before pressing the deploy button.

11. All completed.

12. Send an email to the client and close the change.

 #FMC #FTD #7.0.1