Kinda goes without saying, honestly. I typically use all of the following: Inbound route-map to set community "no-export" on all received routes Outbound filter-list permitting only ^$ Outbound prefix-list permitting only the customer's prefixes
That's my belt-and-suspenders so even if someone goofs one of those facilities in the future they haven't compromised enough of those safeguards to leak routes out. I apply the filter-list and prefix-list independently of any outbound route-maps so that a tweak/goof on the route-map does not compromise the other safeguards. On Thu, Jan 2, 2014 at 3:16 PM, Tony Singh <[email protected]> wrote: > 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
