Suppose, in the same 4-AS scenario, the following policies: AS1 receives AS4 prefixes via AS3 only. AS1 sends a full table to AS3, and a partial table to AS2. AS2 has a default route pointing to AS1. AS2 sends its own prefixes to AS4, plus the partial table it receives from AS1, to AS4. AS2 DOES NOT HAVE A ROUTE TO AS4 AS2 uses default to reach AS4, via AS3.
AS4 sends traffic to the partial table, via AS2, to AS1. This is legitimate traffic. I do not believe FP uRPF, enhanced FP uRPF, or even the further generalized FP uRPF would handle this. This is also far from rare, even if it doesn't reach the level of "common occurrence". (In particular, it is something that happens A LOT wherever satellite links are used, where symmetric traffic over the satellite path is actually the worst possible scenario.) Brian On Tue, Nov 15, 2016 at 1:13 AM, Sriram, Kotikalapudi (Fed) < [email protected]> wrote: > I understand the scenario. > That scenario is a problem for strict or feasible path uRPF, as well as > the enhanced FP uRPF. > If you add one further generalization to enhanced FP uRPF, > namely, allow any prefix learned on any customer peering > to be included in the RPF tables for *all* customer interfaces, > then the enhanced FP uRPF still works for this scenario. > > Sriram > > > ________________________________________ > From: Job Snijders <[email protected]> > Sent: Tuesday, November 15, 2016 3:26 AM > To: Sriram, Kotikalapudi (Fed) > Cc: Gert Doering; [email protected] > Subject: Re: [GROW] Fw: New Version Notification for > draft-sriram-opsec-urpf-improvements-00.txt > > On Tue, Nov 15, 2016 at 05:38:57AM +0000, Sriram, Kotikalapudi (Fed) wrote: > > > Does this technique make routers self-aware? What exactly is meant > > > with the word 'intelligence' in this context? > > > > 'Logic' may be a better choice than 'intelligence' in this context? > > For a brief description of the algorithm, please see: > > https://www.ietf.org/mail-archive/web/grow/current/msg03699.html > > Thank you for the clarification. > > I have a second scenario that might be a challenge for Enhanced > Feasible-Path uRPF. > > ASCII ART: > > +---+ > +-+AS1+--+ > | +---+ | > | | > | | > +-+-+ +-+-+ > |AS2| |AS3| > +---+-+ +--++ > | | > | | > +-+-+ | > |AS4+---+ > +---+ > > AS4 is a customer of AS2 and AS3. AS4 ingests a full routing table from > both AS2 and AS3 (and as such as two paths to AS4). > > A common traffic engineering practise visible in the Default-Free Zone > is to block unbounded propagation of one's prefixes. For instance, AS4 > might use a BGP Community provided by AS2 to block propagation of the > AS4 prefixes to AS1 via AS2. The equivalent would be that AS4 attaches > NO_EXPORT on the announcements to AS2, but not on the announcement to > AS3. > > AS1 will receive traffic sourced by the prefixes from AS4 via both > AS2_AS4 and AS3_AS4. > > Kind regards, > > Job > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
