Bug 2203020 - mirror doesn't work when remote is ipv6
Summary: mirror doesn't work when remote is ipv6
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Fast Datapath
Classification: Red Hat
Component: ovn23.03
Version: FDP 22.A
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: lorenzo bianconi
QA Contact: Jianlin Shi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-05-11 04:10 UTC by OVN Bot
Modified: 2023-07-06 19:17 UTC (History)
3 users (show)

Fixed In Version: ovn23.03-23.03.0-45.el9fdp
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-07-06 19:17:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FD-2880 0 None None None 2023-05-16 18:44:27 UTC
Red Hat Product Errata RHBA-2023:3987 0 None None None 2023-07-06 19:17:48 UTC

Description OVN Bot 2023-05-11 04:10:14 UTC
This is an automatically-generated clone of issue https://bugzilla.redhat.com/show_bug.cgi?id=2168119

Comment 4 Jianlin Shi 2023-05-22 02:42:12 UTC
Verified on ovn23.03-23.03.0-45.el9:


[root@wsfd-advnetlab17 bz2168119]# rpm -qa | grep -E "openvswitch3.0|ovn23.03"                        
openvswitch3.0-3.0.0-45.el9fdp.x86_64                                                                 
ovn23.03-23.03.0-45.el9fdp.x86_64                                                                     
ovn23.03-central-23.03.0-45.el9fdp.x86_64                                                             
ovn23.03-host-23.03.0-45.el9fdp.x86_64

[root@wsfd-advnetlab16 ~]# tcpdump  -i ip6gretap1 -nnle -v
dropped privs to tcpdump
tcpdump: listening on ip6gretap1, link-type EN10MB (Ethernet), capture size 262144 bytes              
22:41:01.802066 00:00:00:01:01:11 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::200:ff:fe01:111 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 00:00:00:01:01:11                             
22:41:07.367523 00:00:00:00:00:01 > 00:00:00:01:01:01, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.254 is-at 00:00:00:00:00:01, length 28
22:41:07.368990 00:00:00:00:00:01 > 00:00:00:01:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 33575, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.2.1 > 192.168.1.1: ICMP echo reply, id 54282, seq 1, length 64                            
22:41:08.368396 00:00:00:00:00:01 > 00:00:00:01:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 34534, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.2.1 > 192.168.1.1: ICMP echo reply, id 54282, seq 2, length 64
22:41:09.418219 00:00:00:00:00:01 > 00:00:00:01:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 35540, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.2.1 > 192.168.1.1: ICMP echo reply, id 54282, seq 3, length 64

Comment 6 errata-xmlrpc 2023-07-06 19:17:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (ovn23.03 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:3987


Note You need to log in before you can comment on or make changes to this bug.