把像拓扑发现、Qos带宽保证、多路径容错路由等网络功能模块做成北向App好呢?还是做成Plugin好呢?哪个难度小一点呢


把像拓扑发现、Qos带宽保证、多路径容错路由等网络功能模块做成北向App好呢?还是做成Plugin好呢?哪个难度小一点呢?

问题来自OpenDaylight群(SD)
已邀请:

君子一诺 - 软件测试外加小小编一枚

赞同来自:


来自OpenDaylight群(山西-文斌王)回复:难度最小的肯定是用北向统一的rest api啊,但是性能上面可能会差好多,而且你还要搞明白,已有的那些rest api是否足够能满足你的要求,如果要是不能满足的话 那你就要构造北端的 plugin

君子一诺 - 软件测试外加小小编一枚

赞同来自:


来自群OpenDaylight群(SD)回复:概念还不是很清楚,比如我要开发北向app,就需要调用rest api,了解有哪些api,提供哪些功能;如果我要开发plugin,是需要了解Opendaylight源码架构,在源码基础上进行修改

xingchun00 - 喜欢探讨新技术

赞同来自:


请问大侠,对于opendaylight的ecmp实现机制是什么?负载分担是基于流的方式还是基于包或者基于带宽?
操作1:如果在试验中发现怎么构造case测试opendaylight对于负载分担的支持。即如附件所示,怎么构造从R5到R1的流量在1和2两条路由实现负载分担?
操作2:测试中从R5 ping R1的loopback口地址,发现报文从路由2传输,如果将R3到R4的链路断开,报文能够切换到路径1,是否可以证明opendaylight的ecmp具有路由备份功能?

君子一诺 - 软件测试外加小小编一枚

赞同来自:


应该是基于流量带宽吧,带宽利用率。这也是根据你在代码 中所设置的策略有关的。对于操作2:将链路断开并不能体现ecmp吧,ecmp意思是等价多路径,你将链路断开,只剩下一条路径,不是很合理。我觉得这个最起码要用三条可达路径的

要回复问题请先登录注册