Hi Elias, so there are two ways of solving this:
1. don’t support such a static mapping (i.e. refuse to create it) 2. make it work for #2 your snat_hairpinning fix might be the right idea. If there is really no change then there is no point doing an extra lookup right? Would you mind pushing it to gerrit? It would be super cool if the change also contained a test case ;-) Thanks, Klement > On 2 Dec 2020, at 18:24, Elias Rudberg <elias.rudb...@bahnhof.net> wrote: > > Hi Klement, > >>> an existing static NAT mapping that maps that IP address on the >>> inside to the same IP address on the outside. > >> what is the point of such static mapping? What is the use case here? > > We are using VPP for endpoint-independent NAT44. Then all traffic from > outside is normally translated by NAT dynamic sessions but we have > special treatment of traffic to a certain IP address that corresponds > to our BGP (Border Gateway Protocol) traffic, that should not be > translated, so then we have such a static mapping for that. If we do > not have this static mapping then VPP tries to translate our BGP > packets and then BGP does not work properly. > > It may be possible to do things differently so that no such mapping > would be needed, but we have been using such a mapping until now and > things have worked fine apart from this infinite loop issue, that > happens when a client from inside happens to send something to our > special BGP IP address that is intended to be used from the outside. > That IP address is normally not used by traffic from clients, the > normal thing is for the router to communicate with the VPP server using > that address, from outside. This is why the out-of-memory problem has > appeared random and hard to reproduce earlier, it just happened when a > client behaved in an unusual way, that did not happen very often but > when it did, we got the out-of-memory crash and now we finally know > why. Now that we know, we can easily reproduce it, it is not really > random it just seemed that way. > > Anyway, even if it would be unusual and possibly a bad idea to have > such a static mapping, do you agree that VPP should handle the > situation differently? > > Best regards, > Elias >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18234): https://lists.fd.io/g/vpp-dev/message/18234 Mute This Topic: https://lists.fd.io/mt/78662322/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
