Não há um problema de roteamento visível na tabela de roteamento no host que você postou. No entanto, percebo que você está usando um comportamento muito inadequado, pelo qual você define dois gateways que estão em sub-redes nas quais você não tem um endereço, um dos quais você não tem uma rota local, o que me faz pensar algum comportamento indefinido. Eu ficaria curioso em ver o conteúdo das tabelas ARP nos hosts enquanto o ping não está passando.
Acho que vejo o que você está tentando fazer aqui - esse tipo de coisa não é padrão. Parece um pouco inútil tentar forçar o tráfego através de um gateway em uma rede, mas fazê-lo apenas para hosts que estão conectados diretamente em outra sub-rede, embora se você quiser enviar tráfego através de um roteador, a solução correta é provisionar um / 30 sub-rede para cada host.
Se isso falhar, é possível que o gateway esteja fazendo algum tipo de processamento com estado (como m_conntrack, se estiver executando o linux) e esteja severamente desprovisionado, ou você pode estar com perda de pacotes. Alternativamente, o servidor Xen pode estar demorando para descobrir onde os pacotes vão, particularmente se você estiver usando o openvswitch, que tem um comportamento surpreendentemente significativo. Também pode ser necessário que algum tráfego de saída seja enviado antes que o tráfego de entrada possa ser recebido, embora isso seja incomum.
Certamente não é o caso de que o tráfego para a sua rede não-RFC1918 será transmitido pela eth1, se a tabela de roteamento parecer que sim. Não há rota que faria isso. Além disso, lembre-se de que cada host possui uma tabela de roteamento na qual as rotas são associadas às interfaces. Qualquer pacote que esteja precisando de roteamento (basicamente, um de saída) atravessa essa mesma tabela e segue as mesmas regras, correspondendo à rota mais específica, usando a métrica para quebrar os laços.