Hi Florin,
Thanks for your suggestion.
Follow your suggested configuration, three applications can communicate each other. But there are two minor problems:
1. I used option 2 to configure APP2 and APP3, but can only get the source IP address 0.0.0.0 (not 192.168.1.129 or 192.168.1.130) after accept for a connect request.
2. There are two different networks between APP1 and APP2/APP3 in your configuration. But if they are all in the same network, then how to configure?
Following are vpp, vcl and fib configurations:
Thanks & Regards,
Hanlin
On 12/7/2019 07:11，Florin Coras<fcoras.li...@gmail.com> wrote：
Hi Hanlin,Inline.On Dec 5, 2019, at 7:00 PM, wanghanlin <wanghan...@corp.netease.com> wrote:Hi Florin,Okay, regarding first question, the following is the detailed use case:I have one 82599 nic in my Linux host. Then I allocate two VF interfaces through SRIOV, one VF place into a Linux namespace N1 and assign IP address 192.168.1.2/24, another VF place into VPP.I have three applications (just called APP1, APP2, APP3) communicating with each other, and each application must get the source IP address (not 0.0.0.0) after accept for a connect request.APP1 run in Linux namespce N1 and use IP address 192.168.1.2/24. APP2 run in Linux namespace N2 and use IP address 192.168.1.3/24. APP3 run in Linux namespace N3 and use IP address 192.168.1.4/24.And finally, APP2 and APP3 need to run based LDP.Let's summarize:APP1, N1, 192.168.1.2/24, outside VPPAPP2, N2, 192.168.1.3/24, inside VPPAPP3, N3, 192.168.1.4/24, inside VPPFC: I assume N2 and N3 are mapped to app namespaces from VPP perspective. Additionally, those two prefixes, i.e., 192.168.1.3/24 and 192.168.1.4/24, do not need to be configured on interfaces part of N2 and N3 respectively.Then, from vpp perspective, APP2 and APP3 are “locally attached” and APP1 is “remote”. So, from my perspective, they’re at least two different networks. APP2 and APP3 could be the same or different networks.For instance, you could assign 192.168.1.2/25 to N1 and then leave 192.168.1.128/25 to vpp for N2 and N3. Within vpp you have two options:- add two interfaces, say intN2 and intN3 with IPs 192.168.1.129/32 and 192.168.1.130/32 and associate N2 and N3 app namespaces to those interfaces (not the fibs). Whenever initiating connections, APP2 and APP3 will pick up the ips of the interfaces associated to their respective app namespaces.- add one interface intN with IP 192.168.1.129/25 and associate both namespaces to it. If you need APP1 to use 192.168.1.129 and APP2 192.168.1.130, then you’ll need your apps to call bind before connecting (haven’t tested this but I think it should work).The above assumes APP2 and APP3 map to different app namespaces. If you want to use the same app namespace, to be able to use cut-through connections, then only option 2 works. Additionally, you need the two apps to attach with both local and global scope set.Hope this helps!Regards,FlorinThen, my question is how to configure 192.168.1.3/24 and 192.168.1.4/24 in VPP?Thanks & Regards,HanlinHi 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.Hi Hanlin,Inline.On Nov 29, 2019, at 7:12 AM, wanghanlin <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,FlorinWhat 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,FlorinThanks,Hanlin-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14737): https://lists.fd.io/g/vpp-dev/message/14737
Mute This Topic: https://lists.fd.io/mt/64106592/675152
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [fcoras.li...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group.
View/Reply Online (#14840): https://lists.fd.io/g/vpp-dev/message/14840 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] -=-=-=-=-=-=-=-=-=-=-=-
