topic Re: Source Groups in Application Networking

Source Groups

JHaynes4 — Wed, 30 Jul 2003 21:04:30 GMT

I have a question regarding source groups used to allow servers behind the Content Switch to initiate connections to the outside.

I understand the concept of creating a source group and adding the services (servers) that will be included within it, and also giving this a VIP address to be used as the source IP for the services connection to the outside world. A content rule is then created for these connections using the same VIP and services as referenced in the source group configuration. It is at this point I have a question regarding the configuration.

Do I have to specify, in the content rule, what protocol and port the services will be using? For instance if I want the servers to be able to make DNS queries, do ftp file transfers, and contact a database is it required that I configure a seperate content rule for each type of connection, or can I make one content rule without specifying what protocol and port to be used, and this would suffice for all types of connections the services try to initiate.

Thanks in advance for any help provided.

Re: Source Groups

d.parks — Wed, 30 Jul 2003 21:20:12 GMT

You shouldn't need source groups for your servers to initiate connections to the outside world unless you want or need all the traffic to appear as it is coming from a VIP address.

If you do want to use a group, I don't think you need a content rule, but I've never used a group in this way.

Generally, I've used groups to NAT traffic in the other direction (from the client), in one-armed configurations to force the correct return path from the server back to the client. In this configuration, I add destination services to the group to instruct the CSS as to which traffic it should NAT.

Re: Source Groups

JHaynes4 — Wed, 30 Jul 2003 23:13:16 GMT

Dominic,

Thanks for the quick reply.

What method are you using in order for the servers to initiate connections to the outside? The CSS Basic Guide book uses Source Groups as the method.

As things stand now, the servers are not able to contact outside devices by initiating the connection. They work for connections initiated on the outside to the VIP we use for them, but not in the reverse. The connections appear to die at the Content Switch when initiated from the inside.

Re: Source Groups

pknoops — Thu, 31 Jul 2003 01:09:08 GMT

Hi,

You will in fact need to use the source groups in the manner you describe and will need the content rule, however, you could potentially just have the content rule as an L3 rule with just the services and vip address and not specify the protocol or port and leave it wide open.

Regards

Pete Knoops

Cisco TAC

Re: Source Groups

JHaynes4 — Thu, 31 Jul 2003 12:00:09 GMT

Pete,

That's what I was thinking. Thanks for the clarification.

Re: Source Groups

d.parks — Thu, 31 Jul 2003 12:17:01 GMT

Pete,

Could you point me to the doc that shows this as a requirement?

I will be migrating my CSS's to a L3 configuration (The CSS as default gateway for the web pool) soon and this could throw a big wrench in my plans.

The way I interpreted the documentation is that I would only need source groups if I want the servers to appear as one IP address to the rest of the network, or if I need to translate their private address to a public. We do our private/public NAT on a firewall, so I have no public addressing on the CSS itself.

My (perhaps incorrect?) assumption is that the CSS will just route any and all IP traffic normally between interfaces.

Thanks,

Dominic

Re: Source Groups

pknoops — Thu, 31 Jul 2003 12:51:15 GMT

Dominic,

I'm not sure there is one. The assumption I make here is that the servers and vips are on different networks. If they are on the same network, then you probably don't need to do this. It becomes an issue when the vip (public) and servers (private) are setup in this manner. Specifically, the packet leaving the server through the CSS goes out. On the return, the packet hits the upstream router and does not have a path back to the CSS as the router (in most cases) is only sending VIP destined traffic to the CSS which is why we would NAT the server request to the VIP. If the upstream router has a static route with the servers network with a next hop of the CSS, then maybe this is not necessary

Pete..

Re: Source Groups

rlu — Thu, 31 Jul 2003 18:12:14 GMT

Hi Pete,

The configuration task in Basic Configuration Guide(7.20) requires configuring "add service" or "add destination service" in source group(Step 3). However, I saw the following source group configuration from a production network, how does it work.

!*************************** GROUP ***************************

group out1

vip address 142.146.232.70

active

group out2

vip address 142.146.232.72

active

group out3

vip address 142.146.232.74

active

group out4

vip address 142.146.232.76

active

group out5

vip address 142.146.232.78

active

group out6

vip address 142.146.232.80

active

group out7

vip address 142.146.232.82

active

group out8

vip address 142.146.232.84

active

group out9

vip address 142.146.232.88

active

!**************************** ACL ****************************

acl 1

......

clause 4 permit icmp 10.0.0.0 255.224.0.0 destination any sourcegroup out1

clause 5 permit any 10.0.0.0 255.224.0.0 destination any sourcegroup out1

clause 6 permit icmp 10.32.0.0 255.224.0.0 destination any sourcegroup out2

clause 7 permit any 10.32.0.0 255.224.0.0 destination any sourcegroup out2

clause 8 permit icmp 10.64.0.0 255.224.0.0 destination any sourcegroup out3

clause 9 permit any 10.64.0.0 255.224.0.0 destination any sourcegroup out3

clause 10 permit icmp 10.96.0.0 255.224.0.0 destination any sourcegroup out4

clause 11 permit any 10.96.0.0 255.224.0.0 destination any sourcegroup out4

clause 12 permit icmp 10.128.0.0 255.224.0.0 destination any sourcegroup out5

clause 13 permit any 10.128.0.0 255.224.0.0 destination any sourcegroup out5

clause 14 permit icmp 10.160.0.0 255.224.0.0 destination any sourcegroup out6

clause 15 permit any 10.160.0.0 255.224.0.0 destination any sourcegroup out6

clause 16 permit icmp 10.192.0.0 255.224.0.0 destination any sourcegroup out7

clause 17 permit any 10.192.0.0 255.224.0.0 destination any sourcegroup out7

clause 18 permit icmp 10.224.0.0 255.224.0.0 destination any sourcegroup out8

clause 19 permit any 10.224.0.0 255.224.0.0 destination any sourcegroup out8

clause 20 permit icmp 142.146.0.0 255.255.0.0 destination any sourcegroup out9

clause 21 permit any 142.146.0.0 255.255.0.0 destination any sourcegroup out9

clause 22 permit icmp 172.16.0.0 255.240.0.0 destination any sourcegroup out9

clause 23 permit any 172.16.0.0 255.240.0.0 destination any sourcegroup out9

clause 24 permit icmp 192.168.0.0 255.255.0.0 destination any sourcegroup out9

clause 25 permit any 192.168.0.0 255.255.0.0 destination any sourcegroup out9

clause 30 permit icmp 192.219.100.0 255.255.255.0 destination any sourcegroup out9

clause 31 permit any 192.219.100.0 255.255.255.0 destination any sourcegroup out9

apply circuit-(VLAN300)

Would you please clarify me.

Thanks,

Richard

Re: Source Groups

jfoerster — Fri, 01 Aug 2003 08:03:28 GMT

Hello Richard,

this is the other way to do NAT (refer to http://www.cisco.com/en/US/partner/products/hw/contnetw/ps789/products_configuration_example09186a008009470e.shtml) The only bad thing on this method is, that you have to apply acls on all circuits even if a permit any any is necessary as enabling acls stops all traffic from getting forward except the circutis you applied a acl. I would prefer the earlier described method if I won't have to do traffic filtering on the CSS. Another aspect is the bypassing. Afaik bypassing NAT is not possible with add destination service.

Kind Regards,

Joerg

Re: Source Groups

rlu — Fri, 01 Aug 2003 12:34:23 GMT

Excellent,

Thanks Joerg

Richard