[
https://issues.apache.org/jira/browse/CLOUDSTACK-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14942213#comment-14942213
]
ASF GitHub Bot commented on CLOUDSTACK-8915:
--------------------------------------------
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.
[email protected]'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
> Cannot SSH into VMs deployed Redundant VPC routers
> --------------------------------------------------
>
> Key: CLOUDSTACK-8915
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8915
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
> Affects Versions: 4.6.0
> Reporter: Wilder Rodrigues
> Assignee: Wilder Rodrigues
> Priority: Blocker
>
> The Marvin test under componenet/test_vpc_redundant.py no longer passes. I
> also tried to test it manually, but unfortunately the feature is now broken.
> * Create a Redundant VPC
> * Add a tier
> * Add a new VM to the tier
> * Add an ACL, open port 22 and associate the ACL with the tier
> * Acquire a pub IP
> * Add a PF rule to port 22 towards the VM
> * Try to SSH to the VM through the Pub IP
> It fails with "No route to host"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
