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@lists.fd.io> au nom de "Dmitry Vakhrushev via Lists.Fd.Io" <dmitry=netgate....@lists.fd.io> Répondre à : "dmi...@netgate.com" <dmi...@netgate.com> Date : vendredi 2 août 2019 à 11:53 À : "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Cc : "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> 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.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13668): https://lists.fd.io/g/vpp-dev/message/13668 Mute This Topic: https://lists.fd.io/mt/32688963/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452 Mute #nat44: https://lists.fd.io/mk?hashtag=nat44&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
