Mark, BGP to RIB filtering (in any vendor implementation) is targeting RR which is not in the forwarding path, so there¹s no forwarding towards any destination filtered out from RIB. Using it selectively on a forwarding node is error prone and in case of incorrect configuration would result in blackholing.
Cheers, Jeff -----Original Message----- From: Mark Tinka <mark.ti...@seacom.mu> Organization: SEACOM Reply-To: <mark.ti...@seacom.mu> Date: Tuesday, July 8, 2014 at 1:56 PM To: "nanog@nanog.org" <nanog@nanog.org> Subject: Re: Best practice for BGP session/ full routes for customer >On Monday, July 07, 2014 08:33:12 PM Anurag Bhatia wrote: > >> In this scenario what is best practice for giving full >> table to downstream? > >In our case, we have three types of edge routers; Juniper >MX480 + Cisco ASR1006, and the Cisco ME3600X. > >For the MX480 and ASR1006 have no problems supporting a full >table. So customers peer natively. > >The ME3600X is a small switch, that supports only up to >24,000 IPv4 and 5,000 IPv6 FIB entries. However, Cisco have >a feature called BGP Selective Download: > > http://tinyurl.com/nodnmct > >Using BGP-SD, we can send a full BGP table from our route >reflectors to our ME3600X switches, without worrying about >them entering the FIB, i.e., they are held only in memory. >The beauty - you can advertise these routes to customers >natively, without clunky eBGP Multi-Hop sessions running >rampant. > >Of course, with BGP-SD, you still need a 0/0 + ::/0 route in >the FIB for traffic to flow from your customers upstream, >but that is fine as it's only two entries :-). > >If your system supports a BGP-SD-type implementation, I'd >recommend it, provided you have sufficient control plane >memory. > >Cheers, > >Mark.
