This is my Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = "bento/centos-7.1"
config.vm.define "test_mashine", primary: true do |test_mashine|
# ...
config.vm.box = "bento/centos-7.1"
test_mashine.vm.network "private_network", ip: "192.168.33.10", bridge: "eth0"
config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--memory", "2048"]
vb.customize ["modifyvm", :id, "--cpus", "1"]
end
end
config.ssh.insert_key = false
end
This is ping statistic:
ping 192.168.33.10
PING 192.168.33.10 (192.168.33.10) 56(84) bytes of data.
64 bytes from 192.168.33.10: icmp_seq=1 ttl=64 time=0.560 ms
64 bytes from 192.168.33.10: icmp_seq=2 ttl=64 time=0.179 ms
64 bytes from 192.168.33.10: icmp_seq=3 ttl=64 time=0.192 ms
64 bytes from 192.168.33.10: icmp_seq=4 ttl=64 time=0.205 ms
^C
--- 192.168.33.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.179/0.284/0.560/0.159 ms
when i do vagrant ssh -c"ifconfig":
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::a00:27ff:fef6:b007 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:f6:b0:07 txqueuelen 1000 (Ethernet)
RX packets 483 bytes 54593 (53.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 299 bytes 44693 (43.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.109 netmask 255.255.255.0 broadcast 192.168.56.255
inet6 fe80::a00:27ff:fe17:2deb prefixlen 64 scopeid 0x20<link>
ether 08:00:27:17:2d:eb txqueuelen 1000 (Ethernet)
RX packets 7 bytes 1632 (1.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 2090 (2.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Connection to 127.0.0.1 closed.
The ip address of machine is 192.168.56.109. Ip address must be 192.168.33.10. When I start machine with ip 192.168.101.100 - ip sets right.
Any ideas?
why your doing bridge ?
if you want to give private ip then you should give like:
test_mashine.vm.network :private_network, ip: "192.168.33.10", netmask: "255.255.255.0"
if you want to give ip from public subnet then you have to give like:
test_mashine.vm.network "public_network"
or for static you can give IP or bridge name also.
your Vagrantfile should be like:
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
# config.vm.box = "bento/centos-7.1"
config.vm.define :test_mashine do |test_mashine|
# ...
test_mashine.vm.box = "bento/centos-7.1"
test_mashine.vm.network :private_network, ip: "192.168.33.10", netmask: "255.255.255.0"
test_mashine.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--memory", "2048"]
vb.customize ["modifyvm", :id, "--cpus", "1"]
end
end
config.ssh.insert_key = false
end
For more info refer Vagrant Networking
Related
I'm trying to implement a TCP stack over TUN device according to RFC 793 in Linux. By default, my program is in the LISTEN state and is waiting for an SYN packet to establish a connection. I use nc to send an SYN:
$ nc 192.168.20.99 20
My program responds with SYN, ACK, but nc doesn't send an ACK at the end. This is the flow:
# tshark -i tun0 -z flow,tcp,network
1 0.000000000 192.168.20.1 → 192.168.20.99 TCP 60 39284 → 20 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1691638570 TSecr=0 WS=128
2 0.000112185 192.168.20.99 → 192.168.20.1 TCP 40 20 → 39284 [SYN, ACK] Seq=0 Ack=1 Win=10 Len=0
3 1.001056784 192.168.20.1 → 192.168.20.99 TCP 60 [TCP Retransmission] [TCP Port numbers reused] 39284 → 20 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=1691639571 TSecr=0 WS=128
|Time | 192.168.20.1 |
| | | 192.168.20.99 |
|0.000000000| SYN | |Seq = 0
| |(39284) ------------------> (20) |
|0.000112185| SYN, ACK | |Seq = 0 Ack = 1
| |(39284) <------------------ (20) |
|1.001056784| SYN | |Seq = 0
| |(39284) ------------------> (20) |
More info about my TCP header:
Frame 2: 40 bytes on wire (320 bits), 40 bytes captured (320 bits) on interface tun0, id 0
Raw packet data
Internet Protocol Version 4, Src: 192.168.20.99, Dst: 192.168.20.1
Transmission Control Protocol, Src Port: 20, Dst Port: 39310, Seq: 0, Ack: 1, Len: 0
Source Port: 20
Destination Port: 39310
[Stream index: 0]
[Conversation completeness: Incomplete, CLIENT_ESTABLISHED (3)]
[TCP Segment Len: 0]
Sequence Number: 0 (relative sequence number)
Sequence Number (raw): 0
[Next Sequence Number: 1 (relative sequence number)]
Acknowledgment Number: 1 (relative ack number)
Acknowledgment number (raw): 645383655
0101 .... = Header Length: 20 bytes (5)
Flags: 0x012 (SYN, ACK)
Window: 10
[Calculated window size: 10]
Checksum: 0x99b0 [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
NOTE: I'm aware of the ISN prediction attack, but this is just a test, and 0 for the sequence number is just as random as any other number in this case.
UPDATE: This is the output of tcpdump which says I'm calculating checksum wrong:
# tcpdump -i tun0 -vv -n
...
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40, bad cksum 16f3 (->911b)!)
192.168.20.99.20 > 192.168.20.1.39308: Flags [S.], cksum 0x9bb0 (incorrect -> 0x1822), seq 0, ack 274285560, win 10, length 0
...
Here is my checksum calculator (From RFC 1071):
uint16_t checksum(void *addr, int count)
{
uint32_t sum = 0;
uint16_t *ptr = addr;
while (count > 1) {
sum += *ptr++;
count -= 2;
}
if (count > 0)
sum += *(uint8_t *)ptr;
while (sum >> 16)
sum = (sum & 0xffff) + (sum >> 16);
return ~sum;
}
And I'm passing the combination of pseudo-header with the TCP segment for TCP checksum. (in big-endian order):
uint16_t tcp_checksum(struct tcp_header *tcph, uint8_t *pseudo_header)
{
size_t len = PSEUDO_HEADER_SIZE + (tcph->data_offset * 4);
uint8_t combination[len];
memcpy(combination, pseudo_header, PSEUDO_HEADER_SIZE);
dump_tcp_header(tcph, combination, PSEUDO_HEADER_SIZE);
return checksum(combination, len / 2);
}
What am I doing wrong here?
Problem solved by calculating checksums via in_cksum.c from tcpdump source code, which is a line-by-line implementation of the RFC 1071. I also had to set IFF_NO_PI for the tun device. For this case, using a tap device instead of a tun device is probably a better choice to handle EtherType.
I installed Openstack (all-in-one) by using KAYOBE. I follow all configuration steps described here https://docs.openstack.org/kayobe/latest/installation.html and here https://docs.openstack.org/kayobe/latest/configuration/scenarios/all-in-one/overcloud.html#configuration
Everything seems fine network/floating IPs, flavors,images,instances but I still have an issue to reach Internet from my instances and also to reach the instances from the host.
I have 2 instances in my Openstack with for each a floating IP in 192.168.213.xxx/24
I can ping from both instances their floating IP and their local IP.
I can also ping from both instances the public interface of my pubic network (EXT)
Any idea or support would be welcome.
Thank you.
My configuration is this one:
On my host the network interfaces are the following:
brens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.213.36 netmask 255.255.255.0 broadcast 192.168.213.255
inet6 fe80::ec5d:5cff:fee4:e865 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:26:9f:e3 txqueuelen 1000 (Ethernet)
RX packets 975109 bytes 2110124730 (1.9 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 607990 bytes 243846445 (232.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:ec:7a:b0:c6 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::20c:29ff:fe26:9fe3 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:26:9f:e3 txqueuelen 1000 (Ethernet)
RX packets 1793551 bytes 2197893693 (2.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 706011 bytes 252766868 (241.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Boucle locale)
RX packets 48961080 bytes 56924742056 (53.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 48961080 bytes 56924742056 (53.0 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
p-brens33-ovs: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::9040:7aff:fe13:333e prefixlen 64 scopeid 0x20<link>
ether 92:40:7a:13:33:3e txqueuelen 1000 (Ethernet)
RX packets 83424 bytes 9297973 (8.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 30 bytes 2056 (2.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
p-brens33-phy: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::ccf3:e0ff:fe09:eeb prefixlen 64 scopeid 0x20<link>
ether ce:f3:e0:09:0e:eb txqueuelen 1000 (Ethernet)
RX packets 30 bytes 2056 (2.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 83424 bytes 9297973 (8.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
qbr24033e67-96: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
ether 1a:08:1a:6e:23:fc txqueuelen 1000 (Ethernet)
RX packets 90 bytes 6932 (6.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
qbr2aa4f6fc-67: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
ether 66:d4:18:69:3b:12 txqueuelen 1000 (Ethernet)
RX packets 79 bytes 5618 (5.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
qvb24033e67-96: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet6 fe80::1808:1aff:fe6e:23fc prefixlen 64 scopeid 0x20<link>
ether 1a:08:1a:6e:23:fc txqueuelen 1000 (Ethernet)
RX packets 189 bytes 19262 (18.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 190 bytes 15978 (15.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
qvb2aa4f6fc-67: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet6 fe80::64d4:18ff:fe69:3b12 prefixlen 64 scopeid 0x20<link>
ether 66:d4:18:69:3b:12 txqueuelen 1000 (Ethernet)
RX packets 1567 bytes 185484 (181.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1654 bytes 154488 (150.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
qvo24033e67-96: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet6 fe80::c411:18ff:fe38:f94a prefixlen 64 scopeid 0x20<link>
ether c6:11:18:38:f9:4a txqueuelen 1000 (Ethernet)
RX packets 190 bytes 15978 (15.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 189 bytes 19262 (18.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
qvo2aa4f6fc-67: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet6 fe80::8c85:c4ff:fe68:8145 prefixlen 64 scopeid 0x20<link>
ether 8e:85:c4:68:81:45 txqueuelen 1000 (Ethernet)
RX packets 1654 bytes 154488 (150.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1567 bytes 185484 (181.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tap24033e67-96: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet6 fe80::fc16:3eff:fee4:c722 prefixlen 64 scopeid 0x20<link>
ether fe:16:3e:e4:c7:22 txqueuelen 1000 (Ethernet)
RX packets 168 bytes 14342 (14.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 201 bytes 18968 (18.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tap2aa4f6fc-67: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet6 fe80::fc16:3eff:fef6:8f99 prefixlen 64 scopeid 0x20<link>
ether fe:16:3e:f6:8f:99 txqueuelen 1000 (Ethernet)
RX packets 1632 bytes 152852 (149.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1587 bytes 186940 (182.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapbdd8182b-15: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet6 fe80::f816:3eff:fe61:78d5 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:61:78:d5 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 24 bytes 1776 (1.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Host: VMWARE Workstation 16
My WM where is installed my Openstack Instance:
-----------------------------------------------
- Operating System: CentOS 8
- Selinux deactivated
- Firewalld service inactive
One single network interface setup in NAT with a static IP address:
IP: 192.168.213.36/24
DNS1: 192.168.213.2 (DNS from my VMWARE Workstation network)
DNS2: 8.8.8.8
GATEWAY: 192.168.213.2
My Openstack network configuration file:
FROM /etc/neutron directory:
##################
File: ml2_conf.ini
##################
[ml2]
type_drivers = flat,vlan,vxlan
tenant_network_types = flat,vlan,vxlan
mechanism_drivers = openvswitch,l2population
extension_drivers = port_security,dns
[ml2_type_vlan]
network_vlan_ranges =
[ml2_type_flat]
flat_networks = physnet1
[ml2_type_vxlan]
vni_ranges = 1:1000
#################
File neutron.conf
#################
[DEFAULT]
debug = True
log_dir = /var/log/kolla/neutron
use_stderr = False
bind_host = 192.168.213.36
bind_port = 9696
api_paste_config = /usr/share/neutron/api-paste.ini
api_workers = 1
metadata_workers = 1
rpc_workers = 2
rpc_state_report_workers = 2
metadata_proxy_socket = /var/lib/neutron/kolla/metadata_proxy
interface_driver = openvswitch
allow_overlapping_ips = true
core_plugin = ml2
service_plugins = metering,router,vpnaas
transport_url = rabbit://openstack:uUmeMPEtFFu6IIQNoJ4Kdl026ZEG9TvlT5PdZnR9#192.168.213.36:5672//
dns_domain = sample.openstack.org.
external_dns_driver = designate
ipam_driver = internal
[nova]
auth_url = http://192.168.213.120:35357
auth_type = password
project_domain_id = default
user_domain_id = default
region_name = Toulouse
project_name = service
username = nova
password = wxXLLtG3uRpUxExM3YJvCsofbmPMWFy0RbnZ92Wk
endpoint_type = internal
cafile =
[oslo_middleware]
enable_proxy_headers_parsing = True
[oslo_concurrency]
lock_path = /var/lib/neutron/tmp
[agent]
root_helper = sudo neutron-rootwrap /etc/neutron/rootwrap.conf
[database]
connection = mysql+pymysql://neutron:zRMXmINpPXB7QNBSROcks7MuWdzbYw3TIouRbI7m#192.168.213.120:3306/neutron
connection_recycle_time = 10
max_pool_size = 1
max_retries = -1
[keystone_authtoken]
www_authenticate_uri = http://192.168.213.120:5000
auth_url = http://192.168.213.120:35357
auth_type = password
project_domain_id = default
user_domain_id = default
project_name = service
username = neutron
password = IujTCY3xxrnATYsc5BLw7MMDOjsvktHkaxnJvWux
cafile =
region_name = Toulouse
memcache_security_strategy = ENCRYPT
memcache_secret_key = vUHcQln5CqIRRbnABG6D4MO81Fb6jVEum4gPPMvY
memcached_servers = 192.168.213.36:11211
memcache_use_advanced_pool = True
[oslo_messaging_notifications]
transport_url = rabbit://openstack:uUmeMPEtFFu6IIQNoJ4Kdl026ZEG9TvlT5PdZnR9#192.168.213.36:5672//
driver = messagingv2
topics = notifications,notifications_designate
[designate]
url = http://192.168.213.120:9001/v2
auth_uri = http://192.168.213.120:5000
auth_url = http://192.168.213.120:35357
auth_type = password
project_domain_id = default
user_domain_id = default
project_name = service
username = designate
password = ngYG2ZLmGwfdfWHgSq4u0fqZz1s4fGmIola9pfL9
allow_reverse_dns_lookup = True
ipv4_ptr_zone_prefix_size = 24
ipv6_ptr_zone_prefix_size = 116
cafile =
region_name = Toulouse
[placement]
auth_type = password
auth_url = http://192.168.213.120:35357
username = placement
password = fJmE67U1r91mM0n7PqvgI0JJ55qjbBxem1qahJuL
user_domain_name = Default
project_name = service
project_domain_name = Default
os_region_name = Toulouse
os_interface = internal
cafile =
region_name = Toulouse
[privsep]
helper_command = sudo neutron-rootwrap /etc/neutron/rootwrap.conf privsep-helper
################
File config.json
################
{
"command": "neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf ",
"config_files": [
{
"source": "/var/lib/kolla/config_files/neutron.conf",
"dest": "/etc/neutron/neutron.conf",
"owner": "neutron",
"perm": "0600"
},
{
"source": "/var/lib/kolla/config_files/neutron_vpnaas.conf",
"dest": "/etc/neutron/neutron_vpnaas.conf",
"owner": "neutron",
"perm": "0600"
},
{
"source": "/var/lib/kolla/config_files/ml2_conf.ini",
"dest": "/etc/neutron/plugins/ml2/ml2_conf.ini",
"owner": "neutron",
"perm": "0600"
}
],
"permissions": [
{
"path": "/var/log/kolla/neutron",
"owner": "neutron:neutron",
"recurse": true
}
]
}
#################
File config.json
#################
{
"command": "neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf ",
"config_files": [
{
"source": "/var/lib/kolla/config_files/neutron.conf",
"dest": "/etc/neutron/neutron.conf",
"owner": "neutron",
"perm": "0600"
},
{
"source": "/var/lib/kolla/config_files/neutron_vpnaas.conf",
"dest": "/etc/neutron/neutron_vpnaas.conf",
"owner": "neutron",
"perm": "0600"
},
{
"source": "/var/lib/kolla/config_files/ml2_conf.ini",
"dest": "/etc/neutron/plugins/ml2/ml2_conf.ini",
"owner": "neutron",
"perm": "0600"
}
],
"permissions": [
{
"path": "/var/log/kolla/neutron",
"owner": "neutron:neutron",
"recurse": true
}
]
}
From /etc/neutron-openvswitch-agent
################
File config.json
################
{
"command": "neutron-openvswitch-agent --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/openvswitch_agent.ini",
"config_files": [
{
"source": "/var/lib/kolla/config_files/neutron.conf",
"dest": "/etc/neutron/neutron.conf",
"owner": "neutron",
"perm": "0600"
},
{
"source": "/var/lib/kolla/config_files/openvswitch_agent.ini",
"dest": "/etc/neutron/plugins/ml2/openvswitch_agent.ini",
"owner": "neutron",
"perm": "0600"
}
],
"permissions": [
{
"path": "/var/log/kolla/neutron",
"owner": "neutron:neutron",
"recurse": true
}
]
}
#################
File neutron.conf
#################
[DEFAULT]
debug = True
log_dir = /var/log/kolla/neutron
use_stderr = False
bind_host = 192.168.213.36
bind_port = 9696
api_paste_config = /usr/share/neutron/api-paste.ini
api_workers = 1
metadata_workers = 1
rpc_workers = 2
rpc_state_report_workers = 2
metadata_proxy_socket = /var/lib/neutron/kolla/metadata_proxy
interface_driver = openvswitch
allow_overlapping_ips = true
core_plugin = ml2
service_plugins = metering,router,vpnaas
transport_url = rabbit://openstack:uUmeMPEtFFu6IIQNoJ4Kdl026ZEG9TvlT5PdZnR9#192.168.213.36:5672//
dns_domain = sample.openstack.org.
external_dns_driver = designate
ipam_driver = internal
[nova]
auth_url = http://192.168.213.120:35357
auth_type = password
project_domain_id = default
user_domain_id = default
region_name = Toulouse
project_name = service
username = nova
password = wxXLLtG3uRpUxExM3YJvCsofbmPMWFy0RbnZ92Wk
endpoint_type = internal
cafile =
[oslo_middleware]
enable_proxy_headers_parsing = True
[oslo_concurrency]
lock_path = /var/lib/neutron/tmp
[agent]
root_helper = sudo neutron-rootwrap /etc/neutron/rootwrap.conf
[database]
connection = mysql+pymysql://neutron:zRMXmINpPXB7QNBSROcks7MuWdzbYw3TIouRbI7m#192.168.213.120:3306/neutron
connection_recycle_time = 10
max_pool_size = 1
max_retries = -1
[keystone_authtoken]
www_authenticate_uri = http://192.168.213.120:5000
auth_url = http://192.168.213.120:35357
auth_type = password
project_domain_id = default
user_domain_id = default
project_name = service
username = neutron
password = IujTCY3xxrnATYsc5BLw7MMDOjsvktHkaxnJvWux
cafile =
region_name = Toulouse
memcache_security_strategy = ENCRYPT
memcache_secret_key = vUHcQln5CqIRRbnABG6D4MO81Fb6jVEum4gPPMvY
memcached_servers = 192.168.213.36:11211
memcache_use_advanced_pool = True
[oslo_messaging_notifications]
transport_url = rabbit://openstack:uUmeMPEtFFu6IIQNoJ4Kdl026ZEG9TvlT5PdZnR9#192.168.213.36:5672//
driver = messagingv2
topics = notifications,notifications_designate
[designate]
url = http://192.168.213.120:9001/v2
auth_uri = http://192.168.213.120:5000
auth_url = http://192.168.213.120:35357
auth_type = password
project_domain_id = default
user_domain_id = default
project_name = service
username = designate
password = ngYG2ZLmGwfdfWHgSq4u0fqZz1s4fGmIola9pfL9
allow_reverse_dns_lookup = True
ipv4_ptr_zone_prefix_size = 24
ipv6_ptr_zone_prefix_size = 116
cafile =
region_name = Toulouse
[placement]
auth_type = password
auth_url = http://192.168.213.120:35357
username = placement
password = fJmE67U1r91mM0n7PqvgI0JJ55qjbBxem1qahJuL
user_domain_name = Default
project_name = service
project_domain_name = Default
os_region_name = Toulouse
os_interface = internal
cafile =
region_name = Toulouse
[privsep]
helper_command = sudo neutron-rootwrap /etc/neutron/rootwrap.conf privsep-helper
##########################
File openvswitch_agent.ini
##########################
[agent]
tunnel_types = vxlan
l2_population = true
arp_responder = true
[securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
[ovs]
bridge_mappings = physnet1:brens33-ovs
datapath_type = system
ovsdb_connection = tcp:127.0.0.1:6640
local_ip = 192.168.213.36
Openstack Security groups link attached to the instances network
[root#controller0 kolla]# openstack security group show be8d2de7-6bd4-4702-9b9f-c3e0f96d451a
+-----------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at | 2021-07-31T12:06:30Z |
| description | Project-00000 |
| id | be8d2de7-6bd4-4702-9b9f-c3e0f96d451a |
| location | cloud='', project.domain_id=, project.domain_name=, project.id='8d4b5b9558d64a04b34b797db97157bf', project.name=, region_name='Toulouse', zone= |
| name | Project-00000 |
| project_id | 8d4b5b9558d64a04b34b797db97157bf |
| revision_number | 6 |
| rules | created_at='2021-07-31T12:06:57Z', direction='ingress', ethertype='IPv4', id='5a896360-c712-4c93-bda9-be669662915e', port_range_max='22', port_range_min='22', protocol='tcp', remote_ip_prefix='0.0.0.0/0', updated_at='2021-07-31T12:06:57Z' |
| | created_at='2021-07-31T12:06:45Z', direction='ingress', ethertype='IPv6', id='7e8642ed-05d2-44a1-9034-216856d21492', protocol='ipv6-icmp', remote_ip_prefix='::/0', updated_at='2021-07-31T12:06:45Z' |
| | created_at='2021-07-31T12:06:31Z', direction='egress', ethertype='IPv6', id='85074747-5623-4142-86a3-045bf3b84ce6', updated_at='2021-07-31T12:06:31Z' |
| | created_at='2021-07-31T12:06:38Z', direction='ingress', ethertype='IPv4', id='86270591-3ad2-4feb-a278-5c2a5968fd27', protocol='icmp', remote_ip_prefix='0.0.0.0/0', updated_at='2021-07-31T12:06:38Z' |
| | created_at='2021-07-31T12:06:31Z', direction='egress', ethertype='IPv4', id='8fa6cb0e-7616-4b0e-9662-887dd012e777', updated_at='2021-07-31T12:06:31Z' |
| | created_at='2021-07-31T12:07:05Z', direction='ingress', ethertype='IPv6', id='acd0daab-a5b7-4eb3-9e2b-5c848f546ba6', port_range_max='22', port_range_min='22', protocol='tcp', remote_ip_prefix='::/0', updated_at='2021-07-31T12:07:05Z' |
| stateful | True |
| tags | [u'Project-00000', u'TrashProject'] |
| updated_at | 2021-07-31T12:07:05Z |
+-----------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
[root#controller0 kolla]# openstack security group show 88e4c862-eed0-4884-b205-defd8a50c67b
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at | 2021-07-31T12:05:25Z |
| description | Default security group |
| id | 88e4c862-eed0-4884-b205-defd8a50c67b |
| location | cloud='', project.domain_id=, project.domain_name=, project.id='8d4b5b9558d64a04b34b797db97157bf', project.name=, region_name='Toulouse', zone= |
| name | default |
| project_id | 8d4b5b9558d64a04b34b797db97157bf |
| revision_number | 1 |
| rules | created_at='2021-07-31T12:05:26Z', direction='egress', ethertype='IPv4', id='26b1decc-0515-436a-a3a6-445e93c1797c', updated_at='2021-07-31T12:05:26Z' |
| | created_at='2021-07-31T12:05:26Z', direction='ingress', ethertype='IPv6', id='508e85c3-1bac-4407-903b-92be818e012b', remote_group_id='88e4c862-eed0-4884-b205-defd8a50c67b', updated_at='2021-07-31T12:05:26Z' |
| | created_at='2021-07-31T12:05:26Z', direction='egress', ethertype='IPv6', id='51abe797-cead-4790-86ee-3341af0253de', updated_at='2021-07-31T12:05:26Z' |
| | created_at='2021-07-31T12:05:26Z', direction='ingress', ethertype='IPv4', id='591c792d-c8c6-4282-8f6e-f66c9cc1c0f7', remote_group_id='88e4c862-eed0-4884-b205-defd8a50c67b', updated_at='2021-07-31T12:05:26Z' |
| stateful | True |
| tags | [] |
| updated_at | 2021-07-31T12:05:26Z |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Network topology
One port of the network
I can see on my host where openstack (docker) is , and with tcpdump, that icmp requests are well received from the VM instances, but on VM instances I did not see any ICMP reply.
I use tcpdump to catch some tcp packets, when analyzing them according to ip/tcp packet schema, the packet seems to be broken. Here is a sample packet I got from tcpdump output. Is any one familiar with them?
Should not the first 4 bit of ip packet always be 0100 in under ipv4?
ip packet: https://en.wikipedia.org/wiki/IPv4
some examples: http://mike.passwall.com/networking/samplepacket.html
13:11:43.330397 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.0.14.16668 > 36.24.146.114.64853: Flags [S.], cksum 0xdc0f (correct), seq 3029391223, ack 129060479, win 14480, options [mss 1460,sackOK,TS val 1254469916 ecr 1492278057,nop,wscale 6], length 0
0x0000: feee 809f 3247 5254 0054 aa9f 0800 4500 ....2GRT.T....E.
0x0010: 003c 0000 4000 4006 d813 ac10 000e 2418 .<..#.#.......$.
0x0020: 9272 411c fd55 b490 d777 07b1 4e7f a012 .rA..U...w..N...
0x0030: 3890 dc0f 0000 0204 05b4 0402 080a 4ac5 8.............J.
uname -a
# Linux VM_0_14_centos 2.6.32-754.2.1.el6.x86_64 #1 SMP Fri Jul 13 12:50:12 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
# tcpdump
tcpdump tcp -vv -XX -n -i eth0 port 16668
0x0000: feee 809f 3247 5254 0054 aa9f 0800 4500 ....2GRT.T....E.
The first 14 bytes are from the link layer (EN10MB). The IP layer only starts with 4500, where the 4 (binary 0100) are the first 4 bits which describe the version number, i.e. IP version 4.
These link layer data are explicitly requested by the -XX option which is used by the OP as pointed out in a comment by David Hoelzer. To cite from the documentation of tcpdump:
-XX When parsing and printing, in addition to printing the headers of each packet, print the data of each packet, including its link level header, in hex and ASCII.
I have couple of VMs running on Openstack. I have one data network gateway assigned into the switch with MTU=1500, where VMs has to running.
Also in Openstack, I have set the default MTU=1500 of the network.
I am trying to ping from the VM to gateway (OR any ip on same network) of the switch with 1500 packetsize, it's de-fragmenting the packet.
localhost:~# ping -M do -s 1500 10.4.14.18
PING 10.4.14.18 (10.4.14.18) 1500(1528) bytes of data.
From 10.4.14.17 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.4.14.17 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.4.14.17 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.4.14.17 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.4.14.17 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.4.14.17 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.4.14.17 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.4.14.17 icmp_seq=1 Frag needed and DF set (mtu = 1500
Instead, If I am sending packets with smaller mtu (1472) it works,
localhost:~# ping -M do -s 1472 10.4.14.18
PING 10.4.14.18 (10.4.14.18) 1472(1500) bytes of data.
1480 bytes from 10.4.14.18: icmp_seq=1 ttl=64 time=0.965 ms
1480 bytes from 10.4.14.18: icmp_seq=2 ttl=64 time=0.515 ms
^C
--- 10.4.14.18 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1875ms
rtt min/avg/max/mdev = 0.515/0.740/0.965/0.225 ms
I can see 28 bytes of difference, i don't understand, where this 28 bytes are being utilised ?
The 1500 byte MTU holds for standard Ethernet at the network layer. In other words: 1500 byte can be transmitted in Ethernet frames without being fragmented. However, further protocols on top of Ethernet of course cut into the maximum payload.
In your case (the case of ping) the additional protocols are IP and ICMP. They both have headers with lengths 20 byte and 8 byte, respectively.
This means that you can transmit at most
1500 bytes (Ethernet mtu) - 20 byte (IP header) - 8 byte (ICMP header)
= 1472 byte
See also this question regarding MTU for UDP.
Ping will add 28 bytes header and then send it.
So if you want to send -s 1500, the actual size is 1500 + 28 = 1528 bytes.
I am using TCPDUMP to intercept the network traffic on an Android device.
The command I use is
./tcpdump -tt -nn -vv tcp > tcp.log
In the result file (tcp.log), I found that there are not only TCP packets, but also some others with Ethernet address. (Some IP and Ethernet addresses are obfuscated due to privacy purpose).
1410451676.980763 IP (tos 0x0, ttl 41, id 0, offset 0, flags [DF], proto TCP (6), length 60)
54.204.ABC.144.80 > 172.31.DEF.178.59949: Flags [S.], seq 572870324, ack 3778403975, win 17898, options [mss 1380,sackOK,TS[|tcp]>
1410451676.980916 IP (tos 0x0, ttl 64, id 44656, offset 0, flags [DF], proto TCP (6), length 52)
172.31.DEF.178.59949 > 54.204.ABC.144.80: Flags [.], seq 1, ack 1, win 1369, options [nop,nop,TS[|tcp]>
1410451676.982167 IP (tos 0x0, ttl 64, id 44657, offset 0, flags [DF], proto TCP (6), length 701)
172.31.DEF.178.59949 > 54.204.ABC.144.80: Flags [P.], seq 1:650, ack 1, win 1369, options [nop,nop,TS[|tcp]>
1410451676.996114 00:24:f9:c3:XX:00 > d8:50:e6:2b:YY:6a, ethertype IPv6 (0x86dd), length 86:
0x0000: 6000 0000 0020 0634 2607 f8b0 400d 0c03 `......4&...#...
0x0010: 0000 0000 0000 00bc 2001 0468 0c80 4340 ...........h..C#
0x0020: b040 b100 7831 4228 146c c1cc ceb8 fc7a .#..x1B(.l.....z
1410451677.000783 00:24:f9:c3:XX:00 > d8:50:e6:2b:YY:6a, ethertype IPv6 (0x86dd), length 535:
0x0000: 6000 0000 01e1 0634 2607 f8b0 400d 0c03 `......4&...#...
0x0010: 0000 0000 0000 00bc 2001 0468 0c80 4340 ...........h..C#
0x0020: b040 b100 7831 4228 146c c1cc ceb8 fc7a .#..x1B(.l.....z
1410451677.000935 d8:50:e6:2b:YY:6a > 00:24:f9:c3:XX:00, ethertype IPv6 (0x86dd), length 86:
0x0000: 6000 0000 0020 0640 2001 0468 0c80 4340 `......#...h..C#
0x0010: b040 b100 7831 4228 2607 f8b0 400d 0c03 .#..x1B(&...#...
0x0020: 0000 0000 0000 00bc c1cc 146c 3b74 2fa9 ...........l;t/.
1410451677.011006 IP (tos 0x0, ttl 41, id 62137, offset 0, flags [DF], proto TCP (6), length 52)
54.204.ABC.144.80 > 172.31.DEF.178.59949: Flags [.], seq 1, ack 650, win 75, options [nop,nop,TS[|tcp]>
In a regular TCP packet header, the result includes its timestamp (UNIX time), IP packet flag+options, source IP address+port, destination IP address+port, and TCP flags.
BUT, what I do not understand is that there are some Ethernet packets in between and according to the results, these packets include their MAC address, instead of IP address.
Why is the case? Are they TCP packets?
Thanks for your answers/insights.
All those packets are Ethernet packets.
The version of tcpdump you're using was apparently not built with IPv6 support, so, while it can recognize IPv4-over-Ethernet packets and printout the IP information, it can't recognize IPv6-over-Ethernet packets, and just prints out the Ethernet-layer information.
You should ask whoever built that version of tcpdump why it doesn't include IPv6 support.