Using VRF-Lite in 6509 as Really Expensive IPS ByPass

Unanswered Question
May 23rd, 2008
User Badges:

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



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Harold Ritter Sat, 05/24/2008 - 07:43
User Badges:
  • Cisco Employee,

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,

cmorledge Tue, 06/10/2008 - 09:55
User Badges:

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.

Actions

This Discussion