Hi Vijay,
> On 29 Mar 2020, at 08:42, Chandra Mohan, Vijay Mohan via Lists.Fd.Io
> <vijchand=ciena....@lists.fd.io> wrote:
>
> 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 ?
No, you cannot. In deterministic NAT an inside address block gets statically
assigned to an external address/port block.
That mapping has to be 1:1. Otherwise how would the out2in direction figure out
which inside address block to use?
Best regards,
Ole
>
> 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 (#15932): https://lists.fd.io/g/vpp-dev/message/15932
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]
-=-=-=-=-=-=-=-=-=-=-=-
