Uploaded image for project: 'vpp'
  1. vpp
  2. VPP-1766

TAP auto-removal leaves orphaned routes that cannot be changed/deleted

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Open
    • Icon: High High
    • 19.08
    • None
    • None
    • None

      Developers of VPP control planes are advised to never delete interface before associated network items, such as routes, ARPs, NAT mappings, etc.
      However, this commit breaks the rule on the VPP side - the TAP interface is automatically removed when the Linux side is lost, but the references to its sw_if_index are not cleaned up across VPP. Routes, ARPs and eveything that was associated to that interface will remain configured with now invalid sw_if_index. What is worse is that the next created interface will reuse the sw_if_index and inherit all these configuration items (with the exception of routes that cannot be changed/deleted and will keep dropping matched packets).

      Here is an example scenario where routes get orphaned by VPP's actions and cannot be fixed via CLI or binary APIs:

      // created interface, added route
      SCRIPT: tap_create_v2 id 4294967295 host-if-name tap-2870264825 
      SCRIPT: sw_interface_tag_add_del sw_if_index 1 tag vpp-tap 
      SCRIPT: sw_interface_set_flags sw_if_index 1 admin-up 
      SCRIPT: ip_route_add_del 192.168.20.0/24 [sw_if_index 1 192.168.11.2 weight 0 preference 0 type 0 proto 0 flags 0 n_labels 0 table-id 0 rpf-id 0]
      SCRIPT: sw_interface_set_table sw_if_index 1 
      SCRIPT: sw_interface_set_table sw_if_index 1 ipv6 
      SCRIPT: sw_interface_add_del_address sw_if_index 1 192.168.11.1/24
      

      The route is displayed by „show ip fib“ as:

      192.168.20.0/24
        unicast-ip4-chain
        [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:15 to:[5:480]]
          [0] [@5]: ipv4 via 192.168.11.2 tap0: mtu:9000 0e168dadc9d902feedf4a6650800
      

      When container to which the TAP was attached is killed, the interface dissapears and the route starts to DROP:

      192.168.20.0/24
        unicast-ip4-chain
        [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:14 to:[5:480]]
          [0] [@0]: dpo-drop ip4
      

      Tried to remove the route (in 2 ways), but with no luck:

      SCRIPT: ip_route_add_del del 192.168.20.0/24 [sw_if_index 1 192.168.11.2 weight 0 preference 0 type 0 proto 0 flags 0 n_labels 0 table-id 0 rpf-id 0]   // <- trying to remove route as was configured (returns error)
      SCRIPT: ip_route_add_del del 192.168.20.0/24 [sw_if_index 0 192.168.11.2 weight 0 preference 0 type 2 proto 0 flags 0 n_labels 0 table-id 0 rpf-id 0]   // <- trying to remove route as DROP (without error and effect)
      

      Also tried to re-create the interface and update the route then:

      SCRIPT: tap_create_v2 id 4294967295 host-if-name tap-2870264825   // <- same sw_if_index as the original interface, but we cannot rely on that since another interface could be created in the meantime
      SCRIPT: sw_interface_tag_add_del sw_if_index 1 tag vpp-tap 
      SCRIPT: sw_interface_set_flags sw_if_index 1 admin-up 
      SCRIPT: ip_route_add_del 192.168.20.0/24 [sw_if_index 1 192.168.11.2 weight 0 preference 0 type 0 proto 0 flags 0 n_labels 0 table-id 0 rpf-id 0]   // <- without error but also without effect (still as DROP route)
      

      VPP should either remove interface together with all the associated items or just leave it to control plane to take care of. Partial solution is not acceptable since it breaks consistency of VPP configuration state.

            sykazmi Mohsin Kazmi
            milanlenco Milan Lenco
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: