Re: Failover route

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,


On Mon, Mar 18, 2019 at 10:57:59AM -0600, Grant Taylor wrote:
> On 3/18/19 8:53 AM, Erik Auerswald wrote:
> 
> >I am referring to the following:
> >
> >--------
> >[...]
> 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.
> [...]
> ># 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).

I was alluding to this part specifically, i.e. tricking the kernel into
sending a packet out an interface although it is addressed to a local
IP address.

> ># 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.

Exactly. In this case two interfaces are used that shall send data to
each other over an external network (a hub), thus source based routing
is used. Source based routing is probably not needed for the BFD-EM idea.

> There is the question of what source IP is used.

In the blog post, the IP of the egress interface was used. As I understand
it, after the kernel determines which interface to send a packet out of,
it determines the "best" IP to use.

I do think that this is quite implementation specific, and I would not
bet that the above behaviour is seen as part of Linux's stable API.

> >--------
> >
> >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

Yes, I'd look into something like this for a BFD-EM implementation.

> I feel like there are other tools that usually fall into the gray /
> black hat camps that can also do this.

Those could be used for a relatively simple proof-of-concept.

> I also wonder if there are some ways to do this with network
> namespaces to avoid some of the routing complexities / hacks above.

I'd expect that using AF_PACKET, SOCK_RAW removes the need for the hacks
used by Project Zero.  They were using e.g. curl instead of writing
their own network application.

Thanks,
Erik
-- 
That's 10 'programmer minutes', i.e. less than a day.
                        -- Russ Cox



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux