On 3/18/19 8:53 AM, Erik Auerswald wrote:
Hi,
Hi,
I am referring to the following: --------In this case, I want the simulated network on 192.168.2.0/24 and the management interface on 192.168.1.1/24. This requires adjusting the local routing table and creating device specific rules accordingly.
I'm not following what you're wanting to do, why you're wanting to do it, and how it's related to the thread. — There's apparently too much blood in my caffeine stream to grok this properly.
# First, make sure Linux will accept local<->hub<->local traffic echo 1 > /proc/sys/net/ipv4/conf/all/accept_local
This is new to me. It looks like accept_local is a knob to disable basic sanity checks.I can't articulate what the sanity checks are and why it's good that they're there in the first place.
#https://i.etsystatic.com/5918013/r/il/48c7e5/289046102/il_794xN.289046102.jpg
# Give the two interfaces connected to the hub static addresses. ip addr add 192.168.2.2 dev eth2 ip addr add 192.168.2.1 dev eth3
Okay.(I've not tested to find out.) What netmask do these IPs get? /24 since they are in the class c address range?
# Route traffic destined for each address to the *opposite* device ip route add 192.168.2.1 dev eth2 ip route add 192.168.2.2 dev eth3
Okay.These are device routes that get added to the main routing table (ID 32766). They state that the destination IPs are available out the devices.
# Force Linux to forget that these are local interfaces so the traffic actually reaches the hub. ip route del 192.168.2.2 table local ip route del 192.168.2.1 table local
Removing the (local) routes from the local routing table (ID 0).
# Now add corresponding rules for each interface ip rule add iif eth2 lookup 100 ip route add local 192.168.2.2 dev eth2 table 100 ip rule add iif eth3 lookup 101 ip route add local 192.168.2.1 dev eth3 table 101
(Re)adding the (local) routes that were removed from the local table to tables 100 and 101 (respectively) and adding ip rules (PBR) to choose the routing tables based on the incoming interface.
If I'm tracking properly, the system will effectively not realize that 192.168.2.2 and 192.168.2.1 are local because the ip rules won't search tables 100 or 101. But it will have (device) routes to them, thus it will be able to send traffic to them.
There is the question of what source IP is used.
--------Yes, if you craft a packet accordingly. But what does the TCP/IP stack do if you send a packet to a local IP address? The BFD Echo packet is addressed to the local IP of the sending interface.
I think, by default, the kernel will try loop internally.
The question is how to create a packet with the local IP and the remote MAC address, and send it out the local interface.One way is editing a PCAP file with a hex editor and using tcpreplay to send the PCAP data as a packet. ;-)
I feel like there are some tools that can be used to create and send custom Ethernet frames.
A quick web search renders this: http://www.microhowto.info/howto/send_an_arbitrary_ethernet_frame_using_an_af_packet_socket_in_c.html
I feel like there are other tools that usually fall into the gray / black hat camps that can also do this.
I also wonder if there are some ways to do this with network namespaces to avoid some of the routing complexities / hacks above.
Thanks,
You're welcome. Now to go find some much needed caffeine. -- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
