diff options
author | Michal Ptacek <m.ptacek@partner.samsung.com> | 2019-09-11 12:04:35 +0000 |
---|---|---|
committer | Michal Ptacek <m.ptacek@partner.samsung.com> | 2019-09-11 12:04:35 +0000 |
commit | 7a008fd29da0f41b8d74bac9f965f9acc272eecc (patch) | |
tree | e56cc94b8f026b808b6ef1bc0d4fed8176fd5667 /docs | |
parent | dd95f0285f8a986498e3b6146c16d23e09ab4490 (diff) |
Adding hint regarding dhcp anti-spoofing for vCPE
Adding instructions for bypassing DHCP anti-spoofing rules
preventing vCPE to work.
Change-Id: Ic0f92a40a41e5e20dc43c360e429baba44a46fa1
Issue-ID: DOC-549
Signed-off-by: Michal Ptacek <m.ptacek@partner.samsung.com>
Diffstat (limited to 'docs')
-rw-r--r-- | docs/docs_vCPE.rst | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/docs/docs_vCPE.rst b/docs/docs_vCPE.rst index 20e9b496d..6a4b1b2db 100644 --- a/docs/docs_vCPE.rst +++ b/docs/docs_vCPE.rst @@ -192,3 +192,8 @@ Known Issues and Workaround root>vppctl restart 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. + +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/ + + **NOTE:** To propagate change in firewall_driver one need to restart neutron-linuxbridge-agent and also openstack-nova-compute services. + |