FIP associated to VIP port is not reachable
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Juniper Openstack |
New
|
Undecided
|
Unassigned | ||
Bug Description
Contrail: 3.1.0.0 (Build 25) Mitaka.
FIP associated to VIP port is not reachable.
When FIP is associated to VM port the route is advertised by vrouter-agent.
But when 3rd neutron port is created ("neutron port-create" command) and used as VIP port to which FIP is associated, FIP is not reachable.
AAP (VIP address) is configured on VM port. FIP is updated with floating_
Attached is a file (from the customer deployment) that compares the working case (FIP mapped to a regular VMI) with the non-working case (FIP mapped to the VIP-port). From a configuration perspective, and except for obvious differences (VIP-port lacks some attributes that regular VMI has), they are identical. In other words, the configuration obtained with neutron API looks correct.
However the BGP route for the FIP is not generated by the control node in the non-working case.
We suspect the problem lies on the control plane (vRouter agent not sending the route to control node) and not on the configuration. Edouard can reply with further findings.
-------
172.30.157.205 (admin/juniper123 - both Contrail & OS), root/juniper123, Contrail version 3.2.0.0-19.
FIP: 100.0.0.201
VIP: 10.0.0.201 (secondary IP on ciros interface)
-------
Contrail Ciros (internal network) interface detail (json) when FIP is assigned to VIP/AAP are shown below. Ping does work from external network.
Floating IP Mapped Fixed IP Address Floating IP Pool
100.0.0.201 192.168.1.3 (36e9420d-
{
floating_ips: [
{
virtual_network: default-
ip_address: 100.0.0.201
}
]
vm_name: cir1
ip6_active: false
virtual_network: default-
uuid: 36e9420d-
-------
Contrail Ciros (internal network) interface detail (json) when FIP is assigned to VIP/AAP are shown below. Ping to FIP doesn't work from external network, ping to VIP works.
Floating IP Mapped Fixed IP Address Floating IP Pool
100.0.0.201 10.0.0.201 (c7b4f493-
{
UveVirtualMachi
vm_name: cir1
cpu_info: { ... }
interface_list: [ ... ]
uuid: e9c3da76-
vrouter: sdn4
interface_details: [
{
floating_ips: [ <-------- EMPTY
]
vm_name: cir1
| Slobodan Blatnjak (sblatnjak) wrote | #1 |
| information type: | Proprietary → Public |
| description: | updated |
| Sergey Matov (smatov) wrote | #2 |
| Sergey Matov (smatov) wrote | #3 |
This is standalone bug with different behaviour. Unmark duplicate.
Mentioned behaviour in description considered having VIP created and FIP assigned on it with VRRP group(AAP) having active interfaces. Bug is still presents. Steps to reproduce:
1. Create VIP port with fixed IP address
2. Create VM ports with allowed-
3. Associate FIPs on VIP/VM ports
4. Create secgroup to allow VRRP/ssh/
5. Update ports with secgroup from step 4
6. Create VMs with attached ports from step 2
7. For VRRP testing, create keepalived group with virtual address from step 1 on all VM that needs to be in HA
Expected result: FIP of VIP is reachable, target VM is one that having VIP configured by keepalive
Actual result: FIP is not reachable
To reduce complexity, we can assign VIP w/o keepalived directly as 2nd address for interface inside VM. However, no reachability faced.