Re: source-validation enable and default route?

While looking for how to handle multicast traffic, I came across this thread. It seems that (incoming) multicast traffic can be blocked if strict reverse path filtering is enabled, although I don't completely understand yet why. Is this because traffic from 224.0.0.0/4 is different from what is expected on the interfaces? Would it be solved using loose reverse path filtering?

Re: source-validation enable and default route?

While looking for how to handle multicast traffic, I came across this thread. It seems that (incoming) multicast traffic can be blocked if strict reverse path filtering is enabled, although I don't completely understand yet why. Is this because traffic from 224.0.0./4 is different from what is expected on the interfaces? Would it be solved using loose reverse path filtering?

source-validation is on the source address while multicast is a destination address.

Re: source-validation enable and default route?

Thanks for your quick reply, Stig. Just for my own understanding: do you understand then what is exactly the problem described in this blog post? Although I completely understand your answer, it seems that the issue raised there seems to be a non-issue.

Re: source-validation enable and default route?

Thanks for your quick reply, Stig. Just for my own understanding: do you understand then what is exactly the problem described in this blog post? Although I completely understand your answer, it seems that the issue raised there seems to be a non-issue.

Well the only thing I can think of is that he mentioned eth0, eth1 and disabling rpf check on ppp0. I've heard of some IPTV implementations that the real "wan" interface is authenticated over pppoe, but that IPTV multicast comes on the parent interface instead of the pppoe. So lets say the multicast packet comes in eth0 with source address 1.1.1.1 and destination 224.0.0.1. The rpf check for 1.1.1.1 says that to get there you use the default route on pppoe, but since it came in on eth0 it gets dropped.

So my conclusion now is that rp_filter is set to '1' by default, and that disabling it for the first time doesn't help. Then, when I remove the 'disable' config again and commit that, it's actually disabled. I can however only produce this behavior once per interface.

Re: source-validation enable and default route?

By the way, I realized that up to some two weeks ago, I used source-validation loose in my firewall config. At that point in time, I didn't know I could configure this per interface. Can it be the case that the bug is caused by the fact that source validation can be configured in two places, i.e., in firewall and interfaces? It would be nice to somehow find out what is causing the inconsistency between CLI and file contents, as unpredicable behavior is the result.

Re: source-validation enable and default route?

Well I did a bunch of testing of both loose and strict setting and as long as I delete the source-validation node it goes back to zero. However I did find that if I have either strict or loose and then change it to disable, then the value does not go back to zero. I'll look into that.

rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path
Each incoming packet is tested against the FIB and if the interface
is not the best reverse path the packet check will fail.
By default failed packets are discarded.
2 - Loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet's source address is also tested against the FIB
and if the source address is not reachable via any interface
the packet check will fail.
Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric routing
or other complicated routing, then loose mode is recommended.
The max value from conf/{all,interface}/rp_filter is used
when doing source validation on the {interface}.
Default value is 0. Note that some distributions enable it
in startup scripts.

So it looks to me like the per-interface values shouldn't mess with the "all" values, but currently it does.

Re: source-validation enable and default route?

What will be the upcoming steps with regard to this issue? It would be nice if this could be fixed rather soon, since the issue arises every time the router is rebooted, for example. I would be happy to test it for you