For anyone reading this, a dirty way around it is to simply add a static
mapping using the external IP and port as both the local and external IP and
port. This forwards the packet internally, punts it, and goes straight to the
TAP interface.
Not ideal, not pretty, but it works.
-=-=-=-=-=-=-=-
Hi,
If we enable dynamic NAT, then TCP packets are no longer punted or even seen on
tap interfaces, as they are simply dropped if there's no matching translation.
This isn't ideal since we still want to be able to process packets that are
meant for us, for example if our interface address is no
I can confirm that this does NOT happen in 19.01 stable
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12458): https://lists.fd.io/g/vpp-dev/message/12458
Mute This Topic: https://lists.fd.io/mt/30295958/21656
Mute #vpp_stability: https://lists.fd.i
Hi everyone,
I noticed something today using v19.04-rc0, running Ubuntu 18.04
Fresh install, nothing modified, cloned straight from https://gerrit.fd.io/r/vpp
Either built manually or via vpp/build-root/vagrant/build.sh, then installed
non-dev and non-debug debs
When NOT using workers, latency
Hi Ole,
I'll see to submitting it then!
Sincerely,
John
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12456): https://lists.fd.io/g/vpp-dev/message/12456
Mute This Topic: https://lists.fd.io/mt/30286653/21656
Group Owner: vpp-dev+ow...@lists.fd.i
Hi,
I've added support to the NAT plugin for Paired-Address-Pooling (PAP) and
wanted to see if there is interest for me to submit it as a patch for review?
The changes modify the behaviour of user creation, address allocation, and
address management. Fundamentally it pairs a NAT user with an ex
Hi Matus,
That's unfortunate.
That would work as an immediate solution. I've considered a solution like that,
but I'm worried it might be wasteful. I considered that very setup when I was
contemplating a sort of hybrid NAT between dynamic NAT and CGN. In CGN, just as
we allocate a number of por
After reading Cisco's implementation for PAP for IOS XE, it seems they limit
the number of local addresses per global address. The default is 120 local
addresses per global address. That way we can make sure that there are never
more than a certain number of local users per global IP, but can st
Hi Matus,
Thanks once again.
That seems to be it. After reading RFC4787 section 4.1 REQ 1, their mention of
PAP (Paired-Address-Pooling) seems to be on-point.
As they mention:
>
> NATs that use an "IP address pooling" behavior of "Arbitrary" can cause
> issues for applications that use multipl
Hi Matus,
Thanks for the response!
Ah, I see, that makes more sense as to why we check against the FIB.
However, if we just pick a random port (per protocol) from the "first address
with some available ports" (dictated by the "busy ports" I presume), how does
this ensure that a user ever gets t
Hi Ole!
Thanks for the response!
I've followed the code you mentioned which has lead me to the default address
and port assignment algorithm. I can see how we can easily plug our own, but
I'm trying to first break down the code for the default one in order to
understand how exactly the algorit
Hello,
Breaking this out into its own thread.
Currently when creating a new dynamic NAT session, the source IP and source
port are considered. If I've understood this right, the next time the user
(source IP) sends traffic matching the previous traffic (source IP + source
port), the same
Hello everyone,
I've just come back from vacation and picked this up again.
I've not yet found a pretty solution to the issues that are present when using
NAT on a large scale and communicating with sources that require clients to
communicate from the same external IP. I had hoped we wouldn't n
nslations are processing (no
worker handoff) and with 10 cores there is worker handoff between two workers
and it is reason of performance drop. Basically your flows are not
symmetrically distributed between cores.
Matus
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
mailto:vpp-dev@
-dev@lists.fd.io On Behalf Of JB
Sent: Friday, December 21, 2018 4:25 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] NAT workers above 4 completely tanks performance
Hi Damjan,
Absolutely.
I raw one case with the default number of NAT workers (10) which has poor
performance, and another case
n is when a source IP uses a different source port but
intends to communicate with the same destination IP as a previous session.
John
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
mailto:vpp-dev@lists.fd.io>> on behalf of JB
mailto:john.bisce.
Hi Damjan,
Absolutely.
I raw one case with the default number of NAT workers (10) which has poor
performance, and another case with a fewer number of NAT workers (4) showing
great performance. They're separated by two different files, both are attached.
John
vpp# sh run
Thread 0 vpp_main (lc
o not account for with the
current implementation is when a source IP uses a different source port but
intends to communicate with the same destination IP as a previous session.
John
From: vpp-dev@lists.fd.io on behalf of JB
Sent: Tuesday, December 18, 2018 2:5
Hello everyone,
This is on "19.01", I've yet to test with 18.10. I've setup dynamic NAT.
I've tested this with a clean setup without specifying anything special in
startup.conf. The results are irrelevant of other NAT settings except NAT
workers. I've tried specifying various networks, single IP
m>> wrote:
Hi,
Endpoint-dependent NAT is not default behaviour, when you want to use
endpoint-dependent NAT you need to adjust startup config
https://wiki.fd.io/view/VPP/NAT#NAT44
Matus
-Original Message-
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> On Behal
sco)" mailto:matfa...@cisco.com>> wrote:
Hi,
Endpoint-dependent NAT is not default behaviour, when you want to use
endpoint-dependent NAT you need to adjust startup config
https://wiki.fd.io/view/VPP/NAT#NAT44
Matus
-Original Message-
From: vpp-dev@lists.fd.io<ma
T#NAT44
Matus
-Original Message-
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> On Behalf Of JB
Sent: Tuesday, December 18, 2018 12:02 AM
To: Ole Troan
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Sanity check re: NAT for same-servic
wiki.fd.io/view/VPP/NAT#NAT44
Matus
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of JB
Sent: Tuesday, December 18, 2018 12:02 AM
To: Ole Troan
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sanity check re: NAT for same-service mapping
Hi Ole,
Absolutely, Endpoint independent mapping i
Hey Brian,
I believe it fetches it again because the file doesn't match the hash string
present in one of the files inside the dpdk directory. At least that was the
issue I faced building for Mellanox cards ages ago. You could also specify that
it uses an external DPDK source.
Sent from ny pho
Hi Ole,
Absolutely, Endpoint independent mapping is the safest bet, which is why it is
recommended. It is unfortunate that we cannot rely on services being IP source
agnostic or that STUN will be used.
Thus, even though Endpoint independent mapping can be considered non-efficient
in its address
Hello group,
This might be best answered by Matus since it regards NAT, but I'll throw it
out there for the whole group.
The endpoint-dependent feature of the NAT plugin – Endpoint address AND port
dependent I presume from the 6-tuple description of it – allows us to map the
same internal sour
Hello everyone,
I've been looking for some documentation surrounding the classify feature of
VPP. Any documentation or any decent information I've stumbled upon seems to be
outdated with syntax that's no longer applicable.
Do we have anything that I've missed?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You
Hi Brian,
I've successfully built the router plugin on 18.10 and "19.01"
What errors are you encountering when you attempt to build it?
Kind regards,
John Biscevic
Systems Architect, Bahnhof AB
Mobile: +46 76 111 01 24
E-mail: john.bisce...@bahnhof.net
From
om: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
mailto:vpp-dev@lists.fd.io>> on behalf of JB
mailto:john.bisce...@bahnhof.net>>
Sent: Friday, October 19, 2018 3:19 PM
To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco);
vpp-dev@lists.fd.io<mailto:vpp-dev@l
...@bahnhof.net<mailto:john.bisce...@bahnhof.net>
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
mailto:vpp-dev@lists.fd.io>> on behalf of JB
mailto:john.bisce...@bahnhof.net>>
Sent: Friday, October 19, 2018 3:19 PM
To: Matus Fabian -X (ma
n Biscevic
Systems Architect, Bahnhof AB
Mobile: +46 76 111 01 24
E-mail: john.bisce...@bahnhof.net
From: vpp-dev@lists.fd.io on behalf of JB
Sent: Friday, October 19, 2018 3:19 PM
To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco);
vpp-dev@lists.fd.
Hello Florin,
Brilliant, that does seem to address it.
We'll patch it tomorrow.
Much appreciated.
Thanks,
John
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10898): https://lists.fd.io/g/vpp-dev/message/10898
Mute This Topic: https://lists.fd.i
Hi Dave,
We have not configured LISP-GPE
Could it be that VPP received an encapsulated packet it wasn't expecting
causing it to crash? That'd be dangerous
I'll have a look at the page for bug reports!
Thanks,
John
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this gr
Hello,
I've encountered a crash I've not seen posted anywhere.
We have a test setup running NAT and on average around 5 Gbps/500 kpps of
traffic. After 24-48 hours, VPP crashes with the following error:
vnet[18358]: next_index_to_iface:101: next_index not associated to an interface!
vnet[18358]
#vpp_stability
Hi John,
Fix in master and stable/1810 branch
Matus
From: vpp-dev@lists.fd.io On Behalf Of JB
Sent: Friday, October 19, 2018 9:14 AM
To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco)
; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet error-drop with fragmented
packets through NAT
#vpp_stability
Hi John,
There is bug in NAT code for ICMP fragments. I will fix it as soon as possible.
Thanks,
Matus
From: vpp-dev@lists.fd.io On Behalf Of JB
Sent: Thursday, October 18, 2018 12:48 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Packet error-drop with
Hello,
We've got a NAT44 setup configured with separate local and outside linknets,
where the internal NAT pool resides on a different subnet and is translated to
an outside different subnet.
When sending, in this case ICMP packets of size 1500 bytes, to 8.8.8.8 we get
no response back from th
Argh, I had written up a response but accidentally sent it to only Sandeep
We've also hit a snag with this. We are attempting to send TCP traffic upwards
to FRR for the purpose of using BGP but have hit this snag. We need BGP to not
only update VPPs FIB but also to receive updates over BGP via V
38 matches
Mail list logo
