TD;LR Make QFX10002 as l2 "core switch" - the most correct solution to the problem.
Whole problem is asymmetric routing.
By design: traffic goes from the Internet (this is one of the non-main ways) through mx480-2 (where host 2.2.2.2 is "connected" - He’s somewhere on the Internet, this is not a direct connection)
2.2.2.2 -> .... hop (s) .. -> mx480- 1.1.1.10 -> l2 -> QFX10002 -> EX4550 -> host 1.1.1.1
But to 2.2.2.2 traffic going 1.1.1.1 -> EX4550 -> 1.1.1.2 (MX480-1) (and here, depending on the routing table) or to -> internet .. 2.2.2.2 or to via -> another l2 path -> 1.1.1.100 -> internet
In any case, this traffic path from Mx480-1 dont send any eth packet with src mac 11:11:11:11:11 (host 1.1.1.1).
I did not explain in the before scheme that both routers are connected by ibgp.
In fact, the architectural problem is that the QFX10002 should be a l2 "core switch" correctly.
If the upward and downward movement of traffic went through it, then the described problem would not exist.
But, for historical reasons, primarily because of the complexity of performing work in the data center, a situation has turned out when the network scheme has been in the process of being reworked.
What is the essence of the problem: traffic comes in one way, but comes back in another.
The table arp lifetime in MX480-2 does not match the mac address table lifetime in QFX10002.
As a result, QFX10002 has no information in the mac table (it has nowhere to come from - because arp requests are rare (l2 packet with mac 11:11:11:11:11:11 from 1.1.1.1), and there is no constant traffic from 1.1.1.1 through QFX10002)
On the other hand, there is constant traffic 2.2.2.2 -> ... -> 1.1.1.10 -> QFX10002 -> EX4550 -> 1.1.1.1 exist.
In result: all constant traffic from 1.1.1.10 copy to all l2 interfaces QFX10002.
Accordingly, we need to either update setup the arp table ttl on mx480-2 very often so that arp requests are constantly present.
Then these requests (and answers) will cause QFX10002 to learn that mac 11: 11: 11: 11: 11 from behind EX4550.
Or, on the contrary, the ttl of the mac address table would be so long that once having learned it, we would not be worried that it would disappear from the table.
So I see the solution. With standard scheme "learning mac".
Why am I talking about "copy" (I dont know protocol or method for it) the mac address table from EX4550 to QFX10002.
This would allow us not to depend on arp requests from 1.1.1.10.