Hi Ole,
Thanks for pointers for IPv6.
"Are you saying that the following works in Linux:"
[Bindiya] : Yes .Little change to your configuration below
192.0.2.1/24 -> Eth0
192.0.2.2/24 -> *Eth0.111*(vlan interface on eth0)
Or are you saying that Linux ignores the second entry and just uses the
first entry in the FIB?
[Bindiya ] : in this config yes , ping to destination IP 192.0.2.10(VLAN)
will go on plain interface (ARP resolved on plain interface)
In VPP arp will be generated on VLAN interface
What then happens with the 192.0.2.2 address?
[Bindiya ] : wrt Linux 192.0.2.2 it will be ignored
wrt VPP it will use vlan interface.
workaround will be to add static route.
As suggested earlier this seems to be invalid scenario. Thanks for the help
.
Regards,
Bindiya
-----------------------------------
Are you saying that the following works in Linux:
192.0.2.1/24 -> Eth0
192.0.2.2/24 -> Eth1
Where Eth0 and Eth1 are connected to the same L2.
Or are you saying that Linux ignores the second entry and just uses the
first entry in the FIB?
What then happens with the 192.0.2.2 address?
Below is the configuration that test case was doing:
.
13.0.0.200 -------------------------------|GigabitEthernet1/0/0 (plain
interface)13.0.0.2
|
GigabitEthernet1/0/0.111(vlan interface)13.0.0.5 packet to send out
destination IP (13.0.0.200)
In this configuration , Ping to the same destination IP(IP: 13.0.0.200)
works (in Linux)as kernel pick up the plain interface route since that is
the 1st route in its routing table.
But VPP ends up requesting ARP(IP: 13.0.0.200) on a VLAN interface which
fails since the ARP is reachable only via the plain interface.
Regards,
Bindiya
On Tue, May 15, 2018 at 1:00 PM, Ole Troan <otr...@employees.org> wrote:
> Hi Bindiya,
>
> > Linux had allowed this configuration and test cases which were running
> on Linux failed on VPP.
> > The reason why it had passed is that linux always picks up the 1st entry
> that gets added in routing table i.e. plain interface while in VPP fib
> entry always return last interface that get added. Hence was curious if
> this was intentional?
>
> Are you saying that the following works in Linux:
>
> 192.0.2.1/24 -> Eth0
> 192.0.2.2/24 -> Eth1
>
> Where Eth0 and Eth1 are connected to the same L2.
>
> Or are you saying that Linux ignores the second entry and just uses the
> first entry in the FIB?
> What then happens with the 192.0.2.2 address?
>
> > Your point "While IPv6 notionally has support for that" is this from the
> RFC, could you please direct me to that?
>
> Look for "inbound load balancing" and "same link" in RFC4861 and RFC4862.
> It is pretty hand-wavy. E.g. it could be implemented as a new virtual
> interface hiding the two underlaying physical interfaces.
>
> Cheers,
> Ole
>
