How to: CORD VTN – Write XOS TOSCA yaml configuration files

How to: CORD VTN – Write XOS TOSCA yaml configuration files

This article describes how to connect 2 different Service Network by VTN(Virtual Tenant Network), and how to debug problem in VTN flows.

Experiment Environment

This post will use oai_scenario as example, oai_scenario is custom profile for Integrated OAI into M-CORD‘s new version, and oai_scenario is still under construction, it will be available to use in estimate approximately March, 2018.

In my scenario, I have 3 different networks, named vmme_network, vhss_network, vspgw_network, This 3 network represent LTE component’s Networks(vHSS, vMME, vSPGW).

As I defined, networks detail will be like as following:

  • vmme_network: 10.0.6.0/24
  • vhss_network: 10.0.7.0/24
  • vspgw_network: 10.0.8.0/24

we have 1 vmme vm, 1 vhss vm and 2 vspgw vms, using service gateway to make automatic load balancing by vtn.

and dependency relationship shows in this picture:

Service Dependencies Graph

vMME depends on vHSS, because vMME will communicate with vHSS when user authentication.
vMME also depends on vSPGW, it needs to tell user which endpoint(Serving gateway) for connection.

In this scenario, ovs will become service gateway, and fake ARP reply to VMs, for example, here is Service Gateway IP address list:

  • vmme service gateway: 10.0.6.1
  • vhss service gateway: 10.0.7.1
  • vspgw service gateway: 10.0.8.1

So in vMME’s config file, Database(vHSS)’s IP address will be 10.0.7.1 instead of unique VM’s IP address(like as 10.0.7.2/24).

When OpenVSwitch receives packets went to 10.0.7.1, ovs will do the load balance by forwarding packet to seperate vHSS VM.

Service Configuration

In mcord-oai-services.yml.j2, will create service object, service slice, define service network and create service instance. But here only shows VTN related code.

Network Template options

Warning: I'm not sure following comment is correct or not, if you find it's incorrect, send me a message, I will be very appreciated.

  • visibility
    • private: private to other slice
    • public: public to other slice
  • translation
    • none: No network address translation to internet
    • NAT: With NAT
  • access
    • None
    • direct: Access Service Instance by VM’s IP address
    • indirect: Access Service Instance by Service Gateway (with load balance mechanism)
  • vtn_kind
    • PRIVATE: virtual network for instances in same service
    • PUBLIC: external accessible network
    • MANAGEMENT_LOCAL: Management network accessible (virtual POD, CORD-in-a-Box)
    • MANAGEMENT_HOST: Management network accessible (physical POD, CORD POD)
    • VSG: access-side network
    • (deprecated) ACCESS_AGENT: Provides a network for access agent infrastructure service

Bold Text means default values.

Code

Service Graph

In mcord-oai-services-graph.yml will describe service dependencies.

And now VTN doesn’t support uni-direct connection, all dependencies will be bidirectional(2-ways connection).

VTN Design Note – OVS Pipeline

Illustration of VTN OVS Pipeline

In VTN OVS pipeline, will have 7 table, deep into VTN Design Note to understand how these tables work.

Use sudo ovs-ofctl dump-flows br-int -O OpenFlow13 to view all flows on overlay ovs. You must to assign OpenFlow version as OpenFlow13, or goto_table action will display as DROP action.

Deep into VTN flows

Okay, so as our configuration, if my vMME(10.0.6.2/24) needs to have connect ability to vHSS(10.0.7.2/24), how many flows will be matched?

In this part, you can open Overlay ONOS WebUI and find flows on ovs.

  • Ingress Table (Table 0):

(No traffic selector criteria for this flow)
Treatment Instructions: transition:TABLE:1, cleared:false

  • Input Port Table (Table 1):

Criteria: IN_PORT:17, ETH_TYPE:ipv4, IPV4_SRC:10.0.6.2/32
Treatment Instructions: transition:TABLE:2, cleared:false

Because packet sent from vMME(10.0.6.2) and Port number matched, so transfer to Table 2.

  • Access Table (Table 2):

Criteria: ETH_TYPE:ipv4, IPV4_SRC:10.0.6.0/24, IPV4_DST:10.0.7.0/24
Treatment Instructions: transition:TABLE:4, cleared:false

And packet's source and destination IP address matched, so pass to Table 4.

  • DstIP Table (Table 4):

Criteria: ETH_TYPE:ipv4, IPV4_DST:10.0.7.2/32
Treatment Instructions: immediate:ETH_DST:FA:16:3E:3D:B8:56, OUTPUT:19, cleared:false

Then packet's Layer 2 dest address changed and packet delivered to correct port.

Reference

Leave a Reply

Your email address will not be published. Required fields are marked *