re-trigger EMU ARP

[Andreas Bourges]

Hi,

...in the customers production network TRex is used to monitor traffic flows between sites and different vrfs. In the production network, we have quite strict control-plane policing in place, which leads to EMU not being able to resolve all gateway IPs all the time. Sometimes we would need to perform the ARP queries a second time for some of the emu clients.

How could I re-trigger ARP for those gateway IPs that couldn't be resolved? 

Thanks,

Andreas

[hanoh haim]

Hi Andreas,

Could you be more specific what is the DG router and what is the issue? Every client sends the query and garp at startup. On the first client response all the clients with the same DG get the right DG value. 

In case there is no answer, the designator client will keep sending the request in this time in seconds (not all the clients send query and response) 

the table of ARP is shared by namespace. maybe this make the switch confused

var defaultRetryTimerSec = [...]uint8{1, 1, 1, 1, 3, 5, 7, 17}

Thanks

Hanoh

[Andreas Bourges]

Hi Hanoh,

...ok, now I understand.The problem is probably, that I take a look at the resolved gateway IP only one time, just after the emu profile was instantiated. If I understand correctly, I should wait for a few seconds and have a look the the ARP result again to see if everything got resolved? I'm probably just too fast looking at the resolved gateway IPs.

Thanks,

Andreas

[hanoh haim]

Hi Andreas, 

Maybe I wasn't clear. let's take an example. 

If you have 255 clients with the same DG. All of them will send a query and garp but only the first one will be the owner of the retransmission object in case there is no answer (we call it designator) 

All of the other client (244) will have a reference to the same request object. Once the first will get the response all of the other clients are not waiting for the response, they will start working with the first client DG MAC and will ignore the response. In case of query from the router each will answer 

Thanks

Hanoh

[Andreas Bourges]

Hi Hanoh,

...yes - I think I understood your explanation. But if I have clients in multiple subnets/namespaces and the default-gw of the first subnet is resolved, it could be that the second one is (for whatever reason) not resolved, yet. But as far as I undestand now, the EMU is still trying to resolve the default-gw in the background. If I recognize i my script that the default-gws are not resolved for all subnets, I could still wait some seconds and have a look at the emu, if the remaining default gws were resolved in the meantime, right?

Thanks,

Andreas

[hanoh haim]

Correct. Every namespace has its own context and you should wait for all. You can query the ns.

Thanks

Hanoh 

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/f1fb64f5-33be-4d50-a812-ca74114553c7n%40googlegroups.com.

--

Hanoh

Sent from my iPhone

[Andreas Bourges]

hi Hanoh,

...sorry, but I cannot find a method to query the ns ? Or do you refer to " get_fields()" ?

Thanks,

Andreas

[Besart Dollma]

Hi Andreas, 

Look at this example for ARP. https://github.com/cisco-system-traffic-generator/trex-core/blob/master/scripts/automation/trex_control_plane/interactive/trex/examples/emu/emu_arp.py

You can get the counters, and when you have a resolved counter, you will know that your ARP is resolved.

Another option is to query the client and see its Default Gateway.

Let me know if that helps.

Thanks,

[Andreas Bourges]

Hi Bes,

...yes - currently I'm using your 2nd suggestion, but I think the first one makes more sense :-)

Thanks a lot!

Andreas