Hi Hanlin, Inline.
> On Dec 4, 2019, at 1:59 AM, wanghanlin <wanghan...@corp.netease.com> wrote: > > Hi Florin， > > Thanks for your patient reply. Still I have some doubt inline. > > > wanghanlin > > wanghan...@corp.netease.com > > <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=wanghanlin&uid=wanghanlin%40corp.netease.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22wanghanlin%40corp.netease.com%22%5D&logoUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyeicon%2F209a2912f40f6683af56bb7caff1cb54.png> > 签名由 网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 > On 11/30/2019 02:47，Florin Coras<fcoras.li...@gmail.com> > <mailto:fcoras.li...@gmail.com> wrote： > Hi Hanlin, > > Inline. > >> On Nov 29, 2019, at 7:12 AM, wanghanlin <wanghan...@corp.netease.com >> <mailto:wanghan...@corp.netease.com>> wrote: >> >> Hi Florin, >> Thanks for your reply. >> I just consider a very simple use case. Some apps in different containers >> communicate through VPP, just in a L2 bridge domain. >> Without hoststack, we may add some host-interfaces in one bridge domain, >> and assign IP address of veth interface in containers. In addition, a >> physical nic also added in same bridge domain to communicate with other >> hosts. >> But with hoststack, things seem complicated because we have to assign IP >> address inside VPP. > > FC: Yes, with host stack transport protocols are terminated in vpp, therefore > the interfaces must have IPs. Do you need network access to the container’s > linux stack for other applications, i.e., do you need IPs in the container as > well? Also, can’t you give the interfaces /32 IPs? > > Hanlin：I need not access to contaner's linux stack now, I think I can create > another host-interface with another IP if needed. Also, if I give the > interfaces /32 IPs, then how to communicate with each other and external > hosts? FC: I’m not sure I understand the question. I’m inclined to say vpp routing and/or cut-through sessions, but it feels like I’m missing some point you were trying to make. > As an alternative, I assign multiple /24 IPs to one interface, then two > applications can communicate with each other and external hosts, but can > only get 0.0.0.0/0 source address at accept time when communicating with each > other. Maybe I should bind to a IP before connect if I want to get this > specified IP？ FC: If you use /24 for the interface then, if you want a unique local IPs for each app, you should use an explicit source ip in the connect (see vppcom_session_attr and VPPCOM_ATTR_SET_LCL_ADDR). > >> I hope apps can communicate with each other and with external hosts in the >> same vrf and source ip is enforced and not changed during communication. If >> not, can multiple vrfs achieve this? > > FC: If applications are attached to the same app namespace, then you could > leverage cut-through connections if you enable local scope connections at > attachment time (see slides 17 and 18 here [1]). Cut-through sessions are > “connected” at session layer, so they don’t pass through the IP fib. > > Hanlin：Can local scope and global scope enable simultaneously? ie, some > connections use local scope and others use global scope simultaneously. FC: Yes, you can. > > Otherwise, connectivity between the apps is established via intra-vrf or > inter-vrf routing. Intra-vrf you don’t need to configure anything more, > inter-vrf you need to add additional routes. For external hosts, you need > routes to them in the vrfs. > > Hanlin：Inter-vrf leaking seems to not work when multiple vrf have same subnet > IPs. In test/test_vcl.py, two vrf table have different subnet IPs. FC: Yes, that’s true. Let’s clarify your first question and see which of the two options (multiple /32 interfaces or a /24 one) works. Regards, Florin > > What we call “local” IPs for a connection are assigned at connect/accept time > and they do not change. When connecting, we use the first IP of an interface > that has a route to the destination and on accept, we use the dst IP on the > SYN packet. > > Regards, > Florin > > [1] https://wiki.fd.io/images/9/9c/Vpp-hoststack-kc-eu19.pdf > <https://wiki.fd.io/images/9/9c/Vpp-hoststack-kc-eu19.pdf> > >> >> Thanks, >> Hanlin >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> >> View/Reply Online (#14737): https://lists.fd.io/g/vpp-dev/message/14737 >> <https://lists.fd.io/g/vpp-dev/message/14737> >> Mute This Topic: https://lists.fd.io/mt/64106592/675152 >> <https://lists.fd.io/mt/64106592/675152> >> Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io> >> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub >> <https://lists.fd.io/g/vpp-dev/unsub> [fcoras.li...@gmail.com >> <mailto:fcoras.li...@gmail.com>] >> -=-=-=-=-=-=-=-=-=-=-=- > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14817): https://lists.fd.io/g/vpp-dev/message/14817 Mute This Topic: https://lists.fd.io/mt/64106592/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
