openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #23398
Re: floodlight ignore subnet gateway due to PORT_DOWN and LINK_DOWN
I just comment some of floodlight codes and VMs can ping the gateway.
But I do not know why the gateway port and link is down, it is up in
namespace view:
root@controller
:/usr/src/eclipse# ip netns exec
qrouter-7bde1209-e8ed-4ae6-a627-efaa148c743c ip link
14: qr-8af2e01f-bb: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UNKNOWN
link/ether fa:16:3e:f7:3d:5e brd ff:ff:ff:ff:ff:ff
root@controller
:/usr/src/eclipse# ip netns exec
qrouter-7bde1209-e8ed-4ae6-a627-efaa148c743c ip addr
14: qr-8af2e01f-bb: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UNKNOWN
link/ether fa:16:3e:f7:3d:5e brd ff:ff:ff:ff:ff:ff
inet 100.0.0.1/24 brd 100.0.0.255 scope global qr-8af2e01f-bb
inet6 fe80::f816:3eff:fef7:3d5e/64 scope link
valid_lft forever preferred_lft forever
On Tue, May 7, 2013 at 5:01 PM, Liu Wenmao <marvelliu@xxxxxxxxx> wrote:
> hi
>
> I use quantum grizzly with namespace and floodlight, but VMs can not ping
> its gateway. It seems that floodlight ignore devices whose status
> is PORT_DOWN or LINK_DOWN, somehow the subnetwork gateway is
> really PORT_DOWN and LINK_DOWN.. is it normal?or how can I change its
> status to normal?
>
> root@controller:~# ovs-ofctl show br-int
> OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000e2ed9e9b6942
> n_tables:255, n_buffers:256
> features: capabilities:0xc7, actions:0xfff
> 1(qr-c5496165-c7): addr:5e:67:22:5b:d5:0e
> config: PORT_DOWN
> state: LINK_DOWN
> * 2(qr-8af2e01f-bb): addr:e4:00:00:00:00:00<--------------------this is
> the gateway.....*
> * config: PORT_DOWN*
> * state: LINK_DOWN*
> 3(qr-48c69382-4f): addr:22:64:6f:3a:9f:cd
> config: PORT_DOWN
> state: LINK_DOWN
> 4(patch-tun): addr:8e:90:4c:aa:d2:06
> config: 0
> state: 0
> 5(tap5b5891ac-94): addr:6e:52:f7:c1:ef:f4
> config: PORT_DOWN
> state: LINK_DOWN
> 6(tap09a002af-66): addr:c6:cb:01:60:3f:8a
> config: PORT_DOWN
> state: LINK_DOWN
> 7(tap160480aa-84): addr:96:43:cc:05:71:d5
> config: PORT_DOWN
> state: LINK_DOWN
> 8(tapf6040ba0-b5): addr:e4:00:00:00:00:00
> config: PORT_DOWN
> state: LINK_DOWN
> 9(tap0ded1c0f-df): addr:12:c8:b3:5c:fb:6a
> config: PORT_DOWN
> state: LINK_DOWN
> 10(tapaebb6140-31): addr:e4:00:00:00:00:00
> config: PORT_DOWN
> state: LINK_DOWN
> 11(tapddc3ce63-2b): addr:e4:00:00:00:00:00
> config: PORT_DOWN
> state: LINK_DOWN
> 12(qr-9b9a3229-19): addr:e4:00:00:00:00:00
> config: PORT_DOWN
> state: LINK_DOWN
> LOCAL(br-int): addr:e2:ed:9e:9b:69:42
> config: PORT_DOWN
> state: LINK_DOWN
> OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=0
>
>
> floodlight codes:
> if (entity.hasSwitchPort() &&
>
> !topology.isAttachmentPointPort(entity.getSwitchDPID(),
>
> entity.getSwitchPort().shortValue())) {
> if (logger.isDebugEnabled()) {
> logger.debug("Not learning new device on internal"
> + " link: {}", entity);
> }
>
> public boolean portEnabled(OFPhysicalPort port) {
> if (port == null)
> return false;
> if ((port.getConfig() & OFPortConfig.OFPPC_PORT_DOWN.getValue()) >
> 0)
> return false;
>
References