On 09/08/2021 10:15, "otr...@employees.org" <otr...@employees.org> wrote: > I think that is telling you not to use /32 address on interface for which you > expect there to be connected peers. > From an IP networking perspective, if you want two peers to be connected on > an interface, they need to be within the same subnet, so use a /31.
For p2p links there are actually two valid approaches to IP subnetting. i would argue the contrary, not subnetting (i.e. using /32) is not a valid approach to subnetting. The BSD approach where you have to independent /32s on each side and a routing entry for the other side. Or a connected route /31 or larger. The act of configuring an address with a prefix is really a shortcut for configuring the address _and_ the connected prefix of course. And it’s an expression that there are other hosts attached to this link so you don’t need to add /32 routes for any such hosts. IOW it’s a way of say stating that there is a sub-network of hosts attached to this router. And my routing protocol can advertise this. If you add only a /32 you make none of those statements, and any routing protocol, if it still works over links without a subnet, does not include (without rediest static) reachability to those attached hosts. IOW it’s broken 😊, or at a minimum not standard IP networking. Of course I may be wrong, I often am, but this was my position when writing IP functionality for VPP, so there may be other surprises … Sounds to me like the SAS algorithm needs a bit of work. Now on that topic I heartily agree 😊 my SAS implementation is flawed in that it uses the glean adjacency to store the link’s receive address. P2p links don’t have a glean adj, hence SAS is broken on p2p links. It was an oversight on my part, I know I need to fix it. My goal with the SAS implementation done that way was to be able to do basic SAS without needing the interface addresses programmed via ‘set int ip adrr …’, but rather completely through the RIB (i.e. ip route add …). This is more like what one might expect at the bottom of a router stack. To say that goal is imcomplete, is an understatement :( The p2p fix, using the directly added IP link addresses is easy, it’s here: https://gerrit.fd.io/r/c/vpp/+/32801 (I'd like to use it for ICMP error sending too, where it also should handle the case of picking a source address from another interface than the outgoing interface). SAS++ 😊 /neale Cheers, Ole > From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> > <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> on behalf of Artem > Glazychev via lists.fd.io > <artem.glazychev=xored....@lists.fd.io<mailto:artem.glazychev=xored....@lists.fd.io>> > Date: Wednesday, 4 August 2021 at 08:37 > To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> > <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> > Subject: [vpp-dev] memif: failed: no source address for egress interface > > Hello, > Found a problem with some types of interfaces. > > For example, memif. When I'm creating memif interfaces and run ping I see: > > DBGvpp# ping 10.10.2.1 > Failed: no source address for egress interface > ... > > But it is worth mentioning that I am setting /32 mask for IP address > > Managed to fix IP mode with these patches: > https://gerrit.fd.io/r/c/vpp/+/32801, https://gerrit.fd.io/r/c/vpp/+/33303 > > But Ethernet mode still doesn't work. > > ============================== > > There was already a similar topic: > https://lists.fd.io/g/vpp-dev/topic/84038840 > > Created a jira issue with details: https://jira.fd.io/browse/VPP-1992 > > Does anyone have any thoughts on this? Thank you. > > > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19930): https://lists.fd.io/g/vpp-dev/message/19930 Mute This Topic: https://lists.fd.io/mt/84656776/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
