Bug 470059

Summary: IPv6 netfilter: output routing rules based on fwmark don't work
Product: Red Hat Enterprise Linux 5 Reporter: Tomas Smetana <tsmetana>
Component: kernelAssignee: Anton Arapov <anton>
Status: CLOSED ERRATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.2CC: anton, cward, dzickus, imatusov, nobody, pamadio, qcai, tao
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 517327 (view as bug list) Environment:
Last Closed: 2009-09-02 08:38:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 517327    
Attachments:
Description Flags
Proposed patch
none
proposed patch. none

Description Tomas Smetana 2008-11-05 15:31:45 UTC 
Description of problem:
The RPDB rules based on fwmark set in OUTPUT chain are not taken in account in output packet routing.

Version-Release number of selected component (if applicable):
kernel-2.6.18-8.el5 but reproducible with the latest RHEL-5 kernel as well.

How reproducible:
Always

Steps to Reproduce:
Assume the system with two eth interfaces set up the following way:

# IP addresses
ifconfig eth0 inet6 add 3FFE::1:2/112
ifconfig eth1 inet6 add 3FFE::2:2/112
ifconfig eth0 inet6 add 3FFE::7:1/112
ifconfig eth1 inet6 add 3FFE::8:1/112

# Packet marking
ip6tables -A OUTPUT -t mangle -p 58 -s 3FFE::7:1/128 -j MARK --set-mark 1
ip6tables -A OUTPUT -t mangle -p 58 -s 3FFE::8:1/128 -j MARK --set-mark 2

# Routing rules
ip -f inet6 route add default via 3FFE::1:1
ip -f inet6 rule add fwmark 1 table 200
ip -f inet6 rule add fwmark 2 table 201
ip -f inet6 route add default via 3FFE::1:1 table 200
ip -f inet6 route add default via 3FFE::2:1 table 201

The goal is to have ICMPv6 packets originating from 3ffe::8:1 to be routed through 3ffe::2:1 and packets from 3ffe::7:1 to go through 3ffe::1:1. The tables 200 and 201 have both higher priority than the default routing table.

Assume there exist an interface 3ffe::3:1 reachable from both 3ffe::1:1 and 3ffe::2:1 routers. Trying to ping 3ffe::3:1:

ping6 3ffe::3:1 -I 3ffe::8:1
  
Actual results:
The ICMPv6 echo requests go through 3ffe::1:1

Expected results:
The ICMPv6 echo requests go through 3ffe::2:1

Additional info:
This was fixed in later kernels (2.6.20?). I will attach the patch based on the newer code that seems to solve the issue.
Comment 1 Tomas Smetana 2008-11-05 15:32:48 UTC 
Created attachment 322591 [details]
Proposed patch

This seems to help but I'm not sure how complete or correct the patch is.
Comment 4 Anton Arapov 2009-01-19 14:38:32 UTC 
Created attachment 329347 [details]
proposed patch.

backport of the commit# 9f40ac713c49fb6ca655550b620edc85c445d743
Comment 10 RHEL Program Management 2009-02-16 15:35:00 UTC 
Updating PM score.
Comment 11 RHEL Program Management 2009-02-20 15:39:52 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 24 Chris Ward 2009-07-03 18:12:12 UTC 
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.
Comment 35 errata-xmlrpc 2009-09-02 08:38:07 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html