Signed-off-by: Neetha John nejo@microsoft.com
Why I did it
For storage backend, certain rules will be applied to the DATAACL table to allow only vlan tagged packets and drop untagged packets.
How I did it
Create DATAACL table if the device is a storage backend device
To avoid ACL resource issues, remove EVERFLOW related tables if the device is a storage backend device
How to verify it
Added the following unit tests
- verify that EVERFLOW acl tables is removed and DATAACL table is added for storage backend tor
- verify that no DATAACL tables are created and EVERFLOW tables exist for storage backend leaf
Why I did it
To further support parse out soc_ipv4 and soc_ipv6 out of Dpg:
<DeviceDataPlaneInfo>
<IPSecTunnels />
<LoopbackIPInterfaces xmlns:a="http://schemas.datacontract.org/2004/07/Microsoft.Search.Autopilot.Evolution">
<a:LoopbackIPInterface>
<ElementType>LoopbackInterface</ElementType>
<Name>HostIP</Name>
<AttachTo>Loopback0</AttachTo>
<a:Prefix xmlns:b="Microsoft.Search.Autopilot.NetMux">
<b:IPPrefix>10.10.10.2/32</b:IPPrefix>
</a:Prefix>
<a:PrefixStr>10.10.10.2/32</a:PrefixStr>
</a:LoopbackIPInterface>
<a:LoopbackIPInterface>
<ElementType>LoopbackInterface</ElementType>
<Name>HostIP1</Name>
<AttachTo>Loopback0</AttachTo>
<a:Prefix xmlns:b="Microsoft.Search.Autopilot.NetMux">
<b:IPPrefix>fe80::0002/128</b:IPPrefix>
</a:Prefix>
<a:PrefixStr>fe80::0002/128</a:PrefixStr>
</a:LoopbackIPInterface>
<a:LoopbackIPInterface>
<ElementType>LoopbackInterface</ElementType>
<Name>SoCHostIP0</Name>
<AttachTo>server2SOC</AttachTo>
<a:Prefix xmlns:b="Microsoft.Search.Autopilot.NetMux">
<b:IPPrefix>10.10.10.3/32</b:IPPrefix>
</a:Prefix>
<a:PrefixStr>10.10.10.3/32</a:PrefixStr>
</a:LoopbackIPInterface>
<a:LoopbackIPInterface>
<ElementType>LoopbackInterface</ElementType>
<Name>SoCHostIP1</Name>
<AttachTo>server2SOC</AttachTo>
<a:Prefix xmlns:b="Microsoft.Search.Autopilot.NetMux">
<b:IPPrefix>fe80::0003/128</b:IPPrefix>
</a:Prefix>
<a:PrefixStr>fe80::0003/128</a:PrefixStr>
</a:LoopbackIPInterface>
</LoopbackIPInterfaces>
</DeviceDataPlaneInfo>
Signed-off-by: Longxiang Lyu lolv@microsoft.com
How I did it
For servers loopback definitions in Dpg, if they contain LoopbackIPInterface with tags AttachTo, which has value of format like <server_name>SOC, the address will be regarded as a SoC IP, and sonic-cfggen now will treat the port connected to the server as active-active if the redundancy_type is either Libra or Mixed.
How to verify it
Pass the unittest.
Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
This reverts commit 90a849ea85.
#### Why I did it
The interfaces unit test did not cover some of the conditions in interfaces.j2 that was changed in #11204. Therefore reverting the change and add the tests before making the change to interfaces.j2.
#### How I did it
Git revert.
#### How to verify it
#### Which release branch to backport (provide reason below if selected)
- [ ] 201811
- [ ] 201911
- [ ] 202006
- [ ] 202012
- [ ] 202106
- [ ] 202111
- [ ] 202205
#### Description for the changelog
#### Link to config_db schema for YANG module changes
#### A picture of a cute animal (not mandatory but encouraged)
* [Interfaces] Modify template to support multiple management interfaces
* Modify minigraph to process interfaces in sorted order
Signed-off-by: Ubuntu <gechen@gechen-sonic-dev.d0r25nej54guppclip4gpy5b5a.jx.internal.cloudapp.net>
* Add UT minigraph
Signed-off-by: Ubuntu <gechen@gechen-sonic-dev.d0r25nej54guppclip4gpy5b5a.jx.internal.cloudapp.net>
* make case insensitve comparison
Signed-off-by: George Chen <gechen@microsoft.com>
* Use natural sort
Signed-off-by: George Chen <gechen@microsoft.com>
Co-authored-by: Ubuntu <gechen@gechen-sonic-dev.d0r25nej54guppclip4gpy5b5a.jx.internal.cloudapp.net>
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan arlakshm@microsoft.com
Why I did it
resolves#10761.
For VOQ chassis, the Recirc port, which was added for the Everflow, stays admin down after load minigraph.
This PR add the fix to make the recirc port as admin up
How I did it
The PR adds a change in minigraph.py, if port has role as Rec make the the port as admin-status up.
How to verify it
UT
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
Why I did it
To further add cable_type and soc_ipv4 field to table MUX_CABLE, this PR tries to parse the minigraph like the following:
```
<Device i:type="SmartCable">
<ElementType>SmartCable</ElementType>
<SubType>active-active</SubType>
<Address xmlns:d5p1="Microsoft.Search.Autopilot.NetMux">
<d5p1:IPPrefix>192.168.0.3/21</d5p1:IPPrefix>
</Address>
<AddressV6 xmlns:d5p1="Microsoft.Search.Autopilot.NetMux">
<d5p1:IPPrefix>::/0</d5p1:IPPrefix>
</AddressV6>
<ManagementAddress xmlns:d5p1="Microsoft.Search.Autopilot.NetMux">
<d5p1:IPPrefix>0.0.0.0/0</d5p1:IPPrefix>
</ManagementAddress>
<ManagementAddressV6 xmlns:d5p1="Microsoft.Search.Autopilot.NetMux">
<d5p1:IPPrefix>::/0</d5p1:IPPrefix>
</ManagementAddressV6>
<SerialNumber i:nil="true" />
<Hostname>svcstr-7050-acs-1-Servers0-SC</Hostname>
</Device>
<Device i:type="Server">
<ElementType>Server</ElementType>
<Address xmlns:d5p1="Microsoft.Search.Autopilot.NetMux">
<d5p1:IPPrefix>192.168.0.2/21</d5p1:IPPrefix>
</Address>
<AddressV6 xmlns:d5p1="Microsoft.Search.Autopilot.NetMux">
<d5p1:IPPrefix>fc02:1000::2/64</d5p1:IPPrefix>
</AddressV6>
<ManagementAddress xmlns:d5p1="Microsoft.Search.Autopilot.NetMux">
<d5p1:IPPrefix>0.0.0.0/0</d5p1:IPPrefix>
</ManagementAddress>
<Hostname>Servers0</Hostname>
</Device>
```
Signed-off-by: Longxiang Lyu lolv@microsoft.com
How I did it
get_mux_cable_entries will try to get the mux cable device from the devices list and get the cable type and soc ip address from the device definition.
How to verify it
Pass the unit-test
#### Why I did it
Fix several bugs:
1. If one vlan member belongs to multiple vlans, and if any of the vlans is "Tagged" type, we respect the tagged type
2. If one vlan member belongs to multiple vlans, and all of the vlans have no "Tagged" type, we override it to be a tagged member
3. make sure `vlantype_name` is assigned correctly in each iteration
#### How to verify it
1. Test the command line to parse a minigraph and make sure the output does not change.
```
./sonic-cfggen -m minigraph.mlnx20.xml
```
The minigraph is for HwSKU Mellanox-SN2700-D40C8S8.
2. Test on a DUT with HwSKU Mellanox-SN2700-D40C8S8
```
sudo config load_minigraph
show vlan brief
```
Checked the "Port Tagging" column in the output.
Why I did it
Config db schema generated by minigraph can’t pass yang validation, deployment_id can’t be none for yang validation.
How I did it
Update minigraph.py, skip deployment_id with None value
How to verify it
Run UT for sonic-config-enginue.
Run command 'sonic-cfggen -m tests/multi_npu_data/sample-minigraph-noportchannel.xml -p tests/multi_npu_data/sample_port_config-3.ini -n asic3 --print-data'.
Signed-off-by: Gang Lv ganglv@microsoft.com
Why I did it
ConfigDB schema generated by minigraph parser can't pass yang validation.
How I did it
Modify minigraph.py, and use 'state' to replace 'status'.
How to verify it
Run UT for sonic-config-engine.
Use minigraph parser to generate ConfigDB schema, and run yang validation.
Signed-off-by: Gang Lv ganglv@microsoft.com
What I did:-
Enhanced minigraph parser to parse interface name associated with static route nexthop
Why I did:-
One of the use case to support interface name is Chassis Packet. For Chassis Packet we have Static Routes configured to route traffic across line-card. If the FRR programs static route without the interface name then in case if the ip interface that is associated with the nexthop goes down FRR resolves static route nexthop over the default route as we have FRR config ip nht-resolve-via-default which causes undesired behavior. Having interface name with Static Route prevents recursive lookup on default route.
How I verify:
Updated unit-test cases
Manual verification
#### Why I did it
It should be handled by `ConfigDBConnector.typed_to_raw()`.
This is a bug for `sonic-cfggen -m --print-data` only
```
"PORTCHANNEL_MEMBER": {
"PortChannel0001|Ethernet112": {
"NULL": "NULL"
},
"PortChannel0002|Ethernet116": {
"NULL": "NULL"
},
"PortChannel0003|Ethernet120": {
"NULL": "NULL"
},
"PortChannel0004|Ethernet124": {
"NULL": "NULL"
}
},
```
But not appears in `sonic-cfgen -d --print-data`.
```
"PORTCHANNEL_MEMBER": {
"PortChannel0001|Ethernet112": {},
"PortChannel0002|Ethernet116": {},
"PortChannel0003|Ethernet120": {},
"PortChannel0004|Ethernet124": {}
},
```
Tested in a T0 KVM.
What I did:
Added option 'advertise':'true'/'false' to STATIC_TALE to control whether given route need to be advertise into BGP.
How I did:
Add a route in FRR with tag (1 for advertise and 2 for not advertise)
Create Route Map to match on tag as 1 and permit
Attach route-map to redistribute static.
Minigraph option to parse advertise option of Static Route.
Added get_system_mac support for cisco-8000 device
Why I did it
This is required to assign unique MACs to namespaces on Backend and Frontend asics
for cisco-8000 platforms
How I did it
Add vendor specific hook in get_system_mac. The MAC address are read from /profile.ini
file
How to verify it
config load_minigraph on a multi-asic system
config save
check mac addresses in DEVICE_METADATA section in each config_db json file
What I did:
Fix the typo in Internal Peer Group template for Packet-based Chassis.
Address Review comments of PR: [chassis-packet] minigraph parsing and BGP template changes #8966
- Static Route Parsing for Host
- Formatting of chassis port_config.ini
Signed-off-by: Neetha John <nejo@microsoft.com>
Why I did it
Storage T0's have all vlan members as tagged
How I did it
Since currently minigraph does not have a unique way to identify if a vlan member is tagged/untagged and to ensure other scenarios are not broken, the logic used is to just update the vlan member type as 'tagged' when we determine that it is a storage backend device. This change will apply only to storage backend T0's since storage backend T1's will not have vlan member information
How to verify it
Updated the storage backend T0 testcases to check for tagged vlan members
Added testcase to check if a T1 and backend T1 device generates an empty vlan member table
Existing vlan member testcases are good enough for checking if any regression has been caused for regular T0's
Build sonic_config_engine-1.0-py3-none-any.whl successfully
1. Changes for Generation LC-Graph for packet-based chassis.
2. Added Support Ipv6 Peering on Loopback4096 for voq also
3. Updated asic topology yml files to be offset of slot
4. Made slot_num to take string slot<number> instead of number
5. Consolidated template_dpg_voq_asic.j2 into dpg_asic.j2
6. Remove Loopback4096 from asic topology and parse as dut invertory for
multi-asic
7. Updated topo_facts parsing for asic topology_
8. Internal BGP Session rename from <VoqChassisInternal> to <ChassisInternal> and take switch_type as value.
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Why I did it
In the config_db.json generated by minigraph "admin_status" attribute is missing for the VOQ inband interface port in the PORT table.
How I did it
Changes done to add admin_status attribute for voq inband interface port, if it exists in the PORT table keys.
Why I did it
Allow deploying DHCPv6 servers following the implementation PR: #7772
How I did it
Add DHCPv6 to minigraph.py on sonic-cfggen tool and improve the unit test to cover this change.
How to verify it
Try to deploy a switch with DHCPv6 servers.
Signed-off-by: Shlomi Bitton <shlomibi@nvidia.com>
Signed-off-by: Neetha John <nejo@microsoft.com>
Why I did it
The current logic generates 'VLAN_SUB_INTERFACE' table if the device type is backend and cluster name contains 'str'. This is not a reliable method to determine a storage backend device
How I did it
Updated the logic to generate 'VLAN_SUB_INTERFACE' table if any of the following conditions hold true
- device is of type backend and ResourceType attribute is None
- device is of type backend and ResourceType attribute contains "Storage"
- device is of type backend and graph contains "Subinterface" section
Also updated the logic to set "is_storage_device" to True
- For Backend, if any of the above conditions hold true
- For Frontend, if ResourceType attribute contains "Storage"
How to verify it
Added new tests to verify the code changes and built sonic_config_engine-1.0-py3-none-any.whl successfully
Why I did it
portconfig.py gets PORT table from config_db if it is present. If not, port_config.ini files are parsed.
For multi-asic platform, if namespace is passed to get_port_config(), config_db connection was done to host namespace always and not to asic specific namespace.
Provides fix for: #7161
How I did it
Modify db connection function to connect to namespace config_db.
* [TPID CONFIG]TPID attribute Yang model and default TPID for Minigraph to configDB Changes
* Fixed alignment spacing issue, removed length and convert to use tpid_type typedef for both LAG and PORT tpid attribute, added description in port and portchannel leaf for the tpid attribute
Why I did it
The current code skips parsing bandwidth for DeviceMgmtLinks. We have a use case to set the speed for these type of links based on the bandwidth attribute in the minigraph
How to verify it
Ran sonic-cfggen on a minigraph and verified that interface of type DeviceMgmtLink has speed set in the PORT table from the bandwidth attribute in the minigraph
When FECDisabled is set to true in minigraph.py, push 'fec' 'none' explicitly to config_db. When 'fec' is defined in port_config.ini do not override it with 'rs' for 100G
This commit contains the following changes to support for configuring a VoQ switch using a minigraph.xml file.:
- Add support for system ports configuration to minigraph
- Add support for SwitchId, SwitchType and MaxCores to minigraph
- Add support for inband vlan configuration in minigraph
- `asic_name` is now a mandatory attribute in CONFIG_DB on VoQ switches
Co-authored-by: Maxime Lorrillere <mlorrillere@arista.com>
This commit has following changes:
* Add templates and code to support VoQ chassis iBGP peers
* Add support to convert a new VoQChassisInternal element in the
BGPSession element of the minigraph to a new BGP_VOQ_CHASSIS_NEIGHBOR
table in CONFIG_DB.
* Add a new set of "voq_chassis" templates to docker-fpm-frr
* Add a new BGP peer manager to bgpcfgd to add neighbors from the
BGP_VOQ_CHASSIS_NEIGHBOR table using the voq_chassis templates.
* Add a test case for minigraph.py, making sure the VoQChassisInternal
element creates a BGP_VOQ_CHASSIS_NEIGHBOR entry, but not if its
value is "false".
* Add a set of test cases for the new voq_chassis templates in
sonic-bgpcfgd tests.
Note that the templates expect the new
"bgp bestpath peer-type multipath-relax" bgpd configuration to be
available.
Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
Make sure Everflow always gets classified as Mirror table and not as Control Plane on multi-asic platforms.
Why I did:
In Multi-asic platforms we generate Everflow acl table data from minigraph for both host and namespace.
It is possible in multi-asic minigraph if there are no external port-channel (Only Router Port IP Interface) then Everflow table will have no binded interface in host and will gets classified as Control Plane ACL while in namespace gets classified as Mirror Table.
For ACL Rule generation we read global db as source of truth for acl table information and so for everflow rule generation if tables gets classified as Control plane we can generate rules with invalid action causing orchagent to throw runtime error.
How I did:
If the table is attach to erspan interface in minigraph then it always gets classified as mirror table.
Parse the value `AutoNegotiation` element from the `LinkMetadata` section of minigraph file. If the element is present, an `autoneg` key will be added to the port in the `PORT` table of Config DB with a value of either `off` or `on`
If an `autoneg` value is present in port_config.ini, the value from the minigraph will take precedence, overriding that value.
Also remove `AutoNegotiation` and `EnableAutoNegotiation` elements from the `DeviceInfo` section, as we will use this data in the `LinkMetadata` section to determine whether to enable auto-negotiation for a port.
To adjust config db generated via minigraph per matchmode changes in fine grained ecmp. The changes are done so that nexthop IP based filtering can occur to determine routes as requiring Fine Grained ECMP, in the past the only mode was to use the IP prefix of the route for filtering, with this matchmode change we will use nexthop IP based filtering
Azure/SONiC#727
How I did it
Change will modify config db entry created for FG_NHG to include 'match_mode': 'nexthop-based' so that nexthop IP based filtering can occur to determine routes as requiring Fine Grained ECMP. Changes also remove FG_NHG_PREFIX entry since its not needed under matchmode nexthop-based.
#### Why I did it
Some platforms have difficult to attach egress ACL to vlan.
#### How I did it
For egress ACL attaching to vlan, break them into vlan members.
#### How to verify it
Unit test
Tested in DUT
It is possible that one interface attaches multiple vlans. The VlanInterface should be in tagged mode.
Signed-off-by: Qi Luo <qiluo-msft@users.noreply.github.com>
Update minigraph parser to retrieve kubernetes server info from minigraph.xml and update "KUBERNETES_MASTER|SERVER" in running config.
Update minigraph parser to include clusterName from minigraph.xml into "DEVICE_METADATA|localhost"
Meet the requirement for the MUX_CABLE table that IPv6 loopbacks have a /128 prefix
Note that this change only affects the MUX_CABLE table, all other tables continue to use the loopback address provided in minigraph.
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Avoid sonic-cfggen crashing when a server does not have a configured loopback address in the minigraph
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Server IPv4 loopbacks do not always arrive with /32 prefix, which is a requirement for the MUX_CABLE table in config DB
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
To make the peer switch hostname easily accessible from config DB. Add peer_switch field to DEVICE_METADATA table
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
Why I did it
To support FG_ECMP scenarios
- How I did it
Modified minigraph parser to parse ECMP fields in the case they are present in minigraph
- How to verify it
Loaded ensuing config_db file on a DUT to verify the fields are parsed and configure device correctly