DPB - FRR config dependency
Vishnu Shetty
Zhenggen Xu
Hi Vishnu,
FRR/BGP configurations does not depending on physical port, at least that is the case for all our use cases. In case of dynamic learnt routes, since we are shutting down the ports before breakout, the routes will be removed by FRR thus removed from ASIC too, so when ports are deleted, there were no dependencies on them.
Regards
Xu
Ben Gale
- alias_at_lanes (new topic)- Yes FRR/BGP depends upon IP interfaces rather than physical ports, but these IP interfaces may be physical port-based. In this case, DPB (Dynamic Port Breakout) *does* affect things. So, for instance, if FRR has a configuration for a port-based interface, and then that interface is broken out, then stale interface configuration is left hanging around in FRR for the "old" port. In general, FRR *does* need to be reconfigured after a DPB event. It seems like you are placing the onus for doing that on the operator (i.e. they have to go in and do this reconfiguration), correct?
- I see from the HLD that the platform.json file has the "alias_at_lines" field. This is used (I think) to express the name(s) of the sub-ports when broken out. This would then be used as the key for the broken out ports in the SONiC PORT table, correct?
- I note that the SONiC PORT table also has the "alias" field. However this has a different usage - this is used as an alternate port reference in the UI (e.g. Click). It's a field in the PORT table, not a key.
- This confused me to begin with, because the word "alias" is used for 2 quite different purposes. Also, if I understand it correctly, this means that there is no "alias" (in the traditional SONiC meaning) available to broken out ports. I think this is a problem. To ask a different way, how does one specify the "alias" field in the SONiC PORT table for a broken out port?
--
You received this message because you are subscribed to the Google Groups "sonic-breakout-workgroup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonic-breakout-wor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonic-breakout-workgroup/8EF471BC-39DF-482F-8721-1F39A8DE4CCC%40linkedin.com.
Zhenggen Xu
Ben,
See comments below:
- FRR related: IP interface depending on physical port was handled by Yang models and in configDB. I,E, the IP interface will be removed automatically or the breakout will fail and output that dependency. We don’t manage the IP interfaces in FRR itself. Of course, if you have neighbors etc that need to be changed due to IP changes, you would need to modify that in FRR config, but currently we don’t manage that dependency and it won’t impact the SONiC backend, it could cause neighbor session down, and that is up to user to fix the FRR configuration. If you are interested to manage these level of dependency, we can discuss further as this is not part of the design right now.
- alias_at_lanes
The alias is used for “alias field” of PORT table, not the key. The keys were always Ethernet0, Ethernet1… and so on. We had some discussion to have different port naming convention: link, that is not in the scope of DPB for now, it was mentioned in the HLD here.
Regards
/Xu