Tom Eastep wrote:
> On 04/29/2013 07:49 PM, Dash Four wrote:
>
>> Dash Four wrote:
>>
>>> 3. Specifying "blackhole" routes for a provider, as well as 'main'
>>> generates an error:
>>>
>>> routes
>>> ~~~~~~
>>> dmz7 62.252.0.0/14 blackhole
>>> main 62.252.0.0/14 blackhole
>>>
>>> during either cold start, or a reload, I get the following error:
>>>
>>> shorewall[7294]: Adding Providers...
>>> shorewall[7294]: RTNETLINK answers: File exists
>>> shorewall[7294]: ERROR: Command "ip -4 route add blackhole
>>> 62.252.0.0/14 table dmz7" Failed
>>> root: ERROR:Shorewall start failed
>>>
>>> This error is mystifying me, because in the generated .start file,
>>> there is only one reference to 62.252.0.0/14 so I have absolutely no
>>> idea why ip is moaning at me. When I execute this command from the
>>> shell, all is well - no problem!
>>>
>> I think I found what is causing this - in the generated firewall file, I
>> have:
>>
>> $IP -4 -o route show table main | while read net route; do
>> case $net in
>> default)
>> ;;
>> blackhole|prohibit|unreachable)
>> run_ip route add table dmz7 $net $route
>> ;;
>> *)
>> case $(find_device $route) in
>> eth0)
>> case $net in
>> 255.255.255.255*)
>> ;;
>> *)
>> run_ip route add table dmz7 $net $route
>> ;;
>> esac
>> ;;
>> esac
>> ;;
>> esac
>> done
>>
>> The above may explain why adding the blackhole route fails, even though
>> I have "none" in the COPY column in "providers". It also explains why
>> the "src" link route is also copied over to the provider table.
>>
>
> That was added at your request -- you wanted the blackhole routes to
> appear in your provider tables. But I don't understand why it isn't
> working in your case.
>
Indeed it was, but, as I recall, this was done just before you
introduced the blackhole-type route definitions in "routes".
The problem is caused by the "blackhole|prohibit|unreachable" case
branch I quoted above. When I define a blackhole routes in 'main', as
well as in the provider table using "routes", shorewall starts creating
these as defined and then attempts to copy the blackhole routes over to
my provider's table, but since they already exist, that is why ip starts
moaning (and rightly so) as the routes already exist. In my view, the
appropriate course of action would be one of:
1. Take the "blackhole|prohibit|unreachable" case branch off completely
and leave defining such routes up to the user (at the end of the day,
this is what "routes" is for, right?); or
2. Modify that case branch slightly to be dependent on a (newly-defined)
separate option for the "COPY" column (I already suggested "blackhole",
"prohibit" or "unreachable") which copies, selectively, the desired
routes across. In other words, if I have "blackhole" in COPY, then
shorewall should copy the blackhole routes over from the table indicated
in the DUPLICATE column to the provider table; or
3. Leave everything as is and let the user deal with the mess themselves.
My personal preference is for option 2 above as it gives me a close
control of everything, but I wouldn't mind if both options 1 and 2 are
implemented.
>> If the above is indeed the cause for this error, then perhaps you could
>> add another set of options called "blackhole", "prohibit" and
>> "unreachable" to the COPY column so that these routes are copied over -
>> when "none" is specified, shorewall should, by definition, copy only the
>> routes with regards to the interface specified (personally, I am against
>> that as well - I think that "none" should really mean nothing is copied
>> over, but this might break backwards compatibility). I also think that
>> there should be an option for nothing at all to be copied over -
>> currently I don't see a way to do this.
>>
>
> Leave the DUPLICATE column empty.
>
I did consider this (although I did not try it), but the man page says
to leave it empty if my USE_DEFAULT_RT=Yes: 'This column should contain
a dash ("-') when USE_DEFAULT_RT=Yes'. As you know, I have
USE_DEFAULT_RT=No, so I wasn't sure whether to use a dash or not. Maybe
an update in the description of this column is in order.
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
