Hi Ole, Thank you for the quick response. You answered all my questions and it is working as per the design which you explained clearly in the above email. And there are no bugs as such that are questioned in the above email.
Thanks, Subramanya On Fri, 21 Jan 2022 at 17:39, <otr...@employees.org> wrote: > Hi Subramanya, > > In general a router implements the weak host model, see > https://datatracker.ietf.org/doc/html/rfc1122#section-3.3.4 > In the weak host model the source address selected is independent of the > outgoing interface. > > > I'm trying to ping, and I observe that there is a mismatch between the > interface taken by the packet to go out and the source IP in the packet > (when there are ecmp routes). > > The issue is that when I try to ping, and there are ECMP routes, the > interface it is going out and the source IP value filled in the IP header > is different, and also packet is not going out of the desired interface, if > I use the "source" option in ping.(even though IP is correct). > > > > Suppose, there are two sub-interfaces configured this way: > > > > TwentyFiveGEthernet0/7/0.13 (up): > > L3 10.10.10.1/29 ip4 table-id 1 fib-idx 1 > > > > TwentyFiveGEthernet0/8/0.14 (up): > > L3 10.10.10.17/29 ip4 table-id 1 fib-idx 1 > > > > And hardware Addresses are this way: > > > > TwentyFiveGEthernet0/7/0 3 up TwentyFiveGEthernet0/7/0 > > Link speed: 25 Gbps > > Ethernet address fa:16:3e:xx:xx:x1 > > > > TwentyFiveGEthernet0/8/0 4 up TwentyFiveGEthernet0/8/0 > > Link speed: 25 Gbps > > Ethernet address fa:16:3e:xx:xx:xx > > > > > > > > show ip fib output is as follows: > > 0.0.0.0/0 > > unicast-ip4-chain > > [@0]: dpo-load-balance: [proto:ip4 index:31 buckets:2 uRPF:199 > to:[0:0]] > > [0] [@5]: ipv4 via 172.19.171.113 TwentyFiveGEthernet0/7/0.1328: > mtu:1500 next:6 a47b2cf5dbf9fa163ecda406810005300800 > > [1] [@5]: ipv4 via 172.19.171.121 TwentyFiveGEthernet0/8/0.1329: > mtu:1500 next:7 a47b2cfaf0edfa163eb0de2f810005310800 > > > > > > Now, suppose I ping using interface TwentyFiveGEthernet0/7/0.13, [ > ping 8.8.8.8 source TwentyFiveGEthernet0/7/0.13 ] > > it is filling the IP of that interface which is 10.10.10.1, but the > outgoing packet is going out of interface TwentyFiveGEthernet0/8/0.14 and > the mac and vlan is also taken of TwentyFiveGEthernet0/8/0.13, > > Are you saying that VPP sends a packet out on 0.14 with a source MAC from > 0.13? > If that's the case, that's clearly a bug. > > > Also, using the option "table-id"[ping 8.8.8.8 table-id 1], the same > issue is seen, where there is a mismatch of the source ip filled in packet > and the packet is taking a different interface to go out. > > Are you saing the source address chosen is not part of table 1? If so that > is also a bug with the source address selection done by ping. > > > So I'm guessing that once the ping plugin fills the source IP address > in the packet, and when the packet gets to the next node i.e. "ip4-lookup" > node, it is not considered strictly to go out of the interface with which > the user has specified in ECMP case. > > The ping "source" command doesn't specify outgoing interface, it specifies > which interface the SAS algorithm should try to get a source address from. > > Suggestions for improvements? We could possibly add an option that would > allow you to set outgoing interface in case of ECMP. > Or even a toggle to select strong host model too. > > Best regards, > Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20784): https://lists.fd.io/g/vpp-dev/message/20784 Mute This Topic: https://lists.fd.io/mt/88580236/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
