08-11-2004 01:41 PM
I have the need to use different default-routes depending on the source-address of the packet, when it comes from the content switch (e.g. from a group-address or as response-packet in a conversation with
a content address).
The reason for this requirement ist, that I have one firewall which is connected to both vlan2 and vlan602.
First there are rules, which disallow some traffic between 128.111.1.0 and 128.222.2.0. (addresses are only examples !!)
Second there occurs a routing-triangle which results
in blocking of path through the (statefull) firewall because the firewall sees no completion of the tcp 3-way handshake.
I tried this configuration but it does not work.
Pakets from 128.222.2.x adresses to 128.111.1.x adresses are send directly to the destination because the address in the arp-cache of the content switch.
any ideas ??
ip route 0.0.0.0 0.0.0.0 128.111.1.1 1
ip route 0.0.0.0 0.0.0.0 128.222.2.1 1
!************************* INTERFACE *************************
interface 1/1
trunk
vlan 2
vlan 602
!************************** CIRCUIT **************************
circuit VLAN2
ip address 128.111.1.101 255.255.255.0
ip virtual-router 2 priority 254 preempt
ip redundant-interface 2 128.111.1.100
circuit VLAN602
ip address 128.222.2.101 255.255.255.0
ip virtual-router 102 priority 254 preempt
ip redundant-interface 102 128.222.2.100
08-11-2004 11:37 PM
HI,
in my opinion this can not be solved with a CSS as you want to do policy based routing and as routing criteria the source-IP if I understood your question right. In my opinion you have to place a router between the CSSes and the Firewalls to be able to do that.
Regards,
Joerg
08-12-2004 04:12 AM
I'm with Joerg, use a router outside the CSS and you can use PBR to do whatever you want.
Paul.
08-13-2004 01:57 PM
The problem with using PBR is the issue of scalability since PBR is process switched. You would need pretty sizeable upstream routers to do PBR at 100+ Mbps rate, let alone trying to do this at gig rate. Someone will probably point out that some of the L3 switches will do PBR at gig line rate, and I have done it on the 3750, but all the planets have to line up just right and you have to do much placating of the TCAM god (e.g. no ACE that would result in TCAM subtraction). Otherwise, PBR will get process switched and the processor will go to 100% with throughput of only 60-70 Mbps. PBR also makes it more complex to implement redundancy; probably have to use object tracking.
It would just be more straightforward and simpler if the CSS can use the "most appropriate" next hop for the source IP in question. For example, group A uses 1.1.1.1 and group B uses 2.2.2.2, and you have default gateways 1.1.1.254 and 2.2.2.254 configured. So the desired behaviour would be for all outbound traffic NAT'd to 1.1.1.1 to be automagically route to 1.1.1.254 for its next hop, and similarly for 2.2.2.2 and 2.2.2.254. I am sure some of the competing products (e.g. RADware Linkproof) can do this.
I have submitted this as a feature request to our local Cisco SE. We'll see if anything comes of it.
08-13-2004 02:00 PM
Additionally, since the CSS is flow based, it should have sufficient clue to send the return traffic out to the same next hop (maybe identifiable via L2 adjacency info, e.g. MAC address) that the inbound traffic came in from.
08-13-2004 01:24 AM
here is a solution.
Create a service pointing at the firewall ip address.
ie:
service FW_ip1
ip address 128.222.2.1
active
Then configure the following acl
acl 1
clause 10 permit any 128.222.2.0 255.255.255.0 destination 128.111.1.0 255.255.255.0 prefer FW_ip1
clause 99 permit any any dest any
apply all
Regards,
Gilles.
08-13-2004 01:44 AM
HI Gilles,
great thing...
Didn't think about that kind of possibility to do "routing"....
Regards,
Joerg
08-13-2004 08:14 PM
This looks like it will work for return traffic for an established flow. But are you sure it would work for outbound (group NAT'd) traffic? Doesn't the ACL work in the inbound direction only? If so, would this still work if the ACL is applied to the pre-NAT'd inbound traffic to the "inside" interface?
08-16-2004 12:22 AM
this won't work for established flow.
Once a flow is created it can't be modified.
This solution is for new sessions.
ACL are indeed applied on inbound, so think about your ACL acarefully.
Finally, if some nating is needed, use the acl to perform the nating - see my previous answer.
Regards,
Gilles.
08-14-2004 09:16 AM
I tried this, but it does not work (with 7.30 version).
I tried it with and without 'ip opportunistic all'.
I played with the 'ip ecmp' command too, but it did not help.
Should this work for outgoing flows resulting from NAT based on groups ?
when I run the debug-command 'ip routes master' their is a routing-table entry like:
0x8a68de08 128.111.1.74/32 08-00-20-fe-58-80 Dynamic
resulting from the arp entry.
Maybe the problem is, that this is an /32 entry which
will be used before /24 entries ?
when a do a 'sh acl 1' the usage -count for clause 10 is always zero !!
when I configure an explicit route:
ip route 128.111.1.74 255.255.255.255 128.222.2.1 1
this route never shows up in 'show ip routes' !!
08-16-2004 12:20 AM
First, the static host route will not override a locally attached route. That's the way they design the CSS.
Regarding the solution provided.
Remember the acl is only applied inbound.
Then, if you need some nating do the following
acl 1
clause 10 permit any
I did not test this myself but I know one customer doing it successfully.
Regards,
Gilles.
08-16-2004 06:35 AM
I tried now the following acl-clause:
clause 3 permit any 192.168.7.60 destination 128.1.1.0 255.255.255.0 sourcegroup belanna1n prefer gw-128.222.2
Sourcegroup belanna1n looks like
group belanna1n
vip address 128.222.2.60
add service belanna1i
active
and the Service is:
service gw-128.222.2
ip address 128.222.2.1
active
I also did a clause 3 log enabled
First I tried a ping: the sys.log looks like:
AUG 16 15:17:00 1/1 347 ACL-7: ACL match 1:3 Forwarding
AUG 16 15:17:00 1/1 348 ACL-7: ICMP
AUG 16 15:17:00 1/1 349 ACL-7: Source: 192.168.7.60
AUG 16 15:17:00 1/1 350 ACL-7: Dest: 128.111.1.74
The destination host still reaches the packet directly from the content switch (verified by tcpdump)
Then I tried a telnet to port 80:
No the log looks like:
AUG 16 15:19:12 1/1 351 ACL-7: ACL rule match 1:3 Redirecting packet, Log Enabled
AUG 16 15:19:12 1/1 352 ACL-7: ACL returning preferred service index 7
The service gw-128.222.2 has number 7, which seems ok.
But: no packets leave the content-switch at all !!!!
08-17-2004 01:30 AM
I just did the test and it works for me.
However, I noticed I forgot to mention that the GW service definition requires the command 'type transparent' so the CSS does not nat the destination ip address.
Regards,
Gilles.
08-17-2004 04:02 AM
ok, after inserting the type transparent-cache statement now this works for hosts in the 128.111.1.0 network which are not vip of the CSS.
When I access a host e.g. 128.111.1.42 -- which
has defined http as content -- from 128.222.2.40,
the packet goes first to the firewall (128.222.2.1)
which sends it back on the other vlan to the
128.111.1.42 adresse. But the return-packets
go directly in the CSS from 128.111.1.42 to 128.222.2.40
how can I solve this problem ?
08-17-2004 05:56 AM
can't you do the same acl for the reverse path ?
This solution won't work with VIP.
If you need such requirement, the CSM is much better for that.
Regards,
Gilles.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide