Almost a month ago, certain nets of ours (AS10368) lost connectivity to a major provider. The problem was tracked down to the major provider having enabled RPF, or "ip verify unicast reverse-path" in IOS-speak, on one of their private peers with one of our upstreams to whom we don't announce those nets. At the time, I decided not to post a warning to nanog as it appeared to be a mistake and an isolated case. Apparently, the same major provider had/has RPF enabled on other peering interfaces also and one more instances were tracked down in the last 24 hours. Enabling RPF on the "backbone" is not a good idea as long as path-asymmetry exists -- unless you are trying to send a message to an unresponsive peer who is sending you source-spoofed packets. Please take this as an appeal to double-check your use of RPF and restrict it to the "edges" of your network. Thanks, Adi
Almost a month ago, certain nets of ours (AS10368) lost connectivity to a major provider. The problem was tracked down to the major provider having enabled RPF, or "ip verify unicast reverse-path" in IOS-speak, on one of their private peers with one of our upstreams to whom we don't announce those nets.
At the time, I decided not to post a warning to nanog as it appeared to be a mistake and an isolated case.
Apparently, the same major provider had/has RPF enabled on other peering interfaces also and one more instances were tracked down in the last 24 hours.
There was an instance of this ocurring in our network that's probably the one you refer to there. As a matter of policy we certainly don't enable RPF to our peers. It's not clear to me as of yet how this particular error ocurred, but it certainly was an error on someone's part and we certainly do know better. We're still attempting to track down what particular sequence of events caused this misconfiguration. --jhawk
participants (2)
-
John Hawkinson -
R.P. Aditya