PPS. if we're multi-homing to dual ISP's then preventing transit services should be high on the list of things to consider I'd use something like an as path filter-list:
Router(config)#ip as-path access-list 1 permit ^$ Router(config-router)#neighbor 1.1.1.1 filter-list 1 out Router(config-router)#neighbor 2.2.2.2 filter-list 1 out The ^$ regular expression ensures that we will only advertise locally originated prefixes, apply this filter to both ISPs. -- BR Tony Sent from my iPad > On 2 Jan 2014, at 19:44, Bob McCouch <[email protected]> wrote: > > We're OT on an OT thread, but I'll throw in my 2 cents as the dissenting > opinion here. I think full tables with just two ISP connections is quite > reasonable and I do it regularly with my customers. Most prefer optimal > routing and having more bandwidth in the nominal state with the > understanding that they could have performance degradation in the event one > ISP link fails. Depends on the customer's situation, I suppose, but > generally for a monthly-fee resource like Internet access, my customers > hate the idea of getting no use out of the backup link and would prefer to > get value from that additional resource when it's operational. You just > have to monitor overall usage and make sure you don't get *way* out of > whack like averaging 90 Mb/s with 2 50 Mb/s feeds. > > Any half-decent modern router (1900 and up) will easily swallow and process > 2 full tables with minimal CPU impact and just a small RAM upgrade (which > are finally priced at a tolerable level). I have a pair of 1941's at a > customer's colo in NYC eating full tables from two ISPs and sure, CPU > spikes to 100% for a few seconds if a BGP peer actually bounces, but > processing the normal ongoing table churn barely impacts the CPU, if at > all. And with 1GB of RAM, there is no problem on the memory side either. > > Saying it is "too much work" for a router was accurate in the 2500/2600 > era. IMO it is not a concern now. > > Ryan J., do be aware that any time you have two BGP connected ISP links, > you may experience asymmetric routing where a request could come in your > Verizon link and the best path to return may still be out your other ISP > link. The only way to *guarantee* you don't have the potential for > symmetric routing would actually be something like setting LP on your > preferred outbound connection and using BGP conditional advertisement to > only even originate your prefix out the backup ISP if the primary ISP goes > away. You *may* be able to force your backup ISP to deprefer your > advertisement to them using community values to tamp down the local > preference on their side, but not all ISPs support that or respect it in > all cases. > > I'll get off my soapbox and shut up now :-) > > Bob McCouch > CCIE #38296 > HerdingPackets.net > > >> On Thu, Jan 2, 2014 at 2:14 PM, Ryanlk18 . <[email protected]> wrote: >> >> Hi Ryan, >> >> >> I get what you are trying to do, but from an efficiency standpoint, unless >> you have an application that has problems with microseconds of delay from >> routing inside the ISP cloud, or you have documented delays from traffic >> having to traverse the ISP, I would not really worry about that problem. >> Pulling down the entire Routing table from 2 different ISPs is a big task >> and not something that is typically done from a non-ISP. >> >> Your ISPs should be efficient enough to route packets to each other with a >> very very small amount of delay. Especially if you are connecting to 2 >> different ISPs that are in the same vacinity(city). If you were connecting >> to an ISP in the US and a different ISP in Europe or Asia, and you had a >> lot of people that were connecting from those different locations, then >> maybe I could see doing that, but the amount of processing that will have >> to take place on your router holding the entire internet routing table will >> only increase the amount of delay required to route the packet. >> >> Active/Standby is the best route in my opinion simply because when you >> start sending traffic over different links into different ISP clouds, it >> can make it difficult to troubleshoot if there is a problem, unless you are >> doing something like odd even or something that is easily recognizable. >> >> V/r, >> >> Ryan Krcelic >> >> >> >>> On Thu, Jan 2, 2014 at 2:00 PM, Ryan Jensen <[email protected]> wrote: >>> >>> Thanks for the feedback everyone. >>> To answer Ryan's question about WHY is that I was thinking about this: >>> With my dual connections now, they're Active/Standby, but I was thinking >> if >>> a member accessing one of our web apps has the same ISP as we do, we >> could >>> route more directly. I.E. Member accesses app and they're on Verizon, >>> request could come in Verizon connection and be routed back out that >>> connection even though our default route was pointing out the other ISP. >>> Unless I'm mistaken, wouldn't I need full tables to do this? >>> I have no qualms with Active/Standby, but would just prefer to route >>> optimally if possible. Does this make sense or am I off-base here? I'm >> not >>> too familiar with how other people would implement this. >>> These routers don't implement any other services other than routing with >>> very course edge-filtering and Netflow. They just sit outside the >> firewalls >>> and peer with ISP. There's no QoS, NAT, IPS, Multicast, etc ,etc. >>> >>> >>>> On Thu, Jan 2, 2014 at 1:39 PM, Tony Singh <[email protected]> >>> wrote: >>> >>>> >>>> I had an alarm on an ASR1002 in one of our sites in Australia can't >>> recall >>>> but it was a known bug, something like punt_linux on the NMS screen >> when >>> I >>>> contacted TAC just acknowledged it, free memory was sufficient enough >>> though >>>> >>>> The memory architecture on these beasts is complex and depends on >> models >>>> and the line cards installed as you have RP's per line card then the >>> memory >>>> is shared and protected in case one process fails which means the whole >>>> router does not die as what were used to in regular routers.. >>>> >>>> -- >>>> BR >>>> >>>> Tony >>>> >>>> Sent from my iPad >>>> >>>>> On 2 Jan 2014, at 18:03, marc abel <[email protected]> wrote: >>>>> >>>>> Slightly OT, but has anyone had any memory issues with ASR 1K's? I've >>> run >>>>> into memory issues on two different one taking two full BGP feeds. >> One >>>>> would think that these size routers should be able to handle 2 full >>> feeds >>>>> as that seems like exactly what they are designed for. >>>>> >>>>> >>>>> On Thu, Jan 2, 2014 at 11:56 AM, Edgar Mauricio Diaz Orellana < >>>>> [email protected]> wrote: >>>>> >>>>>> Greetings Ryan. >>>>>> >>>>>> there is a memory sizing table on the BGP Design and Implementation >>>> Book, >>>>>> As my mind recalls, as much memory as you can take on your router is >>>>>> better, but my worries are the CPU to handle all the BGP Table. >>>>>> >>>>>> did your ISP put limit on the prefixes lenght push to your peer ?, >> did >>>> you >>>>>> think put the prefix limit on your side ? >>>>>> >>>>>> a good reading on that is "ISP Essentials" and the "BGP Design and >>>>>> Implementation" both from CiscoPress >>>>>> >>>>>> Best Regards. >>>>>> >>>>>> >>>>>>> On Thu, Jan 2, 2014 at 1:12 PM, marc abel <[email protected]> >>> wrote: >>>>>>> >>>>>>> You do not need BGP soft-reconfiguration as of IOS 12.0 so that >>> should >>>>>>> save >>>>>>> you some memory. >> http://www.cisco.com/en/US/products/ps6599/products_data_sheet09186a0080087b3a.html >>>>>>> >>>>>>> Previously, in order to perform a soft reset for inbound routing >>> table >>>>>>> updates, the neighbor soft-reconfiguration command directed the >> Cisco >>>> IOS >>>>>>> software in the local BGP router to store all received (inbound) >>>> routing >>>>>>> policy updates without modification. This method is >> memory-intensive >>>> and >>>>>>> not recommended unless absolutely necessary. (Outbound updates have >>>> never >>>>>>> required the extra memory and are not affected by this feature.) >>>>>>> >>>>>>> With this software release, the BGP Soft Reset Enhancement feature >>>>>>> provides >>>>>>> automatic support for dynamic soft reset of inbound BGP routing >> table >>>>>>> updates that is not dependent upon stored routing table update >>>>>>> information. >>>>>>> The new method requires no preconfiguration (as with the neighbor >>>>>>> soft-reconfiguration command) and requires much less memory than >> the >>>>>>> previous soft reset method for inbound routing table updates. >>>>>>> >>>>>>> >>>>>>>> On Thu, Jan 2, 2014 at 9:51 AM, Ryan Jensen <[email protected]> >>> wrote: >>>>>>>> >>>>>>>> Morning! >>>>>>>> I have an OT question... >>>>>>>> I have two 40mbps internet connections from the same ISP today, >> each >>>> one >>>>>>>> runs into a 2921 router. I receive a default route via eBGP with >> ISP >>>> and >>>>>>>> the two routers peer via iBGP with each other. I'm going to be >>>> dropping >>>>>>> one >>>>>>>> internet connection soon and picking up a second ISP, same >>> bandwidth. >>>>>>> We're >>>>>>>> just doing this to diversify. >>>>>>>> Question is: Would the 2921s have enough resources to accept full >>>>>>> internet >>>>>>>> tables from each ISP? >>>>>>>> The way I look at it, each router would store the BGP table from >> the >>>>>>> ISP, >>>>>>>> and also store the table from its iBGP peer... with >>>> soft-reconfiguration >>>>>>>> enabled, It then stores a second copy of each peer's updates. >>>> Basically >>>>>>>> requiring the router to store the entire internet BGP table 4 >>> times... >>>>>>> Am I >>>>>>>> looking at this correctly? >>>>>>>> >>>>>>>> I know my current ISP has an option for them to advertise their >>>>>>> originated >>>>>>>> routes (core routes) and a default, so that would significantly >>>> decrease >>>>>>>> the update size from that peer, but I don't know if my incoming >> ISP >>>> has >>>>>>>> that option. >>>>>>>> >>>>>>>> Routers are default hardware spec, 1g RAM, 256mb Flash >>>>>>>> IOS 15.2(4)M3 >>>>>>>> >>>>>>>> Thoughts?? >>>>>>>> _______________________________________________ >>>>>>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security >>> Videos >>>> :: >>>>>>>> >>>>>>>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Marc Abel >>>>>>> CCIE #35470 >>>>>>> (Routing and Switching) >>>>>>> _______________________________________________ >>>>>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security >> Videos >>>> :: >>>>>>> >>>>>>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Edgar Díaz Orellana >>>>>> CCENT/CCNA/CCDA/CCNA Security, CCNP, CCNP Security en progreso. >>>>>> Kaspersky Administrator / Technical Specialist >>>>>> Microsoft Certified Professional. >>>>>> Celular : 09-91283087 / 09-94118996 >>>>>> skype: eorellan1969 >>>>> >>>>> >>>>> -- >>>>> Marc Abel >>>>> CCIE #35470 >>>>> (Routing and Switching) >>>>> _______________________________________________ >>>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos >>> :: >>>>> >>>>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>>> _______________________________________________ >>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos >> :: >>>> >>>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>> _______________________________________________ >>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >>> >>> iPexpert on YouTube: www.youtube.com/ipexpertinc >> _______________________________________________ >> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >> >> iPexpert on YouTube: www.youtube.com/ipexpertinc > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
