default gateway usage in ASTF mode.

[Jon]

Hello, 

Can anyone tell me if using ASTF mode the traffic for the Clients and servers (by default set to 16.x.x.x and 48.x.x.x) are actually pointed towards the gateway that is specified during the MAC resolution process?

Meaning, the traffic is directed from the TREX IP specified in the config (default 11.11.11.2) to the Gateway (default 11.11.11.1) in the config and the source and destination are not in the 16.x and 48.x address range?

if so, what is the purpose of having the source and destination IP's in ASTF if the traffic has its own IP ranges?

Curious! 

Thanks!

[Besart Dollma]

- The TRex IP specified in the config file is for control messages (ARP) for example. When you have a DUT connected to TRex, that DUT expects the MAC address in the frame to be the correct MAC.

- The generated traffic will have the addresses (16.x.x.x and 48.x.x.x) and as such if you have a DUT you are responsible to make sure the traffic is routed between the interfaces.

[Jon]

Hi, Ok understood. 

we are trying to loopback traffic at a distant L3 switch over an MPLS network.   So we created to L3 routes and all devices are pingable. 

TREX can do the ARP to the gateway IP's but of course the MAC shown is the local MAC of the switch directly connected. 

My understanding now is:   the traffic source and destination IP's do not go towards the IP specified in the config, the gateway.   The client and server traffic only contain source and destination addresses that are configured. They are not pointed towards the "default gateway" in the configuration. 

is this correct?

Thank you very much for the reply!

Jon

[Besart Dollma]

I am not sure I understood your question: 

The egress packets that ASTF generates when you start a profile:

Src MAC: TRex interface 

Dst MAC: Resolved by ARP (closer switch in this case)

Src IP: 16.x.x.x 

Dst IP : 48.x.x.x 

I like to call these data packets.

Control packets are packets that are sent by ARP or ICMP (ping)

Src MAC: TRex Interface

Dst MAC: Broadcast or resolved by ARP

Src Ip: 11.x.x.x or whatever you have configured in your trex_cfg.yaml (can be seen in portattr -a in console)

Dst IP: Configured or whatever you put in ICMP.

[Jon]

Hi Ok, 

So we were under the impression or understanding that the Gateway in the Trex_cfg.yaml is meant to be on the DUT, and that the Egress packets 16.x and 48.x are sent to this gateway.

We created a route to this Gateway, we are generating traffic accross a newly installed submarine fiber.. the gateway on the DUT is at a switch on the far end. 

That gateway is pingable from the switch that the TREX is directly connected to, and the TREX will ARP this interface at the switch.

We can get traffic to hit the Null interface at the far end but it will not route back, so it is saturating the connection, but TREX shows the traffic as dropped. 

our route on the L3 switch looks like this:

Interface 11.11.11.1  Control traffic gw

Interface 12.12.12.1  Control traffic gw

48.0.0.0 255.255.0.0 12.12.12.2   control traffic destination IP 

16.0.0.0 255.255.255.0 11.11.11.2  control traffic destination IP

we are using ASTF mode, and we modified the sfr_full_2k.py with the corresponding subnets, since we are not exactly using the 48.x.x.x and 16.x.x.x subnets in reality.

In short we thought the egress Traffic is using the Control traffic gateway on the switch to send the traffic back to the other Trex control traffic IP that sits on the TREX port.

what im hearing is.. after the control traffic ARP happens, the Egress packets (generated traffic) has nothing at all to do with the control traffic IP range.

Regards,

Jon

[Besart Dollma]

True, 

You need to route all the 48.0.0.0/8 to the server port and 16.0.0.0/8 to the client port.
Thanks,

[Jon]

if we are talking about routing to a port that's Layer 2 right.

There are no interfaces that answer pings in the traffic generator subnet so OSPF wont route to the TREX to those addresses. 

You need to have an IP on the interface closest to the TREX I guess.

Its still not clear to me what the best way to do this strictly Layer 3. For now we can fill the entire link with traffic but it all gets dropped. We can tune our QoS using this, but it would be nice to be able to have L3 source IP's on the Trex.

Jon

[Besart Dollma]

I really don't understand what the problem is. Can you please try to be more precise?

In the first L3 hop for TRex (router) add a static route for 16.0.0.0/8 to redirect to TRex. Then you can redistribute these routes using OSPF. OSPF doesn't route based on ping.

If you want TRex to emulate real hosts that answer ARP/PING etc, you are looking at the wrong mode. We have TRex-EMU for that.

Thanks