SD-WAN

 View Only
last person joined: 23 hours ago 

Ask questions and share experiences with SD-WAN and Session Smart Router (formerly 128T).
  • 1.  TIL: tenant membership changes in 4.0

     
    Posted 04-20-2019 11:59
    Hi everyone, I ran into something this past week that I wanted to share here so others don't have the same struggles I do.

    Historically (and this goes WAAAAY back), there was one way to assign tenancy to inbound packets: adding a tenant to a network-interface. In newer software (circa 3.1),  we gave administrators the ability to assign tenancy by neighborhood. By configuring a member in a tenant, you can identify CIDR blocks within a neighborhood that are associated with that tenant. However, there was a strict order of precedence in these tenant configurations: if you assigned a tenant to an interface, it would treat anything arriving on that interface as belonging to the tenant -- no questions asked. Under the hood, 128T creates a source prefix of 0.0.0.0/0 for that interface within its "source tenant table." Configuring tenant members would not apply.

    In 4.0, however, there was a behavior change. If you configure both interface tenancy and members within that tenant, 128T will only add prefixes to the source tenant table for the prefix(es) you specify. All packets that arrive on the interface that are not from one of the specified prefixes will be dropped. (This is what bit me this past week, in case you were wondering.)

    Interestingly, if you add a tenant to an interface, 128T will add prefixes for that tenant and all of the children of that tenant for the prefixes defined in those tenants' members. This is a great addition to our software, as it lets you really lock down the interface to specific prefixes, and deny everything else.

    The "source tenant table" governs all of this. To investigate the contents of the source tenant table, use the PCLI command "show tenant members". Here's a configuration example that may help illustrate some of these concepts:

    tenant  parent
        name  parent
    exit
    
    tenant  child1.parent
        name    child1.parent
    
        member  LAN
            neighborhood  LAN
            address       192.168.128.0/25
        exit
    exit
    
    tenant  child2.parent
        name    child2.parent
    
        member  LAN
            neighborhood  LAN
            address       192.168.128.128/25
        exit
    exit
    
    network-interface  lan0
        name                   lan0
        global-id              1
        description            "LAN VLAN 0"
        vlan                   0
        neighborhood           LAN
            name      LAN
            topology  spoke
        exit
        tenant                 parent
        inter-router-security  internal
        address                192.168.128.1
            ip-address     192.168.128.1
            prefix-length  24
        exit
    exit​

    And here's the output of "show tenant members" for this configuration:
    admin@hari.fox# show tenant members
    Sat 2019-04-20 15:59:01 UTC
    
    Node: hari
    
    ============ ========= ============== ================= ==================== ===============
     Device I/F   VLAN ID   Network I/F    Network I/F IP    Source IP Prefix     Tenant
    ============ ========= ============== ================= ==================== ===============
     enp2s0             0   lan0           192.168.128.1     0.0.0.0/0            parent
     enp2s0             0   lan0           192.168.128.1     192.168.128.0/25     child1.parent
     enp2s0             0   lan0           192.168.128.1     192.168.128.128/25   child2.parent
     kni254             0   controlKniIf   169.254.127.126   0.0.0.0/0            <global>


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


  • 2.  RE: TIL: tenant membership changes in 4.0

    Posted 04-22-2019 21:54
    One other interesting behavior regarding the use of tenant prefixes caught me last week.  Tenancy using neighborhood prefix(es) will override waypoint behavior for remote waypoint addresses matching the tenant.  So, for inbound SVR traffic with a remote waypoint address matching a tenant prefix (assigned to that interface), the metadata will be ignored and the traffic will be treated with tenant routing policy.  This may happen when the tenant prefixes are broad on combined SVR and non-SVR interfaces.  Be sure to exclude remote waypoint addresses from tenant allow prefixes, as applicable.

    ------------------------------
    Don Troshynski
    CTO - Global Sales
    ------------------------------



  • 3.  RE: TIL: tenant membership changes in 4.0

     
    Posted 04-25-2019 00:46
    Good catch Don! As a best practice, it is not recommended to assign a tenant or use tenant prefixes on a WAN interface (SVR peering interface). The use case you are probably referring too and what I have used in the past as well that goes against this best practice is where you have a combined interface (WAN+LAN). Does anyone else here have any use cases where you might assign a tenant or use tenant prefixes on a WAN interface?

    ------------------------------
    Adam Morris
    Sales Engineer
    WA
    (206) 617-4999
    ------------------------------



  • 4.  RE: TIL: tenant membership changes in 4.0

     
    Posted 04-25-2019 09:17
    Hi Adam, I respectfully disagree. There are certainly valid use cases for using tenant prefixes on WAN interfaces.
    1. Use of a "blacklist" tenant. This is a big one. For services that you're offering on the internet (scope = public), you're invariably going to be found by the unwashed masses on the Internet and become a target of attack. By systemically placing these sources into a blacklist tenant, you can silently drop that traffic at the edge of your network. I wrote a blog post on this last Christmas, and I continue to use it successfully on my own network, and strongly advocate for others to explore it on their own.
    2. Creating "ACL groups." Define a CIDR block of addresses as part of a "remote management" group, and selectively allow this tenant access to services on your network, and now it's reachable by those folks via the public internet.


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



  • 5.  RE: TIL: tenant membership changes in 4.0

     
    Posted 04-25-2019 11:51
    Thanks PT! I definitely agree those are 2 other use cases where a tenant on the WAN solves the issue.

    ------------------------------
    Adam Morris
    Sales Engineer
    WA
    (206) 617-4999
    ------------------------------



  • 6.  RE: TIL: tenant membership changes in 4.0

     
    Posted 07-16-2019 11:55
    @Adam, so, the use case I have is screaming for this functionality.  I have two data centers (actually three) that are SVRed on the back-end to provide next peer session resiliency.  Obviously there are also users/tenants who originate traffic into those same interfaces, as branches host some of the services.

    What to do?

    ------------------------------
    Gene Shtirmer
    Sales Engineer
    Randolph NJ
    (973) 610-5676
    ------------------------------



  • 7.  RE: TIL: tenant membership changes in 4.0

     
    Posted 07-16-2019 11:52
    @Don Troshynski, are you saying this only happens when you assign tenant using neighborhood?  Or will this also be the case if tenants is assigned in the interface? ​

    ------------------------------
    Gene Shtirmer
    Sales Engineer
    Randolph NJ
    (973) 610-5676
    ------------------------------



  • 8.  RE: TIL: tenant membership changes in 4.0

    Posted 07-17-2019 14:37
    @Gene, I recall that neighborhood prefixes are the mechanism to steer traffic to the Service Area.  I just ran a quick test and assignment of a default tenant to the interface did not affect SVR peering on those interfaces.  ​

    ------------------------------
    Don Troshynski
    CTO - Global Sales
    ------------------------------



  • 9.  RE: TIL: tenant membership changes in 4.0

     
    Posted 07-17-2019 14:40
    @Gene, yes this caveat is only when the tenancy is assigned using a neighborhood to specify specific CIDR blocks. If you are assigning tenancy at the interface level, this should work as expected.

    ------------------------------
    Adam Morris
    Sales Engineer
    WA
    (206) 617-4999
    ------------------------------



  • 10.  RE: TIL: tenant membership changes in 4.0

     
    Posted 09-20-2019 14:43
    @peetee, I am not seeing the "4.X" behavior you describe above in release 4.2.0.  I configured a tenant with a member/neighborhood/prefix, and assigned this tenant to an interface.  In the tenant source table I see the quad zero source prefix for that tenant/interface (the prefix I assigned to the tenant is not showing up anywhere in the source tenant table).  Isn't that what you describe as "3.1" behavior?

    ------------------------------
    Gene Shtirmer
    Sales Engineer
    Randolph NJ
    (973) 610-5676
    ------------------------------