locked Feature: Update of nat44 addresses VRF after changing VRF on interfaces #vpp #nat44


Dmitry Vakhrushev
 

Hello!

I have a suggestion to add a feature to update NAT addresses VRF location when the VRF on the interface has been changed.
I've prepared a patch with a test which does it and checks this behavior. 
I want to push these changes, but want to ask first of your opinion.
Is it a good point to add this change to VPP?
 
Test network map:
PC1 <---> <sw_if_index 2> PC(VPP) <sw_if_index 3><---> PC2

Used test sequence:
sw_interface_set_flags sw_if_index 2 admin-up
sw_interface_set_flags sw_if_index 3 admin-up
sw_interface_add_del_address sw_if_index 2 192.168.1.1/24
sw_interface_add_del_address sw_if_index 3 10.10.10.1/24
nat44_interface_add_del_feature sw_if_index 2 in
nat44_interface_add_del_feature sw_if_index 3 out
nat44_add_del_address_range 10.100.200.33 

>> nat44_add_del_address_range 10.100.200.33 - this command add fib record to default VRF (0)

-> Now we change VRF tables on interfaces:
ip_table_add_del table 1 add
sw_interface_add_del_address sw_if_index 2 0.0.0.0/0 del del-all
sw_interface_set_table sw_if_index 2 vrf 1
sw_interface_add_del_address sw_if_index 2 10.10.10.1/24
 
sw_interface_add_del_address sw_if_index 3 0.0.0.0/0 del del-all
sw_interface_set_table sw_if_index 3 vrf 1
sw_interface_add_del_address sw_if_index 3 10.10.30.1/24
 
-> Now NAT address is left in VRF-0, but interfaces in other VRF and now NAT isn't working.

sw_interface_add_del_address sw_if_index 2 0.0.0.0/0 del del-all
sw_interface_set_table sw_if_index 2 vrf 0
sw_interface_add_del_address sw_if_index 2 10.10.10.1/24
 
sw_interface_add_del_address sw_if_index 3 0.0.0.0/0 del del-all
sw_interface_set_table sw_if_index 3 vrf 0
sw_interface_add_del_address sw_if_index 3 10.10.30.1/24
 
-> now NAT is working again.

P.S
NAT can be VRF independent (VRF = ~0) but the suggested case is possible too.


Neale Ranns
 

 

Hi Dmitry,

 

It’s definitely a good idea to add changes that prevent things breaking 😊 The question is how do you do it?

You’ll have noticed in your testing that the following sequence is disallowed:

 

DBGvpp# loop cre

DBGvpp# ip table add 2

DBGvpp# set int ip addr loop0 10.10.10.10/24

DBGvpp# set int ip table loop0 2

set interface ip table: IP addresses are still present on loop0

 

If you want to change the table bound to an interface first you have to remove all the addresses it has, i.e. we block the requested change – there are many use cases in VPP were it is implicit that a config must be fully undone before it can be redone. The alternative approach would be to internally remove the addresses, rebind the table, then reapply the addresses, i.e. we undo and redo existing config upon the change. (this doesn’t work for addresses since they might clash with other interfaces in the new VRF).

 

Which of these two approaches would you take?

 

Regards,

neale

 

 

De : <vpp-dev@...> au nom de "Dmitry Vakhrushev via Lists.Fd.Io" <dmitry=netgate.com@...>
Répondre à : "dmitry@..." <dmitry@...>
Date : vendredi 2 août 2019 à 11:53
À : "vpp-dev@..." <vpp-dev@...>
Cc : "vpp-dev@..." <vpp-dev@...>
Objet : [vpp-dev] Feature: Update of nat44 addresses VRF after changing VRF on interfaces #vpp #nat44

 

Hello!

I have a suggestion to add a feature to update NAT addresses VRF location when the VRF on the interface has been changed.
I've prepared a patch with a test which does it and checks this behavior. 

I want to push these changes, but want to ask first of your opinion.

Is it a good point to add this change to VPP?

 

Test network map:
PC1 <---> <sw_if_index 2> PC(VPP) <sw_if_index 3><---> PC2

Used test sequence:

sw_interface_set_flags sw_if_index 2 admin-up

sw_interface_set_flags sw_if_index 3 admin-up

sw_interface_add_del_address sw_if_index 2 192.168.1.1/24

sw_interface_add_del_address sw_if_index 3 10.10.10.1/24

nat44_interface_add_del_feature sw_if_index 2 in

nat44_interface_add_del_feature sw_if_index 3 out
nat44_add_del_address_range 10.100.200.33 


>> nat44_add_del_address_range 10.100.200.33 - this command add fib record to default VRF (0)

-> Now we change VRF tables on interfaces:

ip_table_add_del table 1 add

sw_interface_add_del_address sw_if_index 2 0.0.0.0/0 del del-all

sw_interface_set_table sw_if_index 2 vrf 1

sw_interface_add_del_address sw_if_index 2 10.10.10.1/24

 

sw_interface_add_del_address sw_if_index 3 0.0.0.0/0 del del-all

sw_interface_set_table sw_if_index 3 vrf 1

sw_interface_add_del_address sw_if_index 3 10.10.30.1/24

 

-> Now NAT address is left in VRF-0, but interfaces in other VRF and now NAT isn't working.


sw_interface_add_del_address sw_if_index 2 0.0.0.0/0 del del-all

sw_interface_set_table sw_if_index 2 vrf 0

sw_interface_add_del_address sw_if_index 2 10.10.10.1/24

 

sw_interface_add_del_address sw_if_index 3 0.0.0.0/0 del del-all

sw_interface_set_table sw_if_index 3 vrf 0

sw_interface_add_del_address sw_if_index 3 10.10.30.1/24

 

-> now NAT is working again.

P.S
NAT can be VRF independent (VRF = ~0) but the suggested case is possible too.