Ignore the network with unsupported network type to make sure no flow rules
populated for the network by any chance.
Change-Id: I3fe01900e5239af1ea28f4c6cb95869ff47964a9
It turns out that suppression annotations have to have the actual
string literal in them; if you use a defined constant SonarQube
ignores the suppression.
Change-Id: I3628df116d182b01a108da0d6f059784a3be4fed
Bugfix:
- Add MPLS BOS matching
- Fix NPE caused by race between filter objective and broadcast next objective
Enhancement:
- Move group handler out from OFDPA pipeline
- Move ARP request from rule populator to packet request
Change-Id: I0ba40e10f7cb7f97277df86725fbd2546a62e890
Done
- Implement service dependency APIs
- Populate or remove basic tenant connectivity rules when VM created or removed
- Populate direct/indirect service access rules when service dependency created
- Remove service dependency rules
Todo
- Add/remove bucket to proper group when a VM is created or terminated
- Populate service dependency rules for existing VMs when service is activated
- Cleanup flow rules remove
Change-Id: I1daaf7ac9b41d7f2694605cb9b75f12d42144dbd
Restart UDP listener thread and create a new RADIUS server socket
when the AAA app configuration changes.
Change-Id: If81479ee54609f56cf86e21aa5c5d83732c6a9fe
- Tool created while debugging ONOS-3509
Usage Example: (See recent Mastership and Device events)
onos> events -m -d
Change-Id: I87aceaf8fe61732a61c2d1e39399d0f10a729b54
This adds SNMP device-discovery, and a Fault Management app which makes alarms available to users via REST/GUI/CLI interfaces.
There is still code cleanup that could be done, but aim of this commit is an end-to-end proof of concept.
To demonstrate :
1) /opt/onos/bin/onos-service
onos> app activate org.onosproject.snmp
onos> app activate org.onosproject.faultmanagement
2) SNMP devices are seeded via config file. The default seed file contains connection details for devices (SNMP agents) available via internet e.g. demo.snmplabs.com
cp /opt/onos/apache-karaf-3.0.3/etc/samples/org.onosproject.provider.snmp.device.impl.SnmpDeviceProvider.cfg /opt/onos/apache-karaf-3.0.3/etc/
3) ONOS will poll these SNMP devices and store their alarms.
4) You can now manipulate the alarms via REST e.g. http://<onos>:8181/onos/v1/fm/alarms , via CLI via various "alarm-*” commands or in UI with an Alarms Overlay.
More info at https://wiki.onosproject.org/display/ONOS/Fault+Management
15/Dec/15: Updated regarding review comments from Thomas Vachuska.
17/Dec/15: Updated coreService.registerApplication(name) as per https://gerrit.onosproject.org/#/c/6878/
Change-Id: I886f8511f178dc4600ab96e5ff10cc90329cabec
- Changed service ID from VNI to network ID
- Added REST APIs(POST/DELETE/PUT)
- Added interfaces to CordVtnService(create/remove)
- Renamed Service/ServiceId to more specific
Change-Id: I80322fea28a7740a2cc7723b576e7bb9ff08389e
