Re: COMMERCIAL BULK: Re: [E] COMMERCIAL BULK: [vpp-dev] TLS app stuck after burst of traffic #vpp-hoststack

[Kevin Yan via lists.fd.io]

Hi Florin,
   Due to some reasons we need to stay on vpp20.09 for some time,  
that’s why I hope I can fix the issue on this version. Actually, I  did some 
code changes in TLS layer to let session node force reschedule the TLS session 
when tx svm fifo is full or at least not empty, after the changes, the tx  svm 
fifo can be recovered after stopping the traffic, but I think this is not the 
correct way to solve the issue.

   Anyway let me see if I can test the same case with latest vpp 
codes

BRs,
Kevin

From: vpp-dev@lists.fd.io  On Behalf Of Florin Coras
Sent: Tuesday, March 7, 2023 2:49 PM
To: vpp-dev 
Cc: Olivia Dunham 
Subject: COMMERCIAL BULK: Re: [E] COMMERCIAL BULK: [vpp-dev] TLS app stuck 
after burst of traffic #vpp-hoststack


Email is from a Free Mail Service (Gmail/Yahoo/Hotmail….) : Beware of Phishing 
Scams, Report questionable emails to s...@mavenir.com<mailto:s...@mavenir.com>
Hi Kevin,

That’s a really old version of vpp. TLS has seen several improvements since 
then in areas including scheduling after incomplete writes. If you get a chance 
to test vpp latest or a more recent release, do let us know if the issue still 
persists.

Regards,
Florin


On Mar 6, 2023, at 5:42 PM, Kevin Yan via lists.fd.io 
mailto:kevin.yan=mavenir@lists.fd.io>> 
wrote:

Hi @Olivia Dunham<mailto:theoliviadun...@gmail.com>,
   Recently I met the exact same issue,  TLS TX svm fifo gets full 
after burst of traffic and it will never resume, meanwhile, TCP TX svm fifo is 
empty at that time I’m using VPP20.09,  I believe there is some issue in TLS 
layer,
so did you fix the issue later? If yes, can you share the solution.

BRs,
Kevin

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Olivia Dunham
Sent: Tuesday, September 14, 2021 8:58 PM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [E] COMMERCIAL BULK: [vpp-dev] TLS app stuck after burst of traffic 
#vpp-hoststack


Email is from a Free Mail Service (Gmail/Yahoo/Hotmail….) : Beware of Phishing 
Scams, Report questionable emails tos...@mavenir.com<mailto:s...@mavenir.com>
During sudden burst of traffic, the TCP fifo gets full. When this happens the 
openssl TLS app de-schedules the transport. But once the TCP data is sent out, 
the TLS is not resuming. VPP ends up in a state where TCP fifo is empty, but 
the TLS fifo is full and no more Tx happens on TLS fifo.

VPP version: 21.01

We came across this commit - session tls: deq notifications for custom 
tx<https://github.com/FDio/vpp/commit/1e6a0f64653c8142fa7032aba127ab4894bafc3c>
Not sure what is the issue fixed by this commit, but It doesn't seem to fix the 
above mentioned issue.

This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to 
secur...@mavenir.com<mailto:secur...@mavenir.com>. This message contains the 
views of its author and may not necessarily reflect the views of Mavenir 
Systems, Inc. or its affiliates, who employ systems to monitor email messages, 
but make no representation that such messages are authorized, secure, 
uncompromised, or free from computer viruses, malware, or other defects. Thank 
You




This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to secur...@mavenir.com. This 
message contains the views of its author and may not necessarily reflect the 
views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor 
email messages, but make no representation that such messages are authorized, 
secure, uncompromised, or free from computer viruses, malware, or other 
defects. Thank You

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22673): https://lists.fd.io/g/vpp-dev/message/22673
Mute This Topic: https://lists.fd.io/mt/97448587/21656
Mute #vpp-hoststack:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-hoststack
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [E] COMMERCIAL BULK: [vpp-dev] TLS app stuck after burst of traffic #vpp-hoststack

[Kevin Yan via lists.fd.io]

Hi @Olivia Dunham,
   Recently I met the exact same issue,  TLS TX svm fifo gets full 
after burst of traffic and it will never resume, meanwhile, TCP TX svm fifo is 
empty at that time I’m using VPP20.09,  I believe there is some issue in TLS 
layer,
so did you fix the issue later? If yes, can you share the solution.

BRs,
Kevin

From: vpp-dev@lists.fd.io  On Behalf Of Olivia Dunham
Sent: Tuesday, September 14, 2021 8:58 PM
To: vpp-dev@lists.fd.io
Subject: [E] COMMERCIAL BULK: [vpp-dev] TLS app stuck after burst of traffic 
#vpp-hoststack


Email is from a Free Mail Service (Gmail/Yahoo/Hotmail….) : Beware of Phishing 
Scams, Report questionable emails to s...@mavenir.com
During sudden burst of traffic, the TCP fifo gets full. When this happens the 
openssl TLS app de-schedules the transport. But once the TCP data is sent out, 
the TLS is not resuming. VPP ends up in a state where TCP fifo is empty, but 
the TLS fifo is full and no more Tx happens on TLS fifo.

VPP version: 21.01

We came across this commit - session tls: deq notifications for custom 
tx
Not sure what is the issue fixed by this commit, but It doesn't seem to fix the 
above mentioned issue.

This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to secur...@mavenir.com. This 
message contains the views of its author and may not necessarily reflect the 
views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor 
email messages, but make no representation that such messages are authorized, 
secure, uncompromised, or free from computer viruses, malware, or other 
defects. Thank You

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22671): https://lists.fd.io/g/vpp-dev/message/22671
Mute This Topic: https://lists.fd.io/mt/97440914/21656
Mute #vpp-hoststack:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-hoststack
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [E] COMMERCIAL BULK: Re: [vpp-dev] Issues with failsafe dpdk pmd in Azure

[Kevin Yan via lists.fd.io]

Hi All,
   After I run below two cmds manually, ping traffic recovered , 
but why tc mirred not working after sometime

tc qdisc add dev eth1 handle : ingress
tc filter add dev eth1 parent : u32  match u32 0 0 action mirred egress 
redirect dev dtap0

Best Regards,
Kevin
From: vpp-dev@lists.fd.io  On Behalf Of Kevin Yan via 
lists.fd.io
Sent: Friday, December 2, 2022 4:39 PM
To: Peter Morrow ; Stephen Hemminger 

Cc: vpp-dev@lists.fd.io; Long Li 
Subject: COMMERCIAL BULK: Re: [E] COMMERCIAL BULK: Re: [vpp-dev] Issues with 
failsafe dpdk pmd in Azure


[EXTERNAL EMAIL] DO NOT CLICK links or attachments unless you recognize the 
sender and know the content is safe.
Hi Peter, Stephen and Long,
   I am facing some issues when running VPP on Azure VM, can you 
please help and give some suggestion if possible.
   I'm running CentOS 7.9 with kernel version 3.10.0 on Azure VM, 
VPP version is 20.09 and DPDK version is 20.11, below is the snapshot of vpp 
startup.conf related to netvsc device

dpdk {
socket-mem 0
no-multi-seg
vdev net_vdev_netvsc0,iface=eth1
vdev net_vdev_netvsc1,iface=eth2
netvsc_dev eth1 {
vpp_interface_name fpeth1
num-rx-queues 1
num-tx-queues 1
num-rx-desc 1024
num-tx-desc 1024
}
netvsc_dev eth2 {
vpp_interface_name fpeth2
num-rx-queues 1
num-tx-queues 1
num-rx-desc 1024
num-tx-desc 1024
}
}
   Forget the netvsc_dev section, this is added by me in order to 
change the failsafe interface name ,otherwise it will always use the default 
name: FailsafeEthernet1, FailsafeEthernet2, etc.
   Btw, for my kernel version(3.10.0) , it can only run failsafe 
PMD in VPP/DDPK, right?

   Basically, we are using two netvsc interfaces and vpp can come 
up without any issue, show hard/show log output looks good and is listed as 
below:
vpp# sh hard
  NameIdx   Link  Hardware
fpeth1 1 up   fpeth1
  Link speed: 50 Gbps
  Ethernet address 00:0d:3a:57:cc:aa
  FailsafeEthernet
carrier up full duplex mtu 1504
flags: admin-up pmd rx-ip4-cksum
Devargs: fd(30),dev(net_tap_vsc0,remote=eth1)
rx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
tx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
max rx packet len: 1522
promiscuous: unicast off all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  ipv4-cksum udp-cksum tcp-cksum scatter
rx offload active: ipv4-cksum
tx offload avail:  ipv4-cksum udp-cksum tcp-cksum tcp-tso multi-segs
tx offload active: none
rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-other ipv4 ipv6-tcp-ex
   ipv6-udp-ex ipv6-frag ipv6-tcp ipv6-udp ipv6-other
   ipv6-ex ipv6
rss active:none
tx burst function: failsafe_tx_burst_fast
rx burst function: failsafe_rx_burst_fast

tx frames ok1507
tx bytes ok95370
rx frames ok 322
rx bytes ok33127
extended stats:
  rx_good_packets322
  tx_good_packets   1507
  rx_good_bytes33127
  tx_good_bytes95370
  rx_q0_packets  322
  rx_q0_bytes  33127
  tx_q0_packets 1507
  tx_q0_bytes  95370
  tx_sub0_good_packets  1507
  tx_sub0_good_bytes   95370
  tx_sub0_q0_packets1507
  tx_sub0_q0_bytes 95370
  tx_sub0_unicast_packets322
  tx_sub0_unicast_bytes30910
  tx_sub0_multicast_packets   29
  tx_sub0_multicast_bytes   3066
  tx_sub0_broadcast_packets 1209
  tx_sub0_broadcast_bytes  80718
  rx_sub1_good_packets   322
  rx_sub1_good_bytes   33127
  rx_sub1_q0_packets 322
  rx_sub1_q0_bytes 33127
fpeth2 2 up   fpeth2
  Link speed: 50 Gbps
  Ethernet address 00:0d:3a:57:cf:f0
  FailsafeEthernet
carrier up full duplex mtu 1504
flags: admin-up pmd rx-ip4-cksum
Devargs: fd(45),dev(net_tap_vsc1,remote=eth2)
rx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
tx: queues 1 (max 16), desc 1024 (min 0

Re: [E] COMMERCIAL BULK: Re: [vpp-dev] Issues with failsafe dpdk pmd in Azure

[Kevin Yan via lists.fd.io]

Hi Peter, Stephen and Long,
   I am facing some issues when running VPP on Azure VM, can you 
please help and give some suggestion if possible.
   I'm running CentOS 7.9 with kernel version 3.10.0 on Azure VM, 
VPP version is 20.09 and DPDK version is 20.11, below is the snapshot of vpp 
startup.conf related to netvsc device

dpdk {
socket-mem 0
no-multi-seg
vdev net_vdev_netvsc0,iface=eth1
vdev net_vdev_netvsc1,iface=eth2
netvsc_dev eth1 {
vpp_interface_name fpeth1
num-rx-queues 1
num-tx-queues 1
num-rx-desc 1024
num-tx-desc 1024
}
netvsc_dev eth2 {
vpp_interface_name fpeth2
num-rx-queues 1
num-tx-queues 1
num-rx-desc 1024
num-tx-desc 1024
}
}
   Forget the netvsc_dev section, this is added by me in order to 
change the failsafe interface name ,otherwise it will always use the default 
name: FailsafeEthernet1, FailsafeEthernet2, etc.
   Btw, for my kernel version(3.10.0) , it can only run failsafe 
PMD in VPP/DDPK, right?

   Basically, we are using two netvsc interfaces and vpp can come 
up without any issue, show hard/show log output looks good and is listed as 
below:
vpp# sh hard
  NameIdx   Link  Hardware
fpeth1 1 up   fpeth1
  Link speed: 50 Gbps
  Ethernet address 00:0d:3a:57:cc:aa
  FailsafeEthernet
carrier up full duplex mtu 1504
flags: admin-up pmd rx-ip4-cksum
Devargs: fd(30),dev(net_tap_vsc0,remote=eth1)
rx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
tx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
max rx packet len: 1522
promiscuous: unicast off all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  ipv4-cksum udp-cksum tcp-cksum scatter
rx offload active: ipv4-cksum
tx offload avail:  ipv4-cksum udp-cksum tcp-cksum tcp-tso multi-segs
tx offload active: none
rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-other ipv4 ipv6-tcp-ex
   ipv6-udp-ex ipv6-frag ipv6-tcp ipv6-udp ipv6-other
   ipv6-ex ipv6
rss active:none
tx burst function: failsafe_tx_burst_fast
rx burst function: failsafe_rx_burst_fast

tx frames ok1507
tx bytes ok95370
rx frames ok 322
rx bytes ok33127
extended stats:
  rx_good_packets322
  tx_good_packets   1507
  rx_good_bytes33127
  tx_good_bytes95370
  rx_q0_packets  322
  rx_q0_bytes  33127
  tx_q0_packets 1507
  tx_q0_bytes  95370
  tx_sub0_good_packets  1507
  tx_sub0_good_bytes   95370
  tx_sub0_q0_packets1507
  tx_sub0_q0_bytes 95370
  tx_sub0_unicast_packets322
  tx_sub0_unicast_bytes30910
  tx_sub0_multicast_packets   29
  tx_sub0_multicast_bytes   3066
  tx_sub0_broadcast_packets 1209
  tx_sub0_broadcast_bytes  80718
  rx_sub1_good_packets   322
  rx_sub1_good_bytes   33127
  rx_sub1_q0_packets 322
  rx_sub1_q0_bytes 33127
fpeth2 2 up   fpeth2
  Link speed: 50 Gbps
  Ethernet address 00:0d:3a:57:cf:f0
  FailsafeEthernet
carrier up full duplex mtu 1504
flags: admin-up pmd rx-ip4-cksum
Devargs: fd(45),dev(net_tap_vsc1,remote=eth2)
rx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
tx: queues 1 (max 16), desc 1024 (min 0 max 65535 align 1)
max rx packet len: 1522
promiscuous: unicast off all-multicast on
vlan offload: strip off filter off qinq off
rx offload avail:  ipv4-cksum udp-cksum tcp-cksum scatter
rx offload active: ipv4-cksum
tx offload avail:  ipv4-cksum udp-cksum tcp-cksum tcp-tso multi-segs
tx offload active: none
rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-other ipv4 ipv6-tcp-ex
   ipv6-udp-ex ipv6-frag ipv6-tcp ipv6-udp ipv6-other
   ipv6-ex ipv6
rss active:none
tx burst function: failsafe_tx_burst_fast
rx burst function: failsafe_rx_burst_fast

tx frames ok  

Re: [E] Re: [vpp-dev] VPP deadlock issue

[Kevin Yan via lists.fd.io]

Hi Florin,
  Thanks for the quick reply. I think when this issue happened, 
main thread was locking the binary api’s queue mutex, and then it scheduled to 
execute another process node, in this process node it called barrier sync. Is 
this a possible scenario?

BRs,
Kevin

From: Florin Coras 
Sent: Friday, April 8, 2022 10:00 AM
To: Kevin Yan 
Cc: vpp-dev@lists.fd.io; Alan Wang 
Subject: [E] Re: [vpp-dev] VPP deadlock issue


Email is from a Free Mail Service (Gmail/Yahoo/Hotmail….) : Beware of Phishing 
Scams, Report questionable emails to s...@mavenir.com<mailto:s...@mavenir.com>
Hi Kevin,

That’s a pretty old VPP release so you should maybe try to update.

Regarding the deadlock, what is main actually doing? If it didn’t lock the 
binary api's queue mutex before the barrier sync, it shouldn’t deadlock.

Regards,
Florin


On Apr 7, 2022, at 6:39 PM, Kevin Yan via lists.fd.io<http://lists.fd.io> 
mailto:kevin.yan=mavenir@lists.fd.io>> 
wrote:

Hi,
  Recently I got a VPP crash issue, one worker thread is doing 
mutex lock and waiting for getting the mutex, the complete call stack is 
arp_learn-> vnet_arp_set_ip4_over_ethernet-> vl_api_rpc_call_main_thread-> 
vl_msg_api_alloc_as_if_client-> vl_msg_api_alloc_internal-> pthread_mutex_lock 
(>mutex); while at the same time main thread is calling 
vlib_worker_thread_barrier_sync to try to lock all worker threads, this will 
lead deadlock and hence VPP crashed.

  Did anyone meet the similar issue and how to solve this race 
condition? I am using vpp19.01, tried to search the commits related to this 
issue for later release but no lucky, not sure if this issue got fixed in later 
release .
  Appreciate if anyone can help.

BRs,
Kevin

This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to 
secur...@mavenir.com<mailto:secur...@mavenir.com>. This message contains the 
views of its author and may not necessarily reflect the views of Mavenir 
Systems, Inc. or its affiliates, who employ systems to monitor email messages, 
but make no representation that such messages are authorized, secure, 
uncompromised, or free from computer viruses, malware, or other defects. Thank 
You




This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to secur...@mavenir.com. This 
message contains the views of its author and may not necessarily reflect the 
views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor 
email messages, but make no representation that such messages are authorized, 
secure, uncompromised, or free from computer viruses, malware, or other 
defects. Thank You

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21230): https://lists.fd.io/g/vpp-dev/message/21230
Mute This Topic: https://lists.fd.io/mt/90327881/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP deadlock issue

[Kevin Yan via lists.fd.io]

Hi,
  Recently I got a VPP crash issue, one worker thread is doing 
mutex lock and waiting for getting the mutex, the complete call stack is 
arp_learn-> vnet_arp_set_ip4_over_ethernet-> vl_api_rpc_call_main_thread-> 
vl_msg_api_alloc_as_if_client-> vl_msg_api_alloc_internal-> pthread_mutex_lock 
(>mutex); while at the same time main thread is calling 
vlib_worker_thread_barrier_sync to try to lock all worker threads, this will 
lead deadlock and hence VPP crashed.

  Did anyone meet the similar issue and how to solve this race 
condition? I am using vpp19.01, tried to search the commits related to this 
issue for later release but no lucky, not sure if this issue got fixed in later 
release .
  Appreciate if anyone can help.

BRs,
Kevin

This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to secur...@mavenir.com. This 
message contains the views of its author and may not necessarily reflect the 
views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor 
email messages, but make no representation that such messages are authorized, 
secure, uncompromised, or free from computer viruses, malware, or other 
defects. Thank You

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21228): https://lists.fd.io/g/vpp-dev/message/21228
Mute This Topic: https://lists.fd.io/mt/90327533/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] some questions about libmemif

[Kevin Yan via Lists.Fd.Io]

Hi all,
Recently I am reading codes of libmemlif (based on vpp19.01) ,I 
am a little bit confused about the fields of head/tail in struct memif_ring_t 
and last_head/last_tail in struct memif_queue_t.

Can anybody help to  clarify the internal mechanism  of the 
read/write operation of ring and how to move the head/tail and  
last_head/last_tail?  I'd like to better understand this and  really appreciate 
if anyone can help.

BRs,
Kevin

This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to secur...@mavenir.com. This 
message contains the views of its author and may not necessarily reflect the 
views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor 
email messages, but make no representation that such messages are authorized, 
secure, uncompromised, or free from computer viruses, malware, or other 
defects. Thank You
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14233): https://lists.fd.io/g/vpp-dev/message/14233
Mute This Topic: https://lists.fd.io/mt/35012940/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [E] Re: [vpp-dev] vip in VPP

[Kevin Yan via Lists.Fd.Io]

Hi Shahid,
Actually I have the same requirement that two IPs from same subnet configured 
on one interface and I tried to configure that way but it failed, vpp will 
complain as bellows
[cid:image001.png@01D50BC7.7BED62D0]
https://gerrit.fd.io/r/#/c/8057/
this patch did the check and disable overlapping sub-nets on any interface, is 
this reasonable? I suppose it is okay to configure multiple ip addresses within 
same subnet to one same interface.  Linux supports this, but vpp doesn’t.

so how did you solve your problem?

BRs,
Kevin
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Shahid Khan
Sent: Friday, April 26, 2019 9:19 PM
To: Ole Troan 
Cc: Damjan Marion ; vpp-dev@lists.fd.io
Subject: [E] Re: [vpp-dev] vip in VPP

Just default gw ... i will check assigning two IPs from same subnet to one 
interface ...


-Shahid

On Apr 26, 2019 18:14, "Ole Troan" 
mailto:otr...@employees.org>> wrote:
> Can we configure one interface with two ips from same subnet ?

There's certainly nothing wrong with that, so if it for some reason doesn't 
work, that can be patched.
You can of course put the same IP on different VPP instances on e.g. a loopback 
interface. If you have some way of routing to them.

VRRP is not supported. Do you have some application requiring state 
synchronisation on top, or is this just for default gateway?

Cheers,
Ole

>
> -Shahid
>
> On Apr 26, 2019 17:56, "Damjan Marion" 
> mailto:dmar...@me.com>> wrote:
>
>
> > On 26 Apr 2019, at 14:15, Shahid Khan 
> > mailto:shahidnasimk...@gmail.com>> wrote:
> >
> > Not on different interfaces same subnet on parent and its sub interface 
> > ... Parent interface will have real ip and sub interface will have VIP
>
> sub-interface is from fib perspective different interface and it is typically 
> tagged with some vlan tags.
>
> What’s wrong with having one interface with 2 IPs assigned. 2nd IP can be 
> added/removed based on control plane decision (i.e. change of vrrp state).
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#12861): https://lists.fd.io/g/vpp-dev/message/12861
> Mute This Topic: https://lists.fd.io/mt/31351846/675193
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
> [otr...@employees.org]
> -=-=-=-=-=-=-=-=-=-=-=-

This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to secur...@mavenir.com. This 
message contains the views of its author and may not necessarily reflect the 
views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor 
email messages, but make no representation that such messages are authorized, 
secure, uncompromised, or free from computer viruses, malware, or other 
defects. Thank You
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13049): https://lists.fd.io/g/vpp-dev/message/13049
Mute This Topic: https://lists.fd.io/mt/31636478/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-