ACE multicast MAC and new release A3(2.6)

[vaba]

Hi,

Our ACE 4710 is setup to forward traffic to a CheckPoint Cluster IP as default gateway. Checkpoint working in active/active mode and using multicast mac address. This mean that mac address on CheckPoint Cluster VIP is 01.00.5e.xx.xx.xx. In release A3(2.6) says that is possible:

http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_x/release/note/RACEA3X.html#wp568729

Per CSCsr19346, the static arp command in configuration mode now allows the configuration of the multicast MAC address for a host. The ACE uses this multicast MAC address while sending packets to the host. This enhancement allows the support of deployments that involve clustering (for example Checkpoint clustering). A host can be assigned an multicast MAC address with the arp command. The ACE does not learn the multicast MAC addresses for a host.

I am using the command:

arp <CheckPoint Cluster ip> 01.00.5e.xx.xx.xx to set ip address and MAC address, but

ACE cannot ping the CheckPoint Cluster ip. ACE not creates sessions to CheckPoint Cluster ip and not generates any traffic. When I ping any physical address on CheckPoint firewall everything is ok. Is it possible to using CheckPoint Cluster ip for default gatawey and how to realize that?

Thanks in advance

[yushimaz · Accepted solution]

I checked the behavior in my lab. As you says, ping packets "generated by ACE" are dropped.

It doesn't depend on default gateway configuration. I can see this symptom without default gw

configuration.

I also checked several commands and found the following counter is increased.

Probably, verification check of mac address is failed.

ACE4710/Admin# sh np 1 me-stats -sicm | i MAC

MAC Lookup Error:                               148             0

It doesn't occur on transit (not generated by ACE) packets.

So, it seems that CSCsr19346 doesn't care packets generated by ACE.

If you want to ping from ACE, please contact TAC. It may be a new bug.

The following is my test result

### config

ACE4710a-yushimaz/Admin# sh run | i route

Generating configuration....

ip route 0.0.0.0 0.0.0.0 192.168.221.10  <<== default gw

ACE4710a-yushimaz/Admin#

ACE4710a-yushimaz/Admin# sh run | i arp

Generating configuration....

arp 192.168.221.10 01.00.5e.11.11.11  <<== static arp with mcast mac

arp 192.168.221.20 00.00.6c.11.11.11

### ping from server to default gw via(routed by) ACE

ACE4710a-yushimaz/Admin# sh logging

[snip]

%ACE-6-302026: Built ICMP connection for faddr 192.168.221.10/29549 gaddr 192.1

68.222.4/8 laddr 192.168.222.4/29549  <<== ACE created the connection

## capture trace

No.     Time                          Source                Destination           Protocol Info

     23 2010-08-25 03:57:18.494195731 192.168.222.4         192.168.221.10        ICMP     Echo (ping) request

Frame 23 (106 bytes on wire, 102 bytes captured)

Ethernet II, Src: Cisco_75:91:ed (00:0f:f7:75:91:ed), Dst: Cisco_fe:1b:01 (00:0b:fc:fe:1b:01)  <<== from server to ACE

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 722

No.     Time                          Source                Destination           Protocol Info

     24 2010-08-25 03:57:18.494213331 192.168.222.4         192.168.221.10        ICMP     Echo (ping) request

Frame 24 (106 bytes on wire, 102 bytes captured)

Ethernet II, Src: Cisco_fe:1b:01 (00:0b:fc:fe:1b:01), Dst: IPv4mcast_11:11:11 (01:00:5e:11:11:11) <<== from ACE to gw

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 721

### ping from ACE to default gw

ACE4710a-yushimaz/Admin# sh np 1 me-stats -sicm | i MAC

MAC Lookup Error:                               148             0

ACE4710a-yushimaz/Admin#

ACE4710a-yushimaz/Admin# ping 192.168.221.10

Pinging 192.168.221.10 with timeout = 2, count = 5, size = 100 ....

No response received from 192.168.221.10 within last 2 sec

No response received from 192.168.221.10 within last 2 sec

No response received from 192.168.221.10 within last 2 sec

No response received from 192.168.221.10 within last 2 sec

No response received from 192.168.221.10 within last 2 sec

5 packet sent, 0 responses received, 100% packet loss

ACE4710a-yushimaz/Admin# sh logging

[snip]

%ACE-7-111009: User 'admin' executed cmd: clear logging

%ACE-7-111009: User 'admin' executed cmd: ping 192.168.221.10

  <<== not logged 'Built ICMP connection'

ACE4710a-yushimaz/Admin# sh np 1 me-stats -sicm | i MAC

MAC Lookup Error:                               153             0  <<==

Regards,

Yuji

[jon.humphries · Accepted solution]

Hi,

I have the same issue, however slightly different results/equipment.

I'm using an ACE module in a 6500 split into to multi-context and have a cluster checkpoint upstream as the ACE contexts default gateway.

The ACE can poll the real interfaces of the checkpoint but not the VIP. Returning from the checkpoint it cannot poll any of the ACE interfaces or VIPS via icmp !!!

It is a major issue, as I have a default route pointing towards the Checkpoint VIP. However as the ACE is unable to ping the cluster IP, it is also unable to inject the static route that has been configured on the ACE.

I am running the latest code, as suggested by Cisco. Any other suggestions, or is it looking like a TAC.

Many thanks,

Jon Humphries

[yushimaz · Accepted solution]

Regarding ACE generated packets to mcast arp, CSCth44891(for module)/CSCth45076 (for appliance) are filed as internally found bug.

CSCth44891 was Closed(C) due to expected behavior(not supported). Currently, CSCth45076 is New(N) state but will be Closed(C).

CSCth44891/CSCth45076 Not able to ping to multicast ARP address from ACE.

ACE can handle multicast arp except for self generated. So, when you configure static arp and default route, it's listed on fib table

as below.

ACE20a/Admin# sh run | i 200

Generating configuration....

ip route 0.0.0.0 0.0.0.0 192.168.71.200

arp 192.168.71.200 01.00.5e.11.11.11

ACE20a/Admin# show ip fib

FIB for Context Admin (RouteId 0)

   Codes: H - host,   I - interface

          S - static,      N - nat

          A - need arp resolve,      E - ecmp

Destination         Interface         EncapId  Flags

------------------------------------------------------------------------

0.0.0.0             vlan771                9   S [0xc]  <<==

ACE20a/Admin#

ACE20a/Admin# sh arp

Context Admin

================================================================================

IP ADDRESS      MAC-ADDRESS        Interface  Type      Encap  NextArp(s) Status

================================================================================

192.168.71.100  00.0b.fc.fe.1b.01  vlan771   VSERVER    LOCAL     _         up

192.168.71.200  01.00.5e.11.11.11  vlan771   GATEWAY    9         _         up <<==

192.168.71.250  00.0b.fc.fe.1b.01  vlan771   ALIAS      LOCAL     _         up

192.168.71.251  00.07.0e.0f.2c.a1  vlan771   INTERFACE  LOCAL     _         up

192.168.72.1    00.23.04.3d.a1.c9  vlan772   LEARNED    6      11652 sec    up

192.168.72.11   00.0c.29.b3.eb.4b  vlan772   RSERVER    4      36 sec       up

192.168.72.12   00.0c.29.e1.d4.dd  vlan772   RSERVER    3      36 sec       up

192.168.72.250  00.0b.fc.fe.1b.01  vlan772   ALIAS      LOCAL     _         up

192.168.72.251  00.07.0e.0f.2c.a1  vlan772   INTERFACE  LOCAL     _         up

192.168.72.254  00.00.6c.69.04.2a  vlan772   RSERVER    8      53 sec       up

192.168.73.251  00.07.0e.0f.2c.a1  vlan773   INTERFACE  LOCAL     _         up

192.168.73.252  00.1f.9e.1a.f4.37  vlan773   LEARNED    5      11573 sec    up

================================================================================

Total arp entries 13

ACE20a/Admin#

I also attached capture trace from server to client with default route.

Since there is no actual client, I can see icmp echo from server to ACE(vlan772) and from ACE to client(vlan771) only.

Regards,

Yuji

[venkatkr · Accepted solution]

HI Vaba,

With CSCsr19346, multicast mac-address was supported with static arp command.  As a part of the fix, only through-the-box traffic scenario was addressed.
i.e, through the box multicast traffic will work fine in routed and bridged flows. 
Multicast traffic originating from the box was NOT handled as a part of this fix. 

As a result, we have a new issue opened
CSCth45076   Not able to ping to multicast ARP address from ACE. However to make this fix, we have to make significant design change. So for now we decided not to implement this solution.

Thanks
VK

[vaba]

Thanks for all,

I am using arp command and now everything works for traffic passing through the ACE (only through-the-box traffic).

Venkatkr,

With my account I cannot see information for this bug (CSCth45076) .

I hope as a change in CSCth45076 status you will post some information

Thanks again

[vaba]

Hi again,

At the moment we are trying to configure ACE4710 by using user authentication with „crypto authgroup”. We have imported root certificate and ACE certificate and everything is working just fine. The problem occurs when we are trying to configurate certificate revocation lists (CRLs) at the time of client authentication. ACE needs to access CA Server through Check Point Firewall cluster. On ACE we configured:

crypto crl CRL_LIST http://CAServer /CertEnroll/ CAServer.crl.

parameter-map type ssl SSL_PARAMETER_MAP

expired-crl reject

ssl-proxy service CLIENT_SSL

  crl CRL_LIST

  ssl advanced-options SSL_PARAMETER_MAP

For the tests we are using telnet 80 created from ACE, by using Check Point Firewall cluster IP address for default gateway. In this case there in no traffic generated from ACE to CA server and ACE cannot access http://CAServer/CertEnroll/ CAServer.crl. When we are using for default gateway on ACE ip address on active Check Point firewall we have access to CA Server on port 80 and telnet 80 is working. In this case we can download CRLs from the server.

Is this the same problem that the described one above by venkatkr, or this is a different one