From: VirtRack.com Mailing Lists (ciscolists@gmail.com)
Date: Wed Dec 06 2006 - 12:28:46 ART
Number 1 sounds like a general requirement and best practice, not some
technical limitation. Basically, avoid a single point of failure on both
the client and provider side.
Number 2 appears to be a best practice to avoid asymmetric routing with your
ISP/Provider. If they are using RPF checking on the link to you, and they
see your route via EBGP from another AS, the RPF check on packets you are
trying to source will fail, and the incoming traffic to that provider will
be discarded. Trying to troubleshoot and fix asymmetric routing when
rotuers outside your control are involved can get ugly fast, so the
statement is advising that you avoid getting into this situation in the
first place. Also, the same rule applies for networks you are advertising
to your BGP peers - if you advertise network A to provider A and not to
provider B, packets sourced from network A should *NOT* be sent to provider
B at all, as RPF would fail in the same manner as above.
On 12/5/06, mathew Fer <mathew118@gmail.com> wrote:
>
> Hi GS,
>
> Can someone explains what is mean by the below 2 that was described in the
> below URL, with regards to U-RPF restrictions?
>
> Restrictions:
>
> There are some basic restrictions to applying Unicast RPF to multihomed
> clients:
>
> 1. Clients should not be multihomed to the same router because multihoming
> defeats the purpose of building a redundant service for the client.
>
> 2. Customers must ensure that the packets flowing up the link (out to the
> Internet) match the route advertised out the link. Otherwise, Unicast RPF
> filters those packets as malformed packets.
>
>
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fothersf/scfrpf.htm
>
>
> Thanks for the reply.
>
> Mathew
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Online rack rental and CCIE Forums at http://www.virtrack.com
This archive was generated by hypermail 2.1.4 : Tue Jan 02 2007 - 07:50:37 ART