-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds dash underlay routing functionality #402
Conversation
@@ -44,8 +44,7 @@ | |||
'sai_ip_addr_family_t': 'u32', | |||
'sai_uint32_t': 'u32', | |||
'sai_uint64_t': 'u64', | |||
'sai_mac_t': 'mac', | |||
'sai_ip_prefix_list_t': 'ipprefixlist' | |||
'sai_mac_t': 'mac' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need this removed ?
@@ -548,4 +545,4 @@ def write_sai_files(sai_api): | |||
write_sai_fixed_api_files(sai_api_full_name_list) | |||
|
|||
if args.print_sai_lib: | |||
print(json.dumps(sai_api, indent=2)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why change this ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make sure other people changes do not get reverted
@@ -140,7 +139,7 @@ Metering is essential for billing the customers and below are the high-level req | |||
- Mapping table based metering - E.g For specific destinations within the mapping table that must be billed separately | |||
- Policy in the metering context refers to metering policy associated to Route tables. This is not related to ACL policy or any ACL packet counters. | |||
- If packet flow hits multiple metering buckets, order of priority shall be **Policy->Route->Mapping** | |||
- User shall be able to override the precedence between Routing/Policy and Mapping buckets by setting an _override_ flag. When policy is enabled for a route, it takes higher precedence than routing and mapping metering bucket unless _override_ flag is set in which case Mapping takes precedence | |||
- User shall be able to override the precedence between Routing and Mapping buckets by setting an _override_ flag. When policy is enabled for a route, it takes higher precedence than routing and mapping metering bucket. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the changes to this section, acl tags and fastpath sections intentional ? It seems to be reverting a prior commit. Can you plz check ?
Merge error, replaced by PR 404 |
Description of PR
This PR is the start for the underlay implementation in BMv2 of the design mentioned in the dash hld under swss lite
The focus of this PR is on introducing the implementation of SAI call for "SAI_OBJECT_TYPE_ROUTE_ENTRY".
The keys implemented are "switch_id", "vr_id", "destination".
The attributes implemented are "SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID". In this PR we have added support for next hop type "SAI_OBJECT_TYPE_PORT". Other types of next_hop_id can be implemented in subsequent PR's.
DASH-libsai code generator added support for fixed SAI headers.
It serves as a foundational step for future implementations, which aim to comprehensively cover the entire underlay scenario.
This PR lays the groundwork for further advancements in addressing the broader scope of the issue at hand.
Also it partially addresses #236 and test cases to the CI to ensure proper functionality
What is the motivation for this PR?
In summary, the motivation for this PR is to enable underlay support in BMv2 and implement the necessary SAI-Thrift calls to ensure the correct functionality of the routing table in the context of #236.
Functionality
The current implementation defaults to an "echo" behavior, where the packet is reflected back on the same port it arrived.
However, this behavior has been modified by incorporating a routing table. As a result, when there is no match in the routing table, the packet continues to be reflected on the same port.
In this PR, when a route is matched in the routing table, the packet is directed to a different port as specified by the matching route.
Main Changes
match)
How did you verify/test it?
Can run the following test cases successfully: