codehaus


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[neutron] Floating ips instances not appear in tcpdump


On Thu, 2020-11-19 at 17:31 +0000, Stephen Medina wrote:
> Which official guides did you use to deploy?
assuming its the install guide this woudl result in a linux bridge deployment.

in both the linuxbridge and ml2/ovs cases floting ips are implemented using ip tables mascarade dnat rules
that is likely why the souce ip is beign rewritten. 
https://www.rdoproject.org/networking/networking-in-too-much-detail/#network-host-router-mn
covers this. that said it rather old so ignore the quantum names it still work the samemore or less unless you are uing
ovn in which case  its similar but done with openflow.

the imporant line is 

-A quantum-l3-agent-PREROUTING -d 172.24.4.228/32 -j DNAT --to-destination 10.1.0.2 

that maps the 172.24.4.228/32 floating ip to  10.1.0.2  fixed ip
although i tought that maintained the orginal source ip.

the -A quantum-l3-agent-float-snat -s 10.1.0.2/32 -j SNAT --to-source 172.24.4.228 
rule is what maps the reply packet form the private fixed ip to the public  floating ip.


so unless there is a bug when you tcp dump in the guest teh source ip of the recieved packets should be the ip or the orginal server e.g. your laptop.
but the dest ip should be the private fixed ip e.g. 10.1.0.2 in this case.

if you tcp dump on you laptop the souce ip of the reply should be the floating ip. and the dest ip should be your laptops.


> 
> -Stephen
> 
> ________________________________
> From: Cristina Mayo <admin at gsic.uva.es>
> Sent: Thursday, November 19, 2020 6:01 AM
> To: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
> Subject: [neutron] Floating ips instances not appear in tcpdump
> 
> Hello,
> 
> I have a multinode Openstack cloud installed on Ubuntu machines following the official guides, without extra settings. I have realised that all the
> income traffic on my instances with floating ips have the same source ip (controller's node ip address). Could anyone help to understand this
> behaviour? I would like source ip address remains because I am interested in filter traffic, and it's currently impossible. It seems that my
> controller node is changing the original ip to the packets.
> 
> Thanks in advance,
> Regards
>