Moving past TCP in the data center, part 1
Moving past TCP in the data center, part 1
Posted Nov 23, 2022 23:43 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)In reply to: Moving past TCP in the data center, part 1 by Rudd-O
Parent article: Moving past TCP in the data center, part 1
You maybe can mirror one port to another, but in an Amazon DC this means nothing. You'll just confuse some random EC2 hardware instance. You won't even be able to do much if you redirect the traffic to an instance that you control, because it's encrypted.
Posted Nov 24, 2022 9:54 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Except the L3 switch ASIC can be programmed to redirect only certain flows to said CPU. They can also be programmed to encap and redirect certain flows to other hosts. Indeed, they can be programmed to mirror packets (but I can't remember if the L3 ASICs commonly used at the super-large DCs can /both/ mirror and encap the same flow - if not, it's just a matter of time till they do).
So:
1. You don't need to analyse the entire data flow on the puny switch CPU, cause the /powerful/ switching ASIC can be programmed to do hardware tcpdumping (basically). Given the CPUs on these switches aren't /that/ puny (low to mid end Xeons), further analysis on host is quite feasible.
Posted Nov 24, 2022 9:56 UTC (Thu)
by paulj (subscriber, #341)
[Link]
I note this is a good counter-argument to your own argument in another sub-thread that intra-DC traffic doesn't need to be encrypted. ;)
Moving past TCP in the data center, part 1
2. Even better, you can just redirect the flow you're interested in to a bigger server by encapping it (the server can resend the flow's packets out again so they're not missed).
Moving past TCP in the data center, part 1