Github user wilderrodrigues commented on the pull request:
https://github.com/apache/cloudstack/pull/908#issuecomment-145233418
Hi @remibergsma @borisroman @DaanHoogland @miguelaferreira @wido @runseb ,
I did the following manual tests:
1. Create a redundant network offering
2. Create a VM using the new net offering
3. Add egress rules to 0.0.0.0/0 - All
4. Acquired a new public IP
5. Created FW (0.0.0.0/0 - 22) and PF (22-22 towards the VM)
```
[root@cs1 integration]# ssh 192.168.23.5
The authenticity of host '192.168.23.5 (192.168.23.5)' can't be established.
ECDSA key fingerprint is 69:80:c4:21:85:b1:fb:93:3c:75:86:8c:75:ae:3f:6b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.23.5' (ECDSA) to the list of known
hosts.
root@192.168.23.5's password:
# ls /
bin dev home lib64 lost+found mnt
proc run sys usr
boot etc lib linuxrc media opt
root sbin tmp var
# ip route show
default via 10.1.1.1 dev eth0
10.1.1.0/24 dev eth0 src 10.1.1.214
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
1000
link/ether 02:00:79:7f:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.214/24 brd 10.1.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::79ff:fe7f:3/64 scope link
valid_lft forever preferred_lft forever
# date
Sat Oct 3 09:34:55 UTC 2015
#
```
I then tried the following as well:
```
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
```
As you can see, I could not ping google from inside the VM. I then went to
the Master router and did:
```
root@r-14-VM:~# ip route show
10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.213
169.254.0.0/16 dev eth1 proto kernel scope link src 169.254.0.7
192.168.23.0/24 dev eth2 proto kernel scope link src 192.168.23.4
```
So, no default route on RVR routers. I then added them:
```
root@r-14-VM:~# route add default gw 192.168.23.1
root@r-14-VM:~# ip route show
default via 192.168.23.1 dev eth2
10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.213
169.254.0.0/16 dev eth1 proto kernel scope link src 169.254.0.7
192.168.23.0/24 dev eth2 proto kernel scope link src 192.168.23.4
root@r-14-VM:~#
```
After that, I went back to the VM and ping was successful!
```
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=48 time=9.765 ms
64 bytes from 8.8.8.8: seq=1 ttl=48 time=9.801 ms
64 bytes from 8.8.8.8: seq=2 ttl=48 time=9.343 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 9.343/9.636/9.801 ms
#
```
This bug is not related with this PR and was not mentioned before -
probably nobody tested it.
I would suggest to create a separate issue, which should include the fix
and a test to cover it. What do you think?
Concerning the conntrackd, I did the following:
```
root@r-14-VM:~# conntrackd -s
ERROR: parsing config file in line (102), symbol 'Multicast': syntax error
root@r-14-VM:~#
```
As you can see the configuration file is not good! And that's the same
problem that was reported before.
I also created a Redundant VPC in order to double check the conntrackd
configuration in the routers. The results were as follows:
```
root@r-17-VM:~#
root@r-17-VM:~# conntrackd -s
cache internal:
current active connections: 1
connections created: 12 failed: 0
connections updated: 12 failed: 0
connections destroyed: 11 failed: 0
cache external:
current active connections: 0
connections created: 4 failed: 0
connections updated: 0 failed: 0
connections destroyed: 4 failed: 0
traffic processed:
0 Bytes 0 Pckts
multicast traffic (active device=eth2):
6820 Bytes sent 5864 Bytes recv
364 Pckts sent 345 Pckts recv
0 Error send 0 Error recv
message tracking:
0 Malformed msgs 0 Lost msgs
root@r-17-VM:~#
```
I will apply the copy stuff and test again both rVPC and RVR.
Cheers,
Wilder
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
