[c-nsp] Setting "weight 255" as default for customer BGP with uRPF strict

[Brian Feeny]

Your right, what I meant to say, was they advertised the same routes to 
both isp's, but just
prepended to one ISP more than the other, so that say, ISP A preffered 
the route thru ISP B, rather than thru its own direct link with the 
customer, since the customer may have prepended say 5 times to ISP A.  
In that case, weight will fix strict uRPF.

Brian

On Nov 21, 2004, at 9:22 PM, James wrote:

> On Sun, Nov 21, 2004 at 08:51:55PM -0600, Brian Feeny wrote:
>>
>> Pete,
>>
>> Ok, let me clarify, the customer is dual homed to a single ISP.
>> routers A and B both belong to the same ISP.
>>
>> You can have the same "problem" though when multi-homed to two
>> different ISP's, because then the customer will announce say a /24 and
>> its aggregate /20 to ISPA and a different /24 and its aggregate to
>> ISPB.  ISPA will see the more specific /24 from ISPB, and put an entry
>> in its FIB for its egress interface.  Yet its still possible the
>> customer sends traffic to ISPA on its ingress interface......which 
>> uRPF
>> would  drop unless something such as weight was being set on the
>> neighbor.
>
> Setting weight won't solve this problem. The more specific prefix has
> next hop of egress interface, which is not the customer connected
> interface. Routing management (RIB) and forwarding operations (FIB)
> are always performed on the most longest match prefix, therefore
> weight set on aggregate /20 won't enforce the /24 coming from another
> network..
>
> One of the ways that you can also work on with BGP customers, that 
> scales
> BETTER than manual access-lists, is to have them register all their bgp
> announcements in IRR (see www.radb.net, or if you want free version, 
> see
> www.altdb.net). Then generate automatic access-list out of registered 
> entries
> from customer ASN.
>
> But then again, if your router isn't good at filtering access-lists
> (*cough* GSR engine 0 LC, *cough*), this is challenging.
>
> HTH,
> -J
>
> -- 
> James Jun                                            TowardEX 
> Technologies, Inc.
> Technical Lead                      Boston IPv4/IPv6 Web Hosting, 
> Colocation and
> james at towardex.com            Network design/consulting & 
> configuration services
> cell: 1(978)-394-2867           web: http://www.towardex.com , noc: 
> www.twdx.net