Hello,
Looking to understand the behavior of NAT in deterministic mode. The issue is,
while in2out translations work fine and sessions are being created
successfully, frames are getting dropped in out2in direction though a session
is present for translation. Following are configurations :
DBGvpp# show interface address
GigabitEthernet5/0/0 (up):
L3 20.20.20.15/24
GigabitEthernet5/0/1 (up):
L3 10.10.10.15/24
TenGigabitEthernet3/0/0 (dn):
TenGigabitEthernet3/0/1 (up):
L3 40.40.40.15/24
local0 (dn):
DBGvpp# show nat44 interfaces
NAT44 interfaces:
GigabitEthernet5/0/0 in
GigabitEthernet5/0/1 out
TenGigabitEthernet3/0/1 in
DBGvpp# show nat44 deterministic mappings
NAT44 deterministic mappings:
in 20.20.20.2/32 out 10.10.10.15/32
outside address sharing ratio: 1
number of ports per inside host: 64512
sessions number: 0
in 40.40.40.2/32 out 10.10.10.15/32
outside address sharing ratio: 1
number of ports per inside host: 64512
sessions number: 0
in2out works fine for both the mappings. Here are the created sessions:
DBGvpp# show nat44 deterministic sessions
NAT44 deterministic sessions:
in 20.20.20.2:700 out 10.10.10.15:1724 external host 10.10.10.2:600 state:
udp-active expire: 13344
in 40.40.40.2:800 out 10.10.10.15:1824 external host 10.10.10.2:600 state:
udp-active expire: 13368
In the out2in direction, frame with dst-port : 1724 gets successfully NAT’ed
but the frame with dst-port : 1824 gets dropped with error “No translation”
when there is a session already present (second session above). Is this an
expected behavior with deterministic NAT ? Can we map multiple
internal-src-ip-addresses to one external-src-ip-address ?
It looks like, from the code, only the first mapping entry is being matched all
the time when the external-src-ip-address is same for the configured mapping
entries above.
always_inline snat_det_map_t *
snat_det_map_by_out (snat_main_t * sm, ip4_address_t * out_addr)
{
snat_det_map_t *dm;
/* *INDENT-OFF* */
pool_foreach (dm, sm->det_maps,
({
if (is_addr_in_net(out_addr, &dm->out_addr, dm->out_plen))
return dm;
}));
/* *INDENT-ON* */
return 0;
}
The above function is called from snat_det_out2in_node. Only the out_addr is
being checked while looking for the matching mapping entry. This may result in
the first added mapping entry to be matched all the time in the case where
dm->out_addr is same for both the mapping entries, right ? Looks like we need
more checks to identify the session correctly.
Here is the node trace for out2in processing:
Packet 3
03:09:18:893987: dpdk-input
GigabitEthernet5/0/1 rx queue 0
buffer 0x9b3a8: current data 0, length 508, buffer-pool 0, ref-count 1,
totlen-nifb 0, trace handle 0x2
ext-hdr-valid
l4-cksum-computed l4-cksum-correct
PKT MBUF: port 3, nb_segs 1, pkt_len 508
buf_len 2176, data_len 508, ol_flags 0x180, data_off 128, phys_addr
0x26cea80
packet_type 0x211 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
RTE_PTYPE_L4_UDP (0x0200) UDP packet
IP4: 00:00:00:1a:9a:7e -> 0c:c4:7a:c2:f6:f5
UDP: 10.10.10.2 -> 10.10.10.15
tos 0x00, ttl 64, length 494, checksum 0x50db
fragment id 0x0000
UDP: 600 -> 1724
length 474, checksum 0x3786
03:09:18:894003: ethernet-input
frame: flags 0x3, hw-if-index 4, sw-if-index 4
IP4: 00:00:00:1a:9a:7e -> 0c:c4:7a:c2:f6:f5
03:09:18:894016: ip4-input-no-checksum
UDP: 10.10.10.2 -> 10.10.10.15
tos 0x00, ttl 64, length 494, checksum 0x50db
fragment id 0x0000
UDP: 600 -> 1724
length 474, checksum 0x3786
03:09:18:894023: nat44-det-out2in
NAT_DET_OUT2IN: sw_if_index 4, next index 1, session index 0
03:09:22:826468: ip4-lookup
fib 0 dpo-idx 3 flow hash: 0x00000000
UDP: 10.10.10.2 -> 20.20.20.2
tos 0x00, ttl 64, length 494, checksum 0x3cde
fragment id 0x0000
UDP: 600 -> 700
length 474, checksum 0x0000
03:09:22:826487: ip4-rewrite
tx_sw_if_index 3 dpo-idx 3 : ipv4 via 20.20.20.2 GigabitEthernet5/0/0:
mtu:9000 0000001a9a7c0cc47ac2f6f40800 flow hash: 0x00000000
00000000: 0000001a9a7c0cc47ac2f6f40800450001ee000000003f113dde0a0a0a021414
00000020: 1402025802bc01da0000000102030405060708090a0b0c0d0e0f1011
03:09:22:826497: GigabitEthernet5/0/0-output
GigabitEthernet5/0/0 l4-cksum-computed l4-cksum-correct l2_hdr_offset_valid
l3_hdr_offset_valid
IP4: 0c:c4:7a:c2:f6:f4 -> 00:00:00:1a:9a:7c
UDP: 10.10.10.2 -> 20.20.20.2
tos 0x00, ttl 63, length 494, checksum 0x3dde
fragment id 0x0000
UDP: 600 -> 700
length 474, checksum 0x0000
03:09:22:826520: GigabitEthernet5/0/0-tx
GigabitEthernet5/0/0 tx queue 0
buffer 0x9b3a8: current data 0, length 508, buffer-pool 0, ref-count 1,
totlen-nifb 0, trace handle 0x2
ext-hdr-valid
l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
l3-hdr-offset 14
PKT MBUF: port 3, nb_segs 1, pkt_len 508
buf_len 2176, data_len 508, ol_flags 0x180, data_off 128, phys_addr
0x26cea80
packet_type 0x211 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
RTE_PTYPE_L4_UDP (0x0200) UDP packet
IP4: 0c:c4:7a:c2:f6:f4 -> 00:00:00:1a:9a:7c
UDP: 10.10.10.2 -> 20.20.20.2
tos 0x00, ttl 63, length 494, checksum 0x3dde
fragment id 0x0000
UDP: 600 -> 700
length 474, checksum 0x0000
Packet 4
03:09:31:598786: dpdk-input
GigabitEthernet5/0/1 rx queue 0
buffer 0x9b381: current data 0, length 508, buffer-pool 0, ref-count 1,
totlen-nifb 0, trace handle 0x3
ext-hdr-valid
l4-cksum-computed l4-cksum-correct
PKT MBUF: port 3, nb_segs 1, pkt_len 508
buf_len 2176, data_len 508, ol_flags 0x180, data_off 128, phys_addr
0x26ce0c0
packet_type 0x211 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
RTE_PTYPE_L4_UDP (0x0200) UDP packet
IP4: 00:00:00:1a:9a:7e -> 0c:c4:7a:c2:f6:f5
UDP: 10.10.10.2 -> 10.10.10.15
tos 0x00, ttl 64, length 494, checksum 0x50db
fragment id 0x0000
UDP: 600 -> 1824
length 474, checksum 0x3722
03:09:31:598804: ethernet-input
frame: flags 0x3, hw-if-index 4, sw-if-index 4
IP4: 00:00:00:1a:9a:7e -> 0c:c4:7a:c2:f6:f5
03:09:31:598815: ip4-input-no-checksum
UDP: 10.10.10.2 -> 10.10.10.15
tos 0x00, ttl 64, length 494, checksum 0x50db
fragment id 0x0000
UDP: 600 -> 1824
length 474, checksum 0x3722
03:09:31:598822: nat44-det-out2in
NAT_DET_OUT2IN: sw_if_index 4, next index 0, session index -1
03:09:35:076675: error-drop
rx:GigabitEthernet5/0/1
03:09:35:076687: drop
nat44-det-out2in: No translation
Thanks,
Vijay
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15919): https://lists.fd.io/g/vpp-dev/message/15919
Mute This Topic: https://lists.fd.io/mt/72625921/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
