cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
493
Views
0
Helpful
4
Replies

ACE routing situation.

ggalteroo
Level 1
Level 1

Is there a way to allow the servers on vlans B and C to talk to any VIP on vlan A? Vlans B and C are directly connected to the ACE being the

ACE the default gateway.

So far, I cannot start a connection to neither the VIPs nor the ACE's interface on vlan A from a subnet directly connected to the ACE. In this case B and C.

The scenario was simplified but the idea behind this is that servers on vlan C use balanced services on other systems also on vlan C and for

that reason they seek a VIP.

Right now vlans B and C are connected to de Catalyst and since the only link to the ACE is vlan A, a NAT policy solves it all. By the way,

NAT doesn't seam to work on directly connected networks. At least not on release A2(1.0a). No caveats were posted on this matter.

Does this make any sence? Can it be "workarounded"? Does NAT require a L3 hop to work? Would a transit subnet on the way to ACE, from clients and

servers do the trick? I mean no host on directly connected subnets. How about VIPs on vlan C for SLB within that vlan? The NAT issue remains as a problem

since servers won't talk to the ACE to reach subnet peers.

Thanks a lot.

Guido

4 Replies 4

If Server vlans are connected to ACE and defined on ACE then you need multi-match policy & Nat pool on the server vlans.

This multi-match policy will listen to the same VIP and nat-pool will ensure symmetrical routing.

Syed

Thank you

I tried it and worked fine though a new question arose regarding name resolution. Whenever users need to reach a server they get an IP on VLAN A. Whenever servers need to reach a VLAN peer they would also get a VLAN A IP. Is there a way to avoid a second set of DNS names?

Thanks again!

Could you please rephrase your question.

Do you want Servers to use a different nat-pool?

Syed

Syed

A nat pool is not my problem right now. What I needed was a way of reaching the VIPs from any interface which seemed not to work for interfaces other than the one belonging to the same range the VIPs do.

Right now I've solved the problem by applying the service-policy globally. Not only that was necesary to get this to work but that was the beginning of it.

I've tried though applying the service-policy to every interface but that, for some reason, didn't work at first. On a second attempt, worked fine. I Cannot explain waht happend.

Anyways the routing problem is now solved.

Thanks for your time!

Getting Started

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: