cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-8915) Cannot SSH into VMs deployed Redundant VPC routers
Date Sat, 03 Oct 2015 10:05:26 GMT

    [ 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.
    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


> 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)

Mime
View raw message