docs/docs_vCPE.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0
   2    International License. http://creativecommons.org/licenses/by/4.0
   3    Copyright 2018 Huawei Technologies Co., Ltd.  All rights reserved.
   4
   5 .. _docs_vcpe:
   6
   7 vCPE Use Case
   8 ----------------------------
   9
  10 Description
  11 ~~~~~~~~~~~
  12 vCPE use case is based on Network Enhanced Residential Gateway architecture specified in Technical Report 317 (TR-317), which defines how service providers deploy residential broadband services like High Speed Internet Access. The use case implementation has infrastructure services and customer service. The common infrastructure services are deployed first and shared by all customers. The use case demonstrates ONAP capabilities to design, deploy, configure and control sophisticated services.
  13
  14 More details on the vCPE Use Case can be found on wiki page https://wiki.onap.org/pages/viewpage.action?pageId=3246168
  15
  16 Source Code
  17 ~~~~~~~~~~~
  18 vcpe test scripts: https://git.onap.org/integration/tree/test/vcpe?h=dublin
  19
  20 How to Use
  21 ~~~~~~~~~~
  22 Most part of the use case has been automated by vcpe scripts. For the details on how to run the scripts, please refer to the use case tutorial on https://wiki.onap.org/display/DW/vCPE+Use+Case+Tutorial%3A+Design+and+Deploy+based+on+ONAP.
  23
  24 Here are the main steps to run the use case in Integration lab environment, where vCPE script is pre-installed on Rancher node under /root/integration/test/vcpe:
  25
  26 1. Run Robot script from Rancher node to onboard VNFs, create and distribute models for vCPE four infrastructure services, i.e. infrastructure, brg, bng and gmux
  27
  28 ::
  29
  30    demo-k8s.sh onap init
  31
  32 2. Add route on sdnc cluster VM node, which is the cluster VM node where pod sdnc-sdnc-0 is running on. This will allow ONAP SDNC to configure BRG later on.
  33
  34 ::
  35
  36    ip route add 10.3.0.0/24 via 10.0.101.10 dev ens3
  37
  38
  39 3. Install Python and other Python libraries
  40
  41 ::
  42
  43    integration/test/vcpe/bin/setup.sh
  44
  45
  46 4. Change the Openstack env parameters and one customer service related parameter in vcpecommon.py
  47
  48 ::
  49
  50     cloud = {
  51         '--os-auth-url': 'http://10.12.25.2:5000',
  52         '--os-username': 'xxxxxxxxxx',
  53         '--os-user-domain-id': 'default',
  54         '--os-project-domain-id': 'default',
  55         '--os-tenant-id': 'xxxxxxxxxxxxxxxx' if oom_mode else '1e097c6713e74fd7ac8e4295e605ee1e',
  56         '--os-region-name': 'RegionOne',
  57         '--os-password': 'xxxxxxxxxxx',
  58         '--os-project-domain-name': 'xxxxxxxxx' if oom_mode else 'Integration-SB-07',
  59         '--os-identity-api-version': '3'
  60     }
  61
  62     common_preload_config = {
  63         'oam_onap_net': 'xxxxxxxx' if oom_mode else 'oam_onap_lAky',
  64         'oam_onap_subnet': 'xxxxxxxxxx' if oom_mode else 'oam_onap_lAky',
  65         'public_net': 'xxxxxxxxx',
  66         'public_net_id': 'xxxxxxxxxxxxx'
  67     }
  68
  69 5. Run Robot to create and distribute for vCPE customer service. This step assumes step 1 has successfully distributed all vcpe models except customer service model
  70
  71 ::
  72
  73    ete-k8s.sh onap distributevCPEResCust
  74
  75 6. If running with oom_mode=False initialize SDNC ip pool by running below command from k8s control node. It will be done automatically otherwise.
  76
  77 ::
  78
  79     kubectl -n onap exec -it dev-sdnc-sdnc-0 -- /opt/sdnc/bin/addIpAddresses.sh VGW 10.5.0 22 250
  80
  81 7. Initialize vcpe
  82
  83 ::
  84
  85    vcpe.py init
  86
  87 8. If running with oom_mode=False run a command printed at the end of the above step from k8s control node to insert vcpe customer service workflow entry in SO catalogdb. It will be done automatically otherwise.
  88
  89
  90 9. Instantiate vCPE infra services
  91
  92 ::
  93
  94     vcpe.py infra
  95
  96 10. From Rancher node run vcpe healthcheck command to check connectivity from sdnc to brg and gmux, and vpp configuration of brg and gmux.
  97
  98 ::
  99
 100     healthcheck-k8s.py --namespace <namespace name> --environment <env name>
 101
 102 11. Instantiate vCPE customer service.
 103
 104 ::
 105
 106     vcpe.py customer
 107
 108 12. Update libevel.so in vGMUX VM and restart the VM. This allows vGMUX to send events to VES collector in close loop test. See tutorial wiki for details
 109
 110 13. Run heatbridge. The heatbridge command usage: demo-k8s.sh <namespace> heatbridge <stack_name> <service_instance_id> <service> <oam-ip-address>, please refer to vCPE tutorial page on how to fill in those paraemters. See an example as following:
 111
 112 ::
 113
 114     ~/integration/test/vcpe# ~/oom/kubernetes/robot/demo-k8s.sh onap heatbridge vcpe_vfmodule_e2744f48729e4072b20b_201811262136 d8914ef3-3fdb-4401-adfe-823ee75dc604 vCPEvGMUX 10.0.101.21
 115
 116 14. Start closed loop test by triggering packet drop VES event, and monitor if vGMUX is restarting. You may need to run the command twice if the first run fails
 117
 118 ::
 119
 120     vcpe.py loop
 121
 122
 123 Test Status
 124 ~~~~~~~~~~~~~~~~~~~~~
 125 The use case has been tested for Dublin release, the test report can be found on https://wiki.onap.org/display/DW/vCPE+%28Heat%29+-+Dublin+Test+Status
 126
 127 Known Issues and Workaround
 128 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 129 1) NATs are installed on BRG and vBNG. In order to allow SDNC to send BRG configuration message through vBNG, SDNC host VM IP address is preloaded on BRG and vBNG during VM instantiation, and provisioned into the NATs. If SDNC changes its host VM, SDNC host VM IP changes and we need to manually update the IP in /opt/config/sdnc_ip.txt. Then run:
 130
 131 ::
 132
 133   root>vppctl tap delete tap-0
 134   root>vppctl tap delete tap-1
 135   root>/opt/nat_service.sh
 136   root>vppctl restart
 137
 138 2) During vCPE customer service instantiation, though vGW should come up successfully BRG vxlan tunnel configuration is likely to fail in SDNC cluster environment due to SDNC unreachable to BRG. See more detail in JIRA INT-1127. One workaround is to run vCPE use case with SDNC cluster disabled.
 139
 140 3) In some Openstack environments (e.g. Ocata version), there is an issue with DHCP anti-spoofing rules preventing BRG to receive DHCP reply (Option 82) from DHCP. By default Openstack neutron is using *IptablesFirewallDriver*, which is actively inserting *Prevent DHCP Spoofing by VM* rules into linuxbridge firewall rules. This feature should prevent mailicious traffic from rogue VM inside Openstack, however it's affecting also vCPE usecase. Manual tweaking of fw rules is not persistent and those rules are automatically regenerated, but one can disable this logic by switching to *neutron.agent.firewall.NoopFirewallDriver*. More details can be found on https://codesomniac.com/2017/07/how-to-run-a-dhcp-server-as-openstack-instance/
 141
 142    **NOTE:** To propagate change in firewall_driver one needs to restart neutron-linuxbridge-agent and also openstack-nova-compute services.
 143
 144    Additionally Neutron's Port Security Extension Driver is by default preventing any routing functions of an instance (be it a router or VNF). Hence for smoothest vCPE experience it's advised to either disable the packet filtering by setting port_security_enabled flag for a network/port to "False" or alternatively add allowed_address_pairs to relevant VNFs ports with appropriate network prefixes. Port security driver can be also disabled globally, for more insight into Port Security Extension Driver please visit https://wiki.openstack.org/wiki/Neutron/ML2PortSecurityExtensionDriver