Printer FriendlyEmail Article Link

TestCenter: How do I manually set up to test streamblocks through a Network Address Translation (NAT) and Port Address Translation (PAT) device?

Answer

I provide a simple example for NAT/PAT and PAT as a suggestion how you might implement this using those two hosts. 

I mention you can try to create raw streams - All you need to do is point one stream on one port to the Nat'ed address, then on the other port point (using IP addressing) the other to the other side of the Nat.
 
NAT/PAT

Private Side                                           Public side

Host 1.1.1.2 -> {NAT Gateway 1.1.1.1 <-> NAT Gateway 20.2.1.1} ------------>Host 20.2.1.3

SB1
-> Source 1.1.1.2
-> Dest 20.2.1.3
-> Gateway 1.1.1.1

SB2
-> Source 20.2.1.3
-> Dest 20.2.1.1
-> Gateway 20.2.1.1

NAT

Private Side                                           Public Side

Host 1.1.1.2 -> {NAT Gateway 1.1.1.1 <-> NAT Gateway 20.2.1.1} -> Host 20.2.1.2------------>Host 20.2.1.3

SB1
-> Source 1.1.1.2
-> Dest 20.2.1.3
-> Gateway 1.1.1.1

SB2
-> Source 20.2.1.3
-> Dest 20.2.1.2
-> Gateway 20.2.1.1
 

Ensure to click the control plane streamblock box.
 
Verify receipt of the streamblock.
 
If you search the HELP for NAPT I believe this explains:
 
Raw Stream Block
Manually create raw stream blocks on an individual port by editing traffic parameters.
When defining a raw stream block, you specify header information, such as source/destination addresses, at the time you configure the stream block instead of associating the block with a device.
Use raw stream blocks when the test is focused specifically on traffic and does not include device behaviour, such as testing protocols (access, routing, multicast, etc.).
Why use a raw stream block?
While bound stream blocks are very efficient for many applications, there are some situations that require raw stream blocks.
Network address/port translation (NAPT). Private Devices <-> DUT <-> Public Devices
In this scenario, the private devices are configured with private IP addresses and the public devices with public IP addresses. If a bound stream block is used, packets going out (private to public) will have a private source address and a public destination address, as they should. However, packets going the other way (public to private) will have a public source address (good) and a private destination address (not good). The destination address should be a public address and the DUT does the translation.
Proprietary implementations. In cases where a DUT uses a proprietary scheme when building the PDU, use a raw stream block to build the frame.
Negative testing. To test the ability of a DUT to handle a mal-formed PDU, use a raw stream block.
Scalability limits. If your requirement exceeds the scalability limits of a bound stream block (as documented in the release notes), you may be able to use a raw stream block to get past the limitation.
 
CAVEAT:
 
If one experience no streamblock results for UDP packets through PAT and less than 66 byte packets and receiving the packets at port level results.
 
I explain the udp packets are adjusted by Spirent to transmit at 64 bytes (less than 66) by sharing (overlap) two bytes of the udp header checksum with the Spirent signature. When the PAT device changes the udp header and checksum, the Spirent signature is altered and subsequently not recognized as the expected packet.
 
 

Product : Data Center,Spirent TestCenter