05-23-2008 07:13 PM
I have an IPS (Intrustion Prevention) unit that is causing me some problems with some of my servers in my ServerFarm. I would like to route most of my to/from ServerFarm traffic through the IPS, but use some policy-based routing with an ACL (preferably, a policy-based ACL) to allow some servers to bypass the IPS.
So, I thought of taking my Cisco 6509 and making it into a Really Expensive Optical ByPass switch for this small group of servers. The challenge is that the IPS runs strictly at Layer 2. So if I connect the IPS in a loop to the 6509, I must change the MAC addresses on these interfaces on the 6509 so that each address is unique -- as well as assign unique IPs to each of the two interfaces, but the addresses must share the same L3 subnet. Of course, this leads to overlapping addresses on the 6509, which it does not like. So, I want to see if I can try a little VRF-lite to remove the overlapping address problem.
To accomplish the bypass segment, I take a piece of fiber and just connect two ports together on the 6509, changing the MAC addresses and assigning the "overlapping" IPs (which is "solved" by placing the different ports in different VRFs, on just one port in the Global table and the other port in a standalone VRF). If I can do this without running this piece of fiber, I'd be welcome to the idea.
I can fire up OSPF on all of my interfaces, raising the cost of the IPS Bypass link, and use the route-maps to try to route the Bypass traffic correctly. Unfortunately, the route-maps are not behaving. The traffic moves across the two links (one with IPS, one without) assymetrically, which isn't what I want.
I am uploading a diagram that will show a simplified example of what I am doing. Here is my config below. Does anyone have any ideas on what I am doing wrong, or a better way to do this? (I tried a VACL approach, but I could not redirect the traffic properly):
ip vrf Srv
description ServerNets
rd 65000:10
object-group ip address IPS-Ignore
host 192.168.20.2
interface GigabitEthernet1/3
ip address 192.168.200.1 255.255.255.0
ip policy route-map ServerNetIngress
interface GigabitEthernet1/9
description ServerNets
no ip address
ip flow ingress
!
interface GigabitEthernet1/9.20
description PublicServerNet
encapsulation dot1Q 20
ip vrf forwarding Srv
ip address 192.168.20.1 255.255.255.128
ip flow ingress
ip policy route-map ServerNetEgress
interface GigabitEthernet1/15
description IPS-ByPass-Global
mac-address 0015.c7c9.c10f
ip address 192.168.15.73 255.255.255.252
ip flow ingress
ip ospf cost 100
interface GigabitEthernet1/17
description IPS-ByPass-Srv-VRF
mac-address 0015.c7c9.c111
ip vrf forwarding Srv
ip address 192.168.15.74 255.255.255.252
ip flow ingress
ip ospf cost 100
interface GigabitEthernet1/19
description IPS-Scrub-Global
mac-address 0015.c7c9.c113
ip address 10.0.0.2 255.255.255.252
ip flow ingress
interface GigabitEthernet1/21
description IPS-Scrub-Srv-VRF
mac-address 0015.c7c9.c115
ip vrf forwarding Srv
ip address 10.0.0.1 255.255.255.252
ip flow ingress
router ospf 10 vrf Srv
router-id 192.168.10.1
log-adjacency-changes
capability vrf-lite
network 192.168.0.0 0.0.255.255 area 0
!
router ospf 1
router-id 192.168.0.1
log-adjacency-changes
network 192.168.0.0 0.0.255.255 area 0
ip access-list extended IPS-Bypass
permit ip addrgroup IPS-Ignore any
permit ip any addrgroup IPS-Ignore
route-map ServerNetIngress permit 100
description ByPassIPS
match ip address IPS-Bypass
set global
set ip next-hop 192.168.15.74 10.0.0.1
!
route-map ServerNetEgress permit 100
description ByPassIPS
match ip address IPS-Bypass
set ip vrf Srv next-hop 192.168.15.73 10.0.0.2
I obfuscated my addresses, so don't let that throw you off too much.
Clarke Morledge
College of William and Mary
05-24-2008 07:43 AM
Clarke,
Can you try removing the "set global" and replace the "set ip vrf Srv next-hop" by "set ip next-hop" in the respective route-map. These commands are intended for a feture called "Multi-VRF Selection using PBR". This is not exactly what you want here, in the sense that traffic coming from the global will be forwarded based on the global routing table and traffic coming from the VRF will be forwarded using the VRF routing table, which is default behavior.
Regards,
06-10-2008 09:55 AM
Thank you for the suggestion. Just using the "set ip next-hop" in the respective route-map is sufficient and gets the job done. Unfortunately, my problem is more with how the policy-based ACLs (PBACLs) work; i.e. the lines with the object-group syntax in the config. My contact with the TAC tells me that PBACLs are not really supported to do policy-based routing. So because the PBACL is not working correctly all of the time, things don't get matched properly in the route-map for the policy-based route to get correctly applied.
This is really too bad since the PBACL looks to be a quite handy feature. In my example -- at least in theory -- I should be able to make but one change to the "object-group" in order to properly handle the policy-based routing involving the two different route-maps. Alas, this is not as easy as I hoped for since making changes to the PBACL apparently produces unpredictable results -- and the TAC just tells me that the feature is not supported for what I want to do.
06-11-2008 05:05 AM
Clarke,
I'm glad you got it working.
Regards,
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: