SD-WAN

 View Only
last person joined: 11 days ago 

Ask questions and share experiences with SD-WAN and Session Smart Router (formerly 128T).
  • 1.  Seeking clarification on device-interface types and when to use them.

     
    Posted 08-03-2018 00:00
    (Running 3.2.5) There are multiple device-interface types available when creating a new device-interface on a 128T router. Ethernet, T1, LTE, and PPPoE are all similar in that if the router has one of these configured it can use it for packet-processing. When selected, 128T will grab any of these interfaces and they will no longer be available to the host. KNI interfaces can then be used to provide host access to the forwarding plane of the router.

    When you select type = 'kni', you are then prompted to select a KNI mode of bridged, host, or vhost. What are the differences between these modes, and when would you use one over the other?


  • 2.  RE: Seeking clarification on device-interface types and when to use them.

     
    Posted 08-03-2018 00:00

    @Jason, I will pile on here, to drill down further into the weeds: what is the purpose of having a setting in device-interface, forwarding = TRUE/FALSE?? I noticed that for Ethernet-type interfaces setting this parameter to false makes the device visible in Linux, meaning we probably disable DPDK for that device? But to what end? Why would one want to do that? What does having a non-forwarding? interface in the router buy me?



  • 3.  RE: Seeking clarification on device-interface types and when to use them.

    Posted 08-03-2018 00:00

    @Jason The valid types are ethernet, pppoe, host, bridged, LTE, and t1. Kni type is deprecated option and should not be used. This was the old way configuration and the only reason it is an option was for backward compatibility. This will be obsolete or removed in release 4.0.

     

    In the old configuration there were only 2 types - ether net and kni. And once kni type as selected, each of LTE, PPPoE, etc were modes within it. But instead of having kni as type, we started using the actual mode as a type (hence the LTE and PPPoE types are there now at the same level as ethernet). Kni types and its related modes are deprecated and should not be used.

     

    @Abilash Menon - if I missed anything.

     

    ​​


  • 4.  RE: Seeking clarification on device-interface types and when to use them.

    Posted 08-03-2018 00:00

    @Gene 

    This flag is there for us to mainly conform to the appliance model. In appliance model, users should be configuring all their interfaces using 128T configuration. For ethernet interfaces, the forwarding flag is used to indicate if we want 128T to take over the interface and allow it to be used for our flow or sessions. If its not a forwarding interface, 128T forwarding plane will not be using that interface for forwarding decisions (ingress or egress).

     

    As for non-ethernet interfaces like host and bridge, the forwarding false has no meaning. A must statement has been added for that to make sure the forwarding flag cannot be configured for the non ethernet types. For LTE, PPPoE, and T1, it still holds and means that these will not be a forwarding interface on 128T. The IP address on the non-forwarding interface is being used to populate the global init node ip as well. This is coming in 3.2.7 or 4.0 release.

     

    @Abilash Menon for any additional information.

    ​​


  • 5.  RE: Seeking clarification on device-interface types and when to use them.

     
    Posted 08-03-2018 00:00

    This is great info regarding the Forwarding ON/OFF? switch @Victoria Smiley and @Abilash Menon!!

    I do have a follow-up question: can I configure the same Ethernet interface twice? One instance as a forwarding type, and the other as non-forwarding. This way I can control what happens to that interface when 128T Service is running and when it?s not. Today we do that by configuring same interface in both Linux ifcfg file and in 128T (the latter being a forwarding interface).

    ​​


  • 6.  RE: Seeking clarification on device-interface types and when to use them.

    Posted 08-03-2018 00:00

    @Gene This is a flag on the device interface. You should not be creating 2 instances of the same interface. A non-forwarding interface means its still available as a linux interface even when 128T runs, just that 128T does take it over. If you create 2 instances, 128T will take over the interface and this interface will no longer be in linux. In case you need some handling that needs to be done after 128T shutdown, that could be incorporated in our data model (since we are in appliance mode), but we may need to understand the requirements.

     

    Message at @Abilash Menon with those reqs.

    ​​


  • 7.  RE: Seeking clarification on device-interface types and when to use them.

    Posted 12-04-2018 15:20
    Is there a way to configure management interface and a forwarding interface on one device Interface?
    I've read the "HOWTO: Shared Interface for Management and Data Plane" document but KNI is depricated and will be removed in the newer 128T version.
    We need this for Appliance with 3 physical Interfaces: one LAN-int two WAN-int. 
    Router on the stick is no option.

    Thank you in advance.


    ------------------------------
    Michael Uwannah
    Ahaus
    ------------------------------



  • 8.  RE: Seeking clarification on device-interface types and when to use them.

     
    Posted 12-22-2018 06:55
    Hi Michael, thanks for the question. We need to update the document, as it apparently still refers to the old method of configuring KNI. As mentioned earlier in this thread, the type=kni setting would compel you to then configure a mode=host or mode=bridged. This has been replaced by type=host and type=bridged. No functionality was removed, only the configuration model has shuffled around a bit.

    ------------------------------
    pt.
    ------------------------------



  • 9.  RE: Seeking clarification on device-interface types and when to use them.

     
    Posted 08-03-2018 00:00

    Thanks, @Victoria Smiley and @Abilash Menon.

     

    @Maxim sent me a complete functional specification of the feature we are discussing here, and I did find my use case in that document. We are all set.

    ​​​