Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The first step is to get an ONOS system up and running, and you can read more about how to do this here: Installing and Running running ONOS

Once ONOS is running, SDN-IP has an additional application dependency that it relies on to ensure ARP requests are resolved properly. This is the org.onosproject.proxyarp application that responds to ARP requests on behalf of hosts and external routers.

...

A full running SDN-IP system has a lot of pieces that need to be correct before anything will work. When setting up a system for the first time or when things go wrong, it's best to go step by step to check each piece is in place.

Check SDN-IP is installed:

Code Block
onos> apps -s | grep sdnip
*   4 org.onosproject.sdnip            1.310.0.SNAPSHOT SDN-IP peering application

The little * in the 1st column means SDN-IP is activated. If it's not there, try activate it again.

Check whether the external routers can resolve ARP properly. If they can't resolve ARP, then look in the addresses.json file and check that the address configuration is correct.

Check the BGP peering sessions are established with the internal BGP speakers. If the peering sessions are not established, it may be that the sdnip.json configuration is wrong. If it seems to be correct, check the configuration of the BGP peers.

Check the configuration files are in the correct directory.

the logs. Is there any error?

Code Block
titleExample: increase sdnip log level to debug, using the ONOS CLI
onos> log:set org.onosproject.apps.sdnip debug

Was you configuration loaded by ONOS?

Code Block
titleCheck the ONOS network configuartion
onos> netcfg

Have interface contained in your ONOS network config loaded correctly in the system?

Code Block
titleCheck interfaces configured
onos> interfaces

Was the SDN-IP configuration contained in your ONOS network config loaded correctly in the system?

Code Block
titleCheck SDN-IP configuration
onos> bgp-neighbors

Once you're sure nothing wrong is in the logs and that SDN-IP has been configured correctly, it's time to go one level deeper. let's check the intent subsystem. First let's check that the external routers You should have six point to point intents for each couple external router - BGP speaker, and one multi-point-to-single-point intent for each route advertised from an external router.

Can your external routers communicate with the BGP speakers?

External routers need to form a BGP session with the BGP speakers. To do that six point to point intents for each couple external router - BGP speaker get installed by ONOS. You should make sure of the following

Can you external routers ping the BGP speakers they should peer with? Do some ping tests. If ping does not work, check if ARP is resolved or not on the hosts, meaning for example, does your external router have the association between the IP address and the MAC address of the BGP speaker in its ARP table? If any of the two points above fails, likely your interfaces configuration is wrong. This usually reflects in wrong point-to-point intents installed by ONOS.

Are the point-to-point intents installed by ONOS correct?

Code Block
titleExample of the basic intent commands - intents summary and detailed intents view
onos> intents -s
onos> intents

If ping works, it's time to check if BGP sessions are up and routes propagated. Routes should be advertised from the external routers to the BGP speaker, and from the BGP speaker advertised to SDN-IP. Checking if BGP sessions are up and routes propagated -and eventually checking the configuration of the routers changes from router to router. In general, you should make sure of the following:

Are all the BGP sessions between the external routers and the BGP speakers up? To be either checked from the external routers or from the BGP speakers

Are the BGP sessions between the BGP speakers and SDN-IP up? To be checked from on the BGP speakers or from SDN-IP (below)Next, check that the internal BGP speakers are peering with ONOS correctly:

Code Block
onos> bgp-neighbors

You should see a list of internal BGP speakers. If not, check that the connectivity is OK and the BGP configuration in the BGP speaker is correct.

Then, check if ONOS receives the expected routes:

Code Block
onos> routes

If the routes are not received, check if the internal BGP speaker has received the routes and advertised them to ONOS.

In addition, you could use the following command to see BGP-specific information about the received routes:

Code Block
onos> bgp-routes

Once the routes are received, ONOS will start to install MultiPointToSinglePoint intents for each route. You can check this is correct by looking at the number of MultiPointToSinglePoint intents in the intent summary. It should be the same as the number of routes, and all intents should move to the INSTALLED state before long.

Code Block
onos> intents -s

Once intents are installed, there should be transit connectivity through the SDN network. 

Has SDN-IP received the routes?

Code Block
titleCheck if SDN-IP received the routes from the BGP speaker
onos> routes

Once you see routes in SDN-IP it's time to check if these get transformed into intents. Each route should correspond to a multi-point-to-single-point intent

Code Block
titleExample of the basic intent commands - intents summary and detailed intents view
onos> intents -s
onos> intents

Likely if intents are wrong, your SDN-IP configuration is wrong.

If intents have been installed all correctly but still things don't work, last thing is to check if corresponding flows got installed correctly. The following commands can help you to see what's going on.

Is there any flow in pending add (meaning that ONOS / the switch are not able to add)?

Code Block
titleCheck flows status
onos> flows
onos> flows pending_add

Questions? Comments? Problems?

...

We really welcome your help to ensure the code and documentation are clear and informative, so let us know if you have and issues.

 have