Today I Learned
I am subscribed to Cloudflare blog as they are in general really good. And definitely, you always learn something new (and want to cry because you have so much to learn from these guys).
This time was a dissection of conntrack in iptables to improve their firewall performance.
https://blog.cloudflare.com/conntrack-tales-one-thousand-and-one-flows
I never thought about the limits of the conntrack table and how important is to have in mind (or make a tattoo of) the iptables diagram:
At work, we use a vendor whose Network Operating System (NOS) is based in Linux. I am a network engineer so I was troubleshooting an issue inside a VRF. I couldn’t use much of the normal commands in the default VRF. So I opened a ticket with the vendor and learned a bit how the VRFs are implemented under the hoods. Obviously (not for me) they use Linux Namespaces, after googling the meaning of the commands they sent. My search brought me to the following links:
This is a good intro:
https://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/
From this link, I took some examples in my quick search
https://kashyapc.fedorapeople.org/virt/openstack/neutron/neutron-diagnostics.txt
At the end I used commands like these:
$ sudo ip netns list $ sudo ip netns exec ns-INET ip link list $ sudo ip netns exec ns-VRF1 arp -a $ sudo ip netns exec ns-VRF1 route -n $ sudo ip netns exec ns-VRF1 telnet -b src_ip dst_ip port $ sudo ip netns exec ns-VRF1 tcpdump -i lo4 -nn tcp 179 $ sudo ip netns exec ns-VRF1 ss --tcp --info $ sudo ip netns exec ns-VRF1 ss --tcp --info -nt src IP
As well, “ss” is such a useful command for troubleshooting and I always feel that I dont make the most of it:
