Migration CSS to ACE.

[Jaime Soto Valenzuela]

Hi all,

Last night I performed the migration of two CCS to two ACE of our client. In the settings remain the same policies that existed in the CSS. These CSS are giving Internet services so there is a firewall that had reached them. The VIP at that point customers are 200.29.72.226 and 200.29.72.228, which are the same ones that had what CSS.

A level of connectivity could not leave from the Firewall to either VIP, but he could reach the IP VLAN interface configured on the ACE (200.29.72.233).

It was clean the ARP table on the firewall without having positive results.

I requested to test the customer to capture traffic on the ACE and when he did ping either the ACE VIP I dont see traffic.

Servers belonging to VLAN 2 on the ACE can be seen, o the VIP are in state IN-SERVICE

I attached the configuration.

I hope your help.

Regards,

Jaime.

[UHansen1976]

Jaime,

I might have completely misunderstood your configuration, but here are my observations.

It looks like you want to apply XLATE to any inbound sessions that hits your VIP. If that is indeed your intention, I'm not sure your NAT-configuration will work as expected. Usually you would translate the public src.ip to an internal ip, usually within the address space, that your internal interface is configured with. In your case, 10.3.0.0/16.

When looking at your multi-match POLICY, it looks like your trying to catch any traffic originating from one your rservers and applying NAT to them. And it also looks like your trying to NAT this traffic to the same ip as your VIP-addresses are configured with. I would expect, that you wish to apply NAT to inbound traffic hitting any of the VIPS and translating the src.address to an internal address, making it appear as if the request towards the www/ftp service originates from an internal ip.

I've downloaded the attached file and made a few modifications to it. The 'xxx' value in the nat-pool statement is to be replaced with an octet of your choice, since I have no knowledge of your address allocation. This way, any external traffic that hits any of the VIP's, will be translated to an internal address within the same range as your internal interface and servers reside in. You could choose to use seperate NAT-pools for www and ftp traffic respectively.

Furthermore, if you indeed need to handle traffic originating from the serverfarms toward the internet, you might consider using an address not used by your VIPs. And I would recommend handling this traffic in a dedicated service-policy.

hth

Message was edited by: UHansen1976

[Jaime Soto Valenzuela]

Thank for your response.

But I dont want to do NAT a inbound traffic. The implementation in the ACE is in ROUTED-MODE, so the ACE performed internally routing between VLAN 46 (client side) and VLAN 2 (server side). The NAT is applied to outbound traffic.

What I find strange is that it had no response from the VIP  formerly the CSS and are now in ACE. It may be that these IPs were with  the MAC of the CSS and for that reason are not seeing the new VIP?.

In the ACE the VIP are IN-SERVICE state and is configured to  respond to ICMP when they are active.

This is a part of the configuration:

class-map match-all ftp_www3_CLASS
  2 match virtual-address 200.29.72.228 tcp range 20 22 (without response)
class-map match-all ftp_www_CLASS
  2 match virtual-address 200.29.72.226 tcp range 20 22 (without response)

interface vlan 46
  description Firewalls
  ip address 200.29.72.233 255.255.255.240 (with response)
  peer ip address 200.29.72.234 255.255.255.240 (with response)
  access-group input permit_all
  nat-pool 1 200.29.72.226 200.29.72.226 netmask 255.255.255.255 pat
  nat-pool 2 200.29.72.228 200.29.72.228 netmask 255.255.255.255 pat
  no shutdown

The new IPs configured in the VLAN interfaces (46) Ping response, but the VIP (which were previously the CSS) dont respond.

Thanks and regards,

Jaime.

[UHansen1976]

Okay,

When you're ping'ing the VIP's, do you see any hits on your access-list permit_all ? The counter should increment.

What does the ARP-table say?

Also, have you looked into this:

active

(Optional) Instructs the ACE to reply to an ICMP request only if the  configured VIP is active. If the VIP is not active and the active option is specified, the ACE discards the ICMP  request and the request times out.

From your configuration, it looks like you've configured the icmp-reply with the 'active' option.

[Jaime Soto Valenzuela]

What I did can verify was to capture traffic and saw no traffic coming to the ACE when pointing to the VIP address.

The ARP tables to wich I refer are those of the FW that performed the routing for VLAN 46 (I guess the FW can have on their ARP tables IPs of the VIP, but with the MAC that it knew of old CSS)

In the next configuration you can see that I have configured policies for reponse a ICMP when VIP is ACTIVE.

Then I attached a output of  "show service-policy summary" in which you can see that VIP is ACTIVE.

policy-map multi-match POLICY
  class www3_CLASS
    loadbalance vip inservice
    loadbalance policy www3_POLICY
    loadbalance vip icmp-reply active
  class www_CLASS
    loadbalance vip inservice
    loadbalance policy www_POLICY
    loadbalance vip icmp-reply active
  class ftp_www3_CLASS
    loadbalance vip inservice
    loadbalance policy ftp_www3_POLICY
    loadbalance vip icmp-reply active
    inspect ftp
  class ftp_www_CLASS
    loadbalance vip inservice
    loadbalance policy ftp_www_POLICY
    loadbalance vip icmp-reply active
    inspect ftp          

ACE-INTERNET-1/CONTEXTO_A# sh service-policy summ

service-policy: POLICY
Class                            VIP             Prot            Port        VLAN                State    Curr Conns   Hit Count  Conns Drop     
                                                                                                                                                    
www3_CLASS                       200.29.72.228   tcp       23   -65535         ALL           IN-SRVC           0           0          0   

www_CLASS                        200.29.72.226   tcp       23   -65535         ALL           IN-SRVC           0           0          0      

ftp_www3_CLASS                   200.29.72.228   tcp       20   -22            ALL           IN-SRVC           0           0          0   
    
ftp_www_CLASS                    200.29.72.226   tcp       20   -22            ALL           OUT-SRVC          0           0          0            

Regards,

Jaime.

[UHansen1976]

Does your capture provide you with information on what the fw does with the lost icmp-packets?

Where did you perform the capture, on the ACE itself or in the vlan between the fw and the ACE?.

[Jaime Soto Valenzuela]

What I did was to capture the incoming traffic to the VLAN 46 but like I said it saw no traffic on the ACE.

With this I conclude that the packages I can not arrive at ACE.

Regards.

Jaime.

[UHansen1976]

Okay,

So I guess to focus should be on the firewall. I would check the arp table (and routing, unless the fw is directly connected to vlan46). Also, I've had some strange things happen to me on account of statics. Can you ping the VIP from the fw, which seems to be the last hop before the ACE?

Other than that, there's not much else I can give you at this moment.

hth