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
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
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
#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
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]
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 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
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.
...@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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
-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
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@
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
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
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
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 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
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,
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
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 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 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
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,
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
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.
-=-=-=-=-=-=-=-
38 matches
Mail list logo
