[Ubuntu Icehouse R2.1 Build 39] DNS Adress is not reachable from BMS

Bug #1428135 reported by chhandak
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R2.1
Fix Committed
Critical
Anand H. Krishnan
Trunk
Fix Committed
Critical
Anand H. Krishnan

Bug Description

Ping from BMS to default DNS server (x.x.x.2) is not working.
Packets are coming till TSN node and getting forwarded to pkt0 interface

ON TSN Node
------------
root@nodea13:~# tcpdump -ni p4p1 udp port 4789
tcpdump: WARNING: p4p1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on p4p1, link-type EN10MB (Ethernet), capture size 65535 bytes
19:07:37.635407 IP 10.204.216.9.60913 > 34.34.34.34.4789: VXLAN, flags [I] (0x08), vni 2222
IP6 fe80::f4:aaff:fe10:8213 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s)
, length 28
19:07:37.656807 IP 34.34.34.34.49762 > 10.204.216.9.4789: VXLAN, flags [I] (0x08), vni 2222
IP 1.1.1.5 > 1.1.1.2: ICMP echo request, id 10859, seq 2737, length 64
19:07:38.139440 IP 10.204.216.9.50264 > 34.34.34.34.4789: VXLAN, flags [I] (0x08), vni 2222
IP6 fe80::f4:aaff:fe10:8213 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s)
, length 28
19:07:38.664745 IP 34.34.34.34.49762 > 10.204.216.9.4789: VXLAN, flags [I] (0x08), vni 2222
IP 1.1.1.5 > 1.1.1.2: ICMP echo request, id 10859, seq 2738, length 64
19:07:39.634578 IP 34.34.34.34.52086 > 10.204.216.9.4789: VXLAN, flags [I] (0x08), vni 2222
ARP, Request who-has 1.1.1.2 tell 1.1.1.5, length 46
19:07:39.672822 IP 34.34.34.34.49762 > 10.204.216.9.4789: VXLAN, flags [I] (0x08), vni 2222
IP 1.1.1.5 > 1.1.1.2: ICMP echo request, id 10859, seq 2739, length 64

root@nodea13:~# tcpdump -ni pkt0 -xx -vv
tcpdump: WARNING: pkt0: no IPv4 address assigned
tcpdump: listening on pkt0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:06:04.920754 IP0 bad-hlen 0
        0x0000: 0000 0000 0001 0000 5e00 0100 0800 0000
        0x0010: 0000 0004 0000 0000 0000 0000 0025 90aa
        0x0020: a8e8 2c21 72a0 4a80 0800 4500 0086 d7f8
        0x0030: 0000 3e11 7d55 2222 2222 0acc d809 c262
        0x0040: 12b5 0072 0000 0800 0000 0008 ae00 0025
        0x0050: 90aa a8e8 0025 90e7 816f 0800 4500 0054
        0x0060: 0000 4000 3f01 37a1 0101 0105 0101 0102
        0x0070: 0800 7e6e 2a6b 0a55 440a f754 0000 0000
        0x0080: 3d9f 0d00 0000 0000 1011 1213 1415 1617
        0x0090: 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627
        0x00a0: 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637

Setup Details
----------------
Setup
————
host1 = 'root@10.204.216.43'
host2 = 'root@10.204.216.48'
host3 = 'root@10.204.216.8'
host4 = 'root@10.204.216.9'
host5 = 'root@10.204.216.11'
host6 = 'root@10.204.216.13'
host7 = 'root@10.204.216.24'

env.roledefs = {

    'all': [host1, host2, host3, host4, host5, host6, host7],
    'cfgm': [host1, host2],
    'openstack':[host2],
    'control':[host2, host3],
    'compute': [host4,host5, host6, host7],
    'tsn': [host4],
    'toragent': [host4],
    'collector': [host1],
    'webui': [host1],
    'database': [host1, host2, host3],
    'build': [host_build],

}

Vrouter team aware of the problem. Opening this bug as tracker

chhandak (chhandak)
description: updated
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : R2.1
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/8055
Committed: http://github.org/Juniper/contrail-vrouter/commit/a06f19d60761287728dba554fe57e91da205861a
Submitter: Zuul
Branch: R2.1

commit a06f19d60761287728dba554fe57e91da205861a
Author: Anand H. Krishnan <email address hidden>
Date: Wed Mar 4 19:19:00 2015 +0530

vrf for packets sent to agent via encap nexthop should come from metadata
and not from ingress interface

Till now, packets that were sent to agent via an encap nexthop, had the vrf
in the agent header set to the ingress interface vrf. The vrf value in all
cases have to be the vrf to which the packet has been classified to.

Bug fix for arp behavior: If an arp request ingressed from fabric interface
and if the proxy bit was set in the route, but the stitching information was
not present, vrouter used to proxy with the vhost mac. This behavior is wrong.
vrouter should proxy only if the destination is hosted by it or if the
destination is not hosted and it is a TSN or if the request was meant for a
host in the cp port.

Closes BUG: #1428135

Change-Id: Ibe543c743a07834a87e1512ac305f1e0f32d5d30

Changed in juniperopenstack:
assignee: nobody → Anand H. Krishnan (anandhk)
tags: added: releasenote
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : master

Review in progress for https://review.opencontrail.org/8243
Submitter: Anand H. Krishnan (<email address hidden>)

information type: Proprietary → Public
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/8243
Committed: http://github.org/Juniper/contrail-vrouter/commit/6433c657043b236afb6545048f68cd272541653e
Submitter: Zuul
Branch: master

commit 6433c657043b236afb6545048f68cd272541653e
Author: Anand H. Krishnan <email address hidden>
Date: Wed Mar 4 19:19:00 2015 +0530

vrf for packets sent to agent via encap nexthop should come from metadata
and not from ingress interface

Till now, packets that were sent to agent via an encap nexthop, had the vrf
in the agent header set to the ingress interface vrf. The vrf value in all
cases have to be the vrf to which the packet has been classified to.

Bug fix for arp behavior: If an arp request ingressed from fabric interface
and if the proxy bit was set in the route, but the stitching information was
not present, vrouter used to proxy with the vhost mac. This behavior is wrong.
vrouter should proxy only if the destination is hosted by it or if the
destination is not hosted and it is a TSN or if the request was meant for a
host in the cp port.

Closes-Bug: #1428135

Change-Id: Ibe543c743a07834a87e1512ac305f1e0f32d5d30

Changed in juniperopenstack:
status: New → Fix Committed
Changed in juniperopenstack:
importance: Undecided → Critical
Changed in juniperopenstack:
milestone: none → r2.20-fcs
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.