Old version gave in logs ...
2019-06-06T09:34:46,730 | WARN | FlowRuleDriverProvider-0 | FlowRuleDriverProvider | 191 - org.onosproject.onos-core-net - 2.2.0.SNAPSHOT | Exception thrown while polling netconf:172.26.138.38:830
java.lang.NullPointerException: null
at org.onosproject.drivers.juniper.FlowRuleJuniperImpl.getFlowEntries(FlowRuleJuniperImpl.java:92) ~[?:?]
at org.onosproject.net.flow.impl.FlowRuleDriverProvider.pollDeviceFlowEntries(FlowRuleDriverProvider.java:193) ~[?:?]
at org.onosproject.net.flow.impl.FlowRuleDriverProvider.access$500(FlowRuleDriverProvider.java:63) ~[?:?]
at org.onosproject.net.flow.impl.FlowRuleDriverProvider$InternalDeviceListener.handleEvent(FlowRuleDriverProvider.java:249) ~[?:?]
at org.onosproject.net.flow.impl.FlowRuleDriverProvider$InternalDeviceListener.lambda$event$0(FlowRuleDriverProvider.java:233) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]
New version gives ...
2019-06-07T09:36:07,924 | WARN | FlowRuleDriverProvider-0 | JuniperAbstractHandlerBehaviour | 218 - org.onosproject.onos-drivers-juniper - 2.2.0.SNAPSHOT | NETCONF session to device netconf:172.26.138.68:830 not yet established, will be retried
Note in new version this lookup code refactored to be in one place.
Change-Id: Ic78c5ecc67e8e98d14da845d0541d980296750a5
New UTs based on NETCONF responses lab devices.
No functional changes here; it is refactoring only.
Change-Id: I6a011fce9496285539c7a11deb8fbac930b12483
There is some case regarding link creation.
Let's suppose that there are A and B devices on topology.
The link discovery drivers on onos will gather the link information from device(eg, switches).
In this case, if a port on the device A is unplugged or changed to down state but the link information(eg, LLDP) will be remained because TTL is not reached yet.
So, onos will re-create the link using link information that is gathered from link discovery driver.
This behavior result to link is re-created suddenly even if ports are disabled.
ONOS-7854
Change-Id: I224fb39fee92648600f9c9e40fcc97890d3ea9ef
Currently, juniper port description is only set with hard coded copper type.
So, set the port type using real value of juniper switch's port type.
ONOS-7844
Change-Id: Ifdaca2fdc73ab0006a8d180e42f05831f9266f9a
The ONOS does not process the incoming LLDP packet from switches.
The ONOS only process LLDP packets if LLDP packet has "ONOS Discovery" optional TLV.
So, this changes process incoming LLDP packet from switch and make a link information and onos can utilize it.
Also, this patch changes the requested appId of DefaultForwardingObjective generated by PacketManager.
So, AppId in result of flows cli will be printed to actual requested appId.
ONOS-7748
Change-Id: I2611b34655bec2369b8817ce0cd29fb2edbed845
