North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: different flavours of uRPF [RE: register.com down sev0?]

  • From: Barry Greene (bgreene)
  • Date: Fri Oct 27 17:12:48 2006
  • Authentication-results: sj-dkim-3.cisco.com; [email protected]; dkim=pass (sig from cisco.com verified; );
  • Dkim-signature: a=rsa-sha1; q=dns; l=1065; t=1161983212; x=1162847212;c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; [email protected]; z=From:=22Barry=20Greene=20\(bgreene\)=22=20<[email protected]>|Subject:RE=3A=20different=20flavours=20of=20uRPF=20[RE=3A=20register.com=20down=20sev0?];X=v=3Dcisco.com=3B=20h=3DNAz/AQ/fSYxMWo1r+SwPq/bYSmg=3D; b=WD6JiuLpnAOOD9OWDFa73naq+HZtCOYXB2hPkc4NLlyWxdLnO3panR2F29auz7rkiEMi1a4EB1w8eu8rjkVh3rfU91UhsIlmZbbiE+kAGE/VUQXnRAFzKZuvls2d8k7j;
 

> > Strict mode uRPF is likely to be implemented by performing a full 
> > forwarding table lookup and then comparing the packet's incoming 
> > interface to the interface from the forwarding table result.

uRPF uses the same look up algorithm as you do when you look up the
destination address for next hop. 
 
> Pekka might have meant wouldn't you build a separate 'urpf 
> table' per interface perhaps? (just guessing at his intent) 
> though there is only one 'urpf table' which is the fib, right?

This is VRF Mode uRPF. Where you configure the uRPF to check a separate
VRF(FIB). This decouples the policy table for the active forwarding
table - providing more flexibility - at the cost of memory. You can set
it to one of two mode - white list (if exist pass) or black list (if
exist drop). The white list is what SPs have been interested in since
you can fill the VRF with the prefixes from a peering partner/customer -
then insure all source addressing coming from that customer matches the
BGP prefixes being sent.