Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

issue when trying to source nat traffic on the ACE module

Hi, 

I am trying to create a nat setup so that traffic from a machine going through the ace to another machine is natted.
We use the ACE blade in a 6506 chassis

The source machine is in vlan 1144, machine ip 10.151.44.111
The destination machine is in vlan 1159, machine ip 10.151.59.22

I want traffic from 10.151.44.111 source natted to a pool 10.151.59.145 - 10.151.59.147

The ACE has both vlans configured as can be seen below :

This is the config : 

access-list acl_nat_10.151.44.0-10.252.0.0 line 8 extended permit ip 10.151.44.0 255.255.255.0 10.252.0.0 255.255.255.0
access-list acl_nat_10.151.44.0-10.252.0.0 line 10 extended permit ip 10.151.44.0 255.255.255.0 10.151.59.0 255.255.255.0

class-map match-all class_map_nat_10.151.44.0-10.252.0.0

  2 match access-list acl_nat_10.151.44.0-10.252.0.0

policy-map multi-match NAT
  class class_map_nat_10.151.44.0-10.252.0.0
    nat dynamic 2 vlan 1159

interface vlan 1144
  alias 10.151.44.1 255.255.255.0
  service-policy input NAT

interface vlan 1159
  alias 10.151.59.153 255.255.255.0
  nat-pool 2 10.151.59.145 10.151.59.147 netmask 255.255.255.0 pat

Am i missing something or what am i doing wrong, i don't see nat translations being build with the show xlate command.

 

Regards,

Sebastian

Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Hi Sebastian,It works as

Hi Sebastian,

It works as first match and if the condition is satisfied, no further rules are checked.

class-map match-all TST-BL-REALSERVERS
  2 match source-address 10.151.44.0 255.255.255.0

class-map match-all class_map_nat_10.151.44.0-10.252.0.0
  2 match access-list acl_nat_10.151.44.0-10.252.0.0

In one condition source is defined and in other condition source and destination is defined. When packet hits ace, and let us say this class "TST-BL-REALSERVERS" condition is met, since source is same and since condition is satisfied , we won't go further. We will then go to different multi-match and do the NAT as suggested. So yes the order matters.

Here's a beautiful example of how matching works.

 

The term "multi-match" refers to execution semantics of the policy; In other
words it depicts how the actions are executed for a given flow that matches
the classifications in the policy.

The policy has multi-match semantics because the policy allows configuring
multiple types of features like loadbalancing, NAT inspect etc; so potentially
this policy can result in taking multiple actions (if multiple features are
configured) for a given matching flow.

Now given that there can be multiple classifications configured for the same
feature type within the policy, the rule is that we always execute *only* the
first matching action for a given feature type;

for .eg consider the below;; just for brevity I am ommiting the exact syntax
of the cmds

--------------------
policy-map multi-match MYPOLICY
  class LB1
    loadbalance policy L7-1
    loadbalance vip inservice
  class NAT1
    nat dynamic 100 vlan 20
  class INSP1
    inspect http
  class LB2
    loadbalance policy L7-2
    loadbalance vip inservice
  class NAT2
    nat dynamic 200 vlan 30

interface vlan 10
   service-policy input MYPOLICY
-------------------

please note above that there are 2 classes each with features loadbalance and
NAT configured and one class with inspect action;

For an incoming flow, we try to match and *execute* *ONLY* the action specified
against first matching class per feature. In otherwords, if flow matches class
LB1 then we will execute "loadbalance action L7-1" and we wont even try to see
if class LB2 matches as it is of the same feature type. Only if class LB1 does
not match we look at LB2.  However we continue matching other class'es since
they have different feature types;

This happens for each feature type; Essentially between the class-maps of same
feature type think of this as first-match and across features its multiple match.

potentially for above policy the flow can match the below possible classes:
LB1, NAT1, INSP1
LB2, NAT1, INSP1
LB2, NAT2, INSP1
LB1, NAT2, INSP1

but the below is not possible;
LB1, LB2, NAT1, INSP1
LB2, NAT1, NAT2, INSP1

you can visualize the above multi-match policy like below; (pls note that below
syntax is not supported and is strictly for illustration purposes only) below has
policy types per FEATURE and each such policy can result in ONLY ONE match/action
being executed;

-------------
policy-map type SLB first-match LBPOLICY
  class LB1
    loadbalance policy L7-1
    loadbalance vip inservice
  class LB2
    loadbalance policy L7-2
    loadbalance vip inservice

policy-map type NAT first-match NATPOLICY
  class NAT1
    nat dynamic 100 vlan 20
  class NAT2
    nat dynamic 200 vlan 30

policy-map type inspect first-match INSPECTPOLICY
  class INSP1
    inspect http

interface vlan 10
   service-policy input LBPOLICY
   service-policy input NATPOLICY
   service-policy input INSPECTPOLICY
-------------

Regards,

Kanwal

NOTE: Please mark if it was helpful.

 

 

 

5 REPLIES
Cisco Employee

Hi Sebastian,The

Hi Sebastian,

The configuration looks fine. I see no access-group applied on interface vlan 1144 though. Could you please apply the access group and check again. When traffic HITS ace, access-list is checked and if it is allowed, it moves on to the other conditions.

Hope this helps.

Regards,

Kanwal

Note: Please mark the answers if they help.

New Member

Hi Kanwal, Vlan 1144 does

Hi Kanwal, 

Vlan 1144 does have an access-list applied, and i do see traffic at 10.151.59.22 when i use wireshark.

However, the traffic arriving at 10.151.59.22 is not natted as it has ip address 10.151.44.111 instead of having an ip address from the nat pool 10.151.59.145 10.151.59.147.

regards, 

Sebastian

New Member

I've been able to get it work

I've been able to get it work by removing the other service policy's and re-applying them.

This results in a different service policy order.

I think it is because realservers hitting their vip are source natted and appearently then no other nat rule is hit ? Can anyone confirm/explain this  ?

I've included a piece of the config, nat pool 1 is used for realservers hitting their own vip, nat pool 2 is to source nat outgoing connections.

access-list acl_nat_10.151.44.0-10.252.0.0 line 8 extended permit ip 10.151.44.0 255.255.255.0 10.252.0.0 255.255.255.0
access-list acl_nat_10.151.44.0-10.252.0.0 line 10 extended permit ip 10.151.44.0 255.255.255.0 10.151.59.0 255.255.255.0


serverfarm host TST-BL-FARM
  failaction purge
  predictor leastconns slowstart 30
  probe ICMP-PROBE
  rserver TST-BL01V.VEC.OTA.INFRA.LOCAL
    inservice
  rserver TST-BL02V.VEC.OTA.INFRA.LOCAL
    inservice

class-map match-all TST-BL-REALSERVERS
  2 match source-address 10.151.44.0 255.255.255.0

class-map match-all class_map_nat_10.151.44.0-10.252.0.0
  2 match access-list acl_nat_10.151.44.0-10.252.0.0

policy-map type loadbalance first-match TST-BL-FARM-BALANCE
  class class-default
    serverfarm TST-BL-FARM
    insert-http X-Forwarded-For header-value "%is"

policy-map multi-match TargetX_NAT
  class class_map_nat_10.151.44.0-10.252.0.0
    nat dynamic 2 vlan 1159

policy-map multi-match TST-BL-LOADBALANCING
  class TST-BL-VIP
    loadbalance vip inservice
    loadbalance policy TST-BL-FARM-BALANCE
  class TST-BL-REALSERVERS
    nat dynamic 1 vlan 1144


interface vlan 1144
  alias 10.151.44.1 255.255.255.0
  nat-pool 1 10.151.44.30 10.151.44.34 netmask 255.255.255.0 pat
  service-policy input TargetX_NAT
  service-policy input TST-BL-LOADBALANCING

interface vlan 1159
  alias 10.151.59.153 255.255.255.0
  access-group input DB-1159-OTA-TargetX-IN
  nat-pool 2 10.151.59.145 10.151.59.147 netmask 255.255.255.0 pat 

 

Cisco Employee

Hi Sebastian,It works as

Hi Sebastian,

It works as first match and if the condition is satisfied, no further rules are checked.

class-map match-all TST-BL-REALSERVERS
  2 match source-address 10.151.44.0 255.255.255.0

class-map match-all class_map_nat_10.151.44.0-10.252.0.0
  2 match access-list acl_nat_10.151.44.0-10.252.0.0

In one condition source is defined and in other condition source and destination is defined. When packet hits ace, and let us say this class "TST-BL-REALSERVERS" condition is met, since source is same and since condition is satisfied , we won't go further. We will then go to different multi-match and do the NAT as suggested. So yes the order matters.

Here's a beautiful example of how matching works.

 

The term "multi-match" refers to execution semantics of the policy; In other
words it depicts how the actions are executed for a given flow that matches
the classifications in the policy.

The policy has multi-match semantics because the policy allows configuring
multiple types of features like loadbalancing, NAT inspect etc; so potentially
this policy can result in taking multiple actions (if multiple features are
configured) for a given matching flow.

Now given that there can be multiple classifications configured for the same
feature type within the policy, the rule is that we always execute *only* the
first matching action for a given feature type;

for .eg consider the below;; just for brevity I am ommiting the exact syntax
of the cmds

--------------------
policy-map multi-match MYPOLICY
  class LB1
    loadbalance policy L7-1
    loadbalance vip inservice
  class NAT1
    nat dynamic 100 vlan 20
  class INSP1
    inspect http
  class LB2
    loadbalance policy L7-2
    loadbalance vip inservice
  class NAT2
    nat dynamic 200 vlan 30

interface vlan 10
   service-policy input MYPOLICY
-------------------

please note above that there are 2 classes each with features loadbalance and
NAT configured and one class with inspect action;

For an incoming flow, we try to match and *execute* *ONLY* the action specified
against first matching class per feature. In otherwords, if flow matches class
LB1 then we will execute "loadbalance action L7-1" and we wont even try to see
if class LB2 matches as it is of the same feature type. Only if class LB1 does
not match we look at LB2.  However we continue matching other class'es since
they have different feature types;

This happens for each feature type; Essentially between the class-maps of same
feature type think of this as first-match and across features its multiple match.

potentially for above policy the flow can match the below possible classes:
LB1, NAT1, INSP1
LB2, NAT1, INSP1
LB2, NAT2, INSP1
LB1, NAT2, INSP1

but the below is not possible;
LB1, LB2, NAT1, INSP1
LB2, NAT1, NAT2, INSP1

you can visualize the above multi-match policy like below; (pls note that below
syntax is not supported and is strictly for illustration purposes only) below has
policy types per FEATURE and each such policy can result in ONLY ONE match/action
being executed;

-------------
policy-map type SLB first-match LBPOLICY
  class LB1
    loadbalance policy L7-1
    loadbalance vip inservice
  class LB2
    loadbalance policy L7-2
    loadbalance vip inservice

policy-map type NAT first-match NATPOLICY
  class NAT1
    nat dynamic 100 vlan 20
  class NAT2
    nat dynamic 200 vlan 30

policy-map type inspect first-match INSPECTPOLICY
  class INSP1
    inspect http

interface vlan 10
   service-policy input LBPOLICY
   service-policy input NATPOLICY
   service-policy input INSPECTPOLICY
-------------

Regards,

Kanwal

NOTE: Please mark if it was helpful.

 

 

 

New Member

Hi Kanwal, That cleared it up

Hi Kanwal, 

That cleared it up ! Tnx !

49
Views
0
Helpful
5
Replies