Skip to content

SAI Ambiguities

Jump to bottom Edit New page
Vladimir Gurevich edited this page Jan 29, 2016 · 18 revisions

Introduction

The original SAI specification lacks a number of important details, describing both the expected behavior of the dataplane and the expected behavior of the API itself. While trying to implement a formal dataplane model of SAI, we came up with a number of questions and this page contains the current interpretations, derived in the discussions with SAI authors (Microsoft).

Parsing and packet validation

How does the switch determine if packet contains a VLAN tag?

  • The assumption is that the dataplane automatically recognizes the standard value of 0x8100 as TPID. This is the one and only value -- all others (e.g. 0x9100, 0x88a8) are not recognized.

Are priority-tagged packets “tagged” or “untagged” for the purposes of DROP_TAGGED/DROP_UNTAGGED?

  • MSFT to think about it

Are there any additional packet verification rules?

  • Yes, the packets are subject to the standard IEEE checks and must be dropped if one of them fails:

    • Ethernet packets with MACSA[40]==1 (multicast source address) are not allowed
    • Ethernet packets with MACSA==00:00:00:00:00:00 are not allowed
    • Ethernet packets with MACDA==00:00:00:00:00:00 are not allowed
    • Ethernet packets with MACSA == MACDA are not allowed

  • For processing beyond L2, SAI switch witch only accepts packets with EthernetII encapsulation. Ethernet packets with LLC/SNAP encapsulation (e.g IP packets with ProtocolID=0x0800) are not recognized as such and processed as regular L2 packets. This might be changed later.

Router Interfaces

What is the order of precedence between port-based and VLAN-based router interfaces?

The SAI API must prevent this from happening, by not allowing ports, for which a port-based interface is created, from being members of a VLAN and participating in L2 switching. Similarly, port-based interface cannot be created on a port that is currently a member of a VLAN.

If a port-based router interface is created on a port, that port can only accept untagged packets.

  • Default VLAN can (and should) still be set on a port.
  • MSFT to think about priority-tagged packets case (they might be still allowed)

Ingress Functionality

What packets are acceptable on a port for which a port-based Router Interface has been created?

  • MSFT to think about which packets are acceptable and consult with other participants
    • The router can only process IPv4 and IPv6 packets and must drop all others
    • Any other ingress packet of interest to L3 stack, e.g. ARP, must be trapped before it reaches the router

What packets are acceptable on a VLAN for which a VLAN-based Router Interface has been created?

  • Creation of a VLAN-based router interface should not affect L2 switching functionality. All non-L3 packets (that are not trapped) should go through normal L2 switching process

  1. Ingress functionality:

    • Which packets are subject to routing functionality: just IPv4 and IPv6? What about ARP?

      • See above

    • If neither SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS, nor SAI_SWITCH_ATTR_SRC_MAC_ADDRESS are set, does it mean that ALL packets ingressing on a given port/VLAN will go to L3 processing, or none?

    -   SRC\_MAC\_ADDRESS must always be set (at least for
    the switch)
-   It’s OK to create many router interfaces with different
    SRC\_MAC\_ADDRESS

    • While the attribute name is SRC_MAC_ADDRESS, doesn’t it mean that packets with the given Destination MAC address need to match? It probably should have been called MAC_ADDRESS (without SRC)

      • MSFT: Think about separating into Ingress and Egress Routing Interfaces

  2. It is not clear what kind of MAC addresses are allowed for SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS and SAI_SWITCH_ATTR_SRC_MAC_ADDRESS. Are multicast addresses allowed, for example? How about broadcast or all-zeroes?

    • For now use Unicast MAC addresses

  3. Is SAI_ROUTER_INTERFACE_ATTR_MTU an ingress or egress parameter (or both)?

    • Both

  4. Router interfaces are also used in the neighbor objects. However, it is not explicitly specified what happens. Do they always set MACSA=RouterMac and the new VLAN ID?

    • For port-based interfaces VLAN_ID is irrelevant (see below)

  5. What about port-based Router Interfaces? What do they provide? Just MACSA or VLAN_ID which is the default on a port?

-   Port-based router interfaces provide both MAC SA and the
    egress port.

  1. Should the VLAN, specified as SAI_ROUTER_INTERFACE_ATTR_VLAN_ID exist? What if it is removed after the interface has been created (SAI_STATUS_OBJECT_IN_USE)?

    • SAI must enforce consistency

  2. Same thing for SAI_ROUTER_INTERFACE_ATTR_VIRTUAL_ROUTER_ID? What if the virtual router is removed (SAI_STATUS_OBJECT_IN_USE)?

    • SAI Enforces consistency

########## Virtual Routers

  1. Which Admin state has precedence, virtual router or router interface admin state?

    • It’s an AND

  2. Is SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS ignored if you have a virtual router without SAI_ROUTER_INTERFACE_ATTR_SRC_MAC_ADDRESS attribute?

    • Correct

########## Routes & NextHops

  1. Route maps (vr_id, destination (IP prefix)) to the nexthop ID

  2. Nexthop Id resolves into (IP address, router interface)

  3. (IP address, router interface) is looked up in the neighbor table, gives us MAC DA.

  4. MAC DA is looked up in FDB. Where does vlan_id come from? Probably router interface, but what if it is port-based?

    • FDB is looked up only for VLAN-based Router Interfaces

  5. No words about URPF checks

    • Not yet defined

########## Neighbors

It sounds like the neighbor table can be used as a host route table unless SAI_NEIGHBOR_ATTR_NO_HOST_ROUTE is set to true. What’s the priority between that entry and an entry in the routing table? Also, lookup in the neighbor table is done using (IP, router_interface_ID), not (IP, vr_id).

  • MSFT to think about it. My proposal: If SAI_NEIGHBOR_ATTR_NO_HOST_ROUTE if FALSE, that means that an entry is automatically added to the route table, just as a convenience.

########## LAGs

  1. it is not clear where lag_id can be used. The spec is vague. For example, can a router interface be created for a LAG? If yes, what’s the VLAN ID of the egress packet? Depends on a port?

    • MSFT to clarify

  2. Is it OK to add the same port to to a LAG multiple times?

    • No

  3. Is it OK for a port to be added to multiple LAGs? How ingress LAG is resolved?

    • No

  4. Are port-based router interfaces looked up using the ingress port or ingress LAG?

    • Yes

########## SAI Status Codes

  1. SAI_STATUS_INVALID_VLAN_ID does it mean that the VLAN hasn’t been created or that VLAN ID is simply out of 0..4095 (or is it 0..4094, 1..4095, 1..4094?) range?

    • MSFT to think about it

########## STP

  1. How exactly LEARNING, FORWARDING and BLOCKING states are defined (since there is no BPDU definition around)?

    • MSFT to think about it. 01:80:C2:xx:xx:xx ? Something else?
    • Make sense to add DISABLED state

  2. What happens if a VLAN is added to multiple STP VLAN Lists?

    • STP group is a VLAN property

########## ACL

  1. What’s the semantics of SAI_ACL_TABLE_ATTR_PRIORITY? Is “Priority 0” highest or lowest?

    a. Priority 0 is lowest

Add a custom footer
Add a custom sidebar
Clone this wiki locally