openstack team mailing list archive

[The King in Yellow <yellowking@xxxxxxxxx>]

A little more information, or a completely different problem...I just
realized my network node can't ping its public gateway.  (Instead of
7.7.7.0/24, I am using 10.42.36.0/23.  My gateway is .1 (and has
non-redundant IP of .10), and my Network Node IP is .130).  This did work
at one time.

root@os-network:~# ping 10.42.36.1
PING 10.42.36.1 (10.42.36.1) 56(84) bytes of data.
>From 10.42.36.130 icmp_seq=1 Destination Host Unreachable
>From 10.42.36.130 icmp_seq=2 Destination Host Unreachable
>From 10.42.36.130 icmp_seq=3 Destination Host Unreachable
^C
--- 10.42.36.1 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4023ms
pipe 3
root@os-network:~# arp -an
? (10.42.36.1) at <incomplete> on qg-28108125-11
? (10.10.10.2) at 00:50:56:81:25:73 [ether] on eth1
? (10.42.38.11) at 40:55:39:25:a5:c1 [ether] on eth3
? (192.168.0.1) at 00:50:56:81:48:02 [ether] on eth0
? (10.5.5.4) at fa:16:3e:95:94:9c [ether] on tap45ffdc5f-da
? (10.42.36.10) at <incomplete> on qg-28108125-11
? (10.5.5.3) at fa:16:3e:8d:6d:13 [ether] on tap45ffdc5f-da
? (10.42.38.1) at 00:07:b4:01:b5:01 [ether] on eth3
root@os-network:~#

Nor does it work the other way:


>From my gateway:

sniktc-nx10A-7010-KXDC-E12# sho run int vlan402

!Command: show running-config interface Vlan402
!Time: Fri Mar  8 14:11:45 2013

version 5.1(3)

interface Vlan402
  vrf member Enterprise
  no ip redirects
  ip address 10.42.4.10/22
  ip router eigrp 1
  ip pim sparse-mode
  glbp 402
    ip 10.42.4.1
    priority 200
    authentication text KXDCglbp402
  no shutdown
  mtu 9216

sniktc-nx10A-7010-KXDC-E12# ping 10.42.36.130 vrf Enterprise source
10.42.36.10
PING 10.42.36.130 (10.42.36.130) from 10.42.36.10: 56 data bytes
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out

--- 10.42.36.130 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss
sniktc-nx10A-7010-KXDC-E12#



root@os-network:~# ifconfig qg-28108125-11
qg-28108125-11 Link encap:Ethernet  HWaddr fa:16:3e:a9:a3:4c
          inet addr:10.42.36.130  Bcast:10.42.37.255  Mask:255.255.254.0
          inet6 addr: fe80::f816:3eff:fea9:a34c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:34 errors:0 dropped:0 overruns:0 frame:0
          TX packets:354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4840 (4.8 KB)  TX bytes:22619 (22.6 KB)

root@os-network:~# ovs-vsctl show
e232f8c8-1cb8-4cf5-9de5-49f41e59fd38
    Bridge br-tun
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
        Port "gre-2"
            Interface "gre-2"
                type: gre
                options: {in_key=flow, out_key=flow, remote_ip="10.10.10.2"}
    Bridge br-ex
        Port "qg-28108125-11"
            Interface "qg-28108125-11"
                type: internal
        Port br-ex
            Interface br-ex
                type: internal
        Port "eth2"
            Interface "eth2"
    Bridge br-int
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
        Port "tap45ffdc5f-da"
            tag: 1
            Interface "tap45ffdc5f-da"
                type: internal
        Port "qr-9f9041ce-65"
            tag: 1
            Interface "qr-9f9041ce-65"
                type: internal
    ovs_version: "1.4.0+build0"
root@os-network:~#

I suppose something has gone wrong inside quantum on the network node?  Is
there a good way to blow everything away and rebuild?  I tried the
following, but the quantum-networking script doesn't really work this way,
as it assumes it is creating items (and getting the uuids in return), which
doesn't work the second time through.

ovs-vsctl del-br br-int
ovs-vsctl del-br br-ex

service openvswitch-switch restart

ovs-vsctl add-br br-int
ovs-vsctl add-br br-ex
ovs-vsctl add-port br-ex eth2
ip link set up br-ex

service quantum-plugin-openvswitch-agent restart
service quantum-dhcp-agent restart
service quantum-l3-agent restart

sh ./quantum-networking-filled.sh

service quantum-l3-agent restart


Here is what quantum looks like right now-- note the additional
provider-routers, I'm guessing from failed runs of the quantum-networking
script.  Note also ...771's external gateway of ...3de0, which isn't
showing up anywhere...could that be the problem?  Should that be subnet
...06f6?

root@os-network:~# quantum subnet-list
+--------------------------------------+------+---------------+--------------------------------------------------+
| id                                   | name | cidr          |
allocation_pools                                 |
+--------------------------------------+------+---------------+--------------------------------------------------+
| 0617c874-9a95-40dc-ae4f-bb44eec806f6 |      | 10.5.5.0/24   | {"start":
"10.5.5.2", "end": "10.5.5.254"}       |
| cde12bce-eeed-4041-87e3-5a1b905b3c98 |      | 10.42.36.0/23 | {"start":
"10.42.36.130", "end": "10.42.36.150"} |
+--------------------------------------+------+---------------+--------------------------------------------------+
root@os-network:~# quantum router-list
+--------------------------------------+-----------------+--------------------------------------------------------+
| id                                   | name            |
external_gateway_info                                  |
+--------------------------------------+-----------------+--------------------------------------------------------+
| 8b8e7a08-16ba-4ab0-9800-88d0b17b6771 | provider-router | {"network_id":
"e00341e1-3e59-4b8b-8c3a-7b227b423dc0"} |
| 76fb89b9-ec11-4cad-ab0f-e160c3f0d4e7 | provider-router |
null                                                   |
| af76d59e-22b2-4fbd-a95d-0b891824957e | provider-router |
null                                                   |
+--------------------------------------+-----------------+--------------------------------------------------------+
root@os-network:~# quantum port-list
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+
| id                                   | name | mac_address       |
fixed_ips
|
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+
| 9f9041ce-654d-4706-a208-60cf5fca5d90 |      | fa:16:3e:e2:38:da |
{"subnet_id": "0617c874-9a95-40dc-ae4f-bb44eec806f6", "ip_address":
"10.5.5.1"}     |
| 28108125-119c-4ce4-a3a3-537639589791 |      | fa:16:3e:a9:a3:4c |
{"subnet_id": "cde12bce-eeed-4041-87e3-5a1b905b3c98", "ip_address":
"10.42.36.130"} |
| 45ffdc5f-dad9-444a-aff4-3d39b607f828 |      | fa:16:3e:36:2e:54 |
{"subnet_id": "0617c874-9a95-40dc-ae4f-bb44eec806f6", "ip_address":
"10.5.5.2"}     |
| fe6d3b06-c27d-40a4-bba2-7b5d6060799a |      | fa:16:3e:8d:6d:13 |
{"subnet_id": "0617c874-9a95-40dc-ae4f-bb44eec806f6", "ip_address":
"10.5.5.3"}     |
| 2c6f106f-de2a-46d1-afbd-b6d42a3557b3 |      | fa:16:3e:95:94:9c |
{"subnet_id": "0617c874-9a95-40dc-ae4f-bb44eec806f6", "ip_address":
"10.5.5.4"}     |
+--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+
root@os-network:~#