RE: Default route with object tracking
To be absolutely safe, choose 4-5 of the ideas, track all of them and use a composite track object to combine them :) You can find a lot more details (including the oscillating routing problem) here: http://www.nil.com/ipcorner/SmallSiteMultiHoming/ http://wiki.nil.com/Small_site_multihoming Good luck! Ivan Pepelnjak blog.ioshints.info / www.ioshints.info > -Original Message- > From: Andrey Gordon [mailto:andrey.gor...@gmail.com] > Sent: Monday, February 01, 2010 4:14 PM > To: Nanog > Subject: Default route with object tracking > > Hi list. > > I'd like to setup my default routes to the Interwebz to be conditional on > reachability of something on the Interwebz. I got two different ISPs (no > BGP). I'm trying to figure out what would be a reliable object to track? > Meaning, it's probably not reasonable to track my ISPs default gateway, > since it does not protect me from someone on the ISP side screwing up. I'm > thinking of tracking something like google.com, but am not sure if after I > resolve google.com for the first time, it will be simply tracking an > arbitrary server (or some load balancer). > > I wanted to see what experienced folks think is a reliable tracking > target. > Any comments are much appreciated. > > thank you, > > > - > Andrey Gordon [andrey.gor...@gmail.com]
RE: BGP testbed tools
This is how you can do it with Quagga: http://wiki.nil.com/Use_Quagga_to_generate_BGP_routes You could write a Perl (or whatever your favorite scripting language is) script to get Quagga/IOS configuration from live BGP data, but it would be non-trivial and the resulting configuration would be enormous. I know there was a similar discussion months ago on the NANOG mailing list; browse the archives. Ivan Pepelnjak blog.ioshints.info / www.ioshints.info > -Original Message- > From: Ben Jencks [mailto:b...@bjencks.net] > Sent: Tuesday, January 12, 2010 9:28 PM > To: nanog@nanog.org > Subject: BGP testbed tools > > This is obviously a rookie question, but I haven't found anything by > searching. I'm looking to set up a small testbed to simulate our > internal network topology, and I want to have a realistic BGP table > from the fake "upstream" routers. Ideally what I'd like to do is dump > the BGP table from our production routers, strip the immediate > neighbor AS, and load the table into Quagga or OpenBGPD to advertise. > I'm running into two problems: how do you dump BGP tables in a > machine-parseable format from IOS, and how do you make the route > server advertise the routes as they were in the original table, > including the full AS-path, communities, etc? If Quagga/OpenBGPD > aren't the right tools, I'm happy to use something else. > > This seems like it would be a pretty standard thing to do, but none of > the tools I've found seem aimed at this sort of testbed. > > Thanks! > > -Ben Jencks >
RE: Consumer-grade dual-homed connectivity options?
> At home, I currently run two DSL lines. Right now, we just have two > separate LANs, one connected to each line, with my wife's devices attached > to one, and my devices attached to the other. For a while now, I've been > thinking about setting up a load-balancing routing solution to give both > of us access to both lines. If you decide to use an IOS-based router, you'll find most what you need here: http://wiki.nil.com/Small_site_multihoming Ivan Pepelnjak blog.ioshints.info / www.ioshints.info
RE: Routing to multiple uplinks
Am I right in assuming that you're establishing application-layer sessions to two hosts with two different IP addresses (outside of your control) which provide (close to) identical services? If so, there's not much you can do outside of the application itself (at least if you want a semi-robust solution). You could try (reverse) load balancer, but even then the application session would have to be disconnected before being switched over to the other host. > As stated before Path A and Path B are two distinct paths they do however > provide identical services but application state is not preserved. A new > session and state must be established if a user decides to switch between > paths. Ivan Pepelnjak blog.ioshints.info / www.ioshints.info
RE: fight club :) richard bennett vs various nanogers, on paid peering
> Oh wait, those billions got pocketed - if the massive fiber > buildout had happened, we'd have so much bandwidth that > neutrality wouldn't be an issue... Maybe this is how the fiber got used :)) http://en.wikipedia.org/wiki/RFoG
RE: MPLS Services
This might give you some ideas (also solves the overlapping customer address problem): http://www.nil.com/ipcorner/FlexExtraImplement/ Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -Original Message- > From: Kenny Sallee [mailto:kenny.sal...@gmail.com] > Sent: Friday, August 28, 2009 6:28 PM > To: nanog@nanog.org > Subject: MPLS Services > > Questions for the community: from a Application Service > Provider perspective - how / can one provide application > access to a group of Enterprises where the ASP provider > provides ASP like applications to all Enterprise customers > who have multiple locations and who may or may not have > overlapping addresses? Each Enterprise is it's own business > and we cannot allow connectivity between each other We've > struggled internally with this. MPLS and using BGP > communities seems to be the solution. But I am trying to > understand / think through the configuration of it from a CE > and PE side perspective. Lab configs to follow but here's > what I'm thinking: > > - From the CE side we could ask for 2 frame PVC's - each in > it's own VRF on the PE side. Call 1 VRF private and 2nd VRF > public. In the Private VRF advertise all CE routes between > customer A for example. Each CE customer would have their > own VRF on the MPLS providers network. > > - From the CE, In Public VRF advertise a network range we > provide the clients and NAT traffic destined for the shared > environment to the public range > > - On each CE router only permit route updates on the Public > VRF for BGP communities that belong to that customer and our > shared segments. Could also do this with just route > filtering by ACL/prefix lists. On the Private VRF no need to > filter incoming but filter outgoing to contain routing domain > consistency (only send updates for CE networks) > > - In the Public VRF from ASP side - advertise all shared > services routes. > Accept all updates on Public VRF. No access to Private VRF's here. > > Thoughts? > Thanks, > Kenny > >
RE: OSPF vs IS-IS vs PrivateAS eBGP
> Configure eBGP from your edge to the client edge using > private-AS. Since I already have copy/paste templates (thanks > to RANCID), I make it a habit to ensure filters are at both > ends. Goes without saying that > BCP-38 is followed, and strict is deployed everywhere possible. > > peer-group and regexes are handy. If you're starting from scratch, use peer templates, they are slightly more versatile than the peer groups and allow (limited) inheritance. Ivan http://www.ioshints.info/about http://blog.ioshints.info/
RE: OSPF vs IS-IS vs PrivateAS eBGP
> The only issue with using ebgp is getting enough of my > staff that actually understand bgp to the point where they > can deploy it themselves without having to get me involved on > every install. I think I can make this pretty cookie-cutter > config to start off and then work from there. For those of them that prefer eye candy to real study :), I've made a few video clips when the weather was really bad last winter and I couldn't go rock climbing ... http://wiki.nil.com/BGP (the "Videos" section") They are targeted at using BGP in MPLS VPN networks, but are useful in other similar scenarios as well. > So my deployment strategy will be ebgp with > multihmed customers. I just had to poke the fire so I had > some ammo for upper management when they ask why I decide to go ebgp. Ah, that was the reason ... You could have told us in advance and my previous reply would have been even more explicit :)) Good luck! Ivan http://www.ioshints.info/about http://blog.ioshints.info/
RE: OSPF vs IS-IS vs PrivateAS eBGP
Do not EVER run an SPF routing protocol with your customer. They can insert anything they want into it (due to configuration mistake, malicious intent or third-party hijacking) and your whole network (or at least the other customers) will be affected. Just to give you a few examples: * They could hijack the host route to your DNS server and spoof every other customer of yours that uses your DNS * They could hijack the host route to your POP3 server and collect the usernames and passwords of your residential users * Company A could hijack the host route to the web server of company B. * They could insert a better default route than you do and at least some of your routers will listen to them. * If they ever make a total mess and start flapping their LSAs, your whole network will be affected and all your routers will burn CPU running SPF algorithm. If you absolutely insist on not using BGP (but then BGP is the only currently available routing protocol designed to handle routing in scenarios where the two parties don't necessarily trust each other), use RIP. It's safer than OSPF, at least you can filter the incoming updates. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -Original Message- > From: Clue Store [mailto:cluest...@gmail.com] > Sent: Wednesday, August 19, 2009 5:13 PM > To: nanog@nanog.org > Subject: OSPF vs IS-IS vs PrivateAS eBGP > > Hi All, > > I know this has been discussed probably many times on this > list, but I was looking for some specifics about what others > are doing in the following situations. > > I would like to run an IGP (currently OSPF) to our customers > that are multi-homed in a non-mpls environment. They are > multi-homed with small prefixes that are swipped from my ARIN > allocations. OSPF has been flaky at best under certain > conditions and I am thinking of making the move to IS-IS. > I have also seen others going to private AS and running eBGP. > This seems a bit much, but if it works, i'd make the move to > it as I like bgp the most (all of the BGP knobs give me the > warm and fuzzies :). > > I'd also like to see what folks are using in a MPLS network?? > OSPFv3 or IS-IS or right to MP-BGP and redist static from the > CE to PE??? > > On and off list are welcome. I'll make a summary after I > gather the info. > > Thanks, > Clue > >
RE: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ?
> Ivan- >Thanks for posting this how-to on excessive as prepends. I > have a couple of questions that some of the less BGP savvy > out their may find helpfull > > 1. In my enviornment, we are not doing full routes. We have > partial routes from AS209 and then fail to AS7263. Is their > any advantage for someone like me to do this, as we are not > providing any IP transit so we are not passing the route > table to anyone else? You could do it to protect your BGP table, but as you're not a transit AS, it does not make much sense. > 2. When I run the "sh ip bgp quote-regexp > "_([0-9]+)_\1_\1_\1_\1_ \1_" | begin Network" I am seeing > many many ASes that would be filtered by this access-list. Obviously a lot of people are prepend-happy. > What happens to those networks, are they unreachable from my > AS, or do I just route those networks to my upstream provider > and let them deal with it? If I understood correctly, you're using a default route toward AS7263, which means that anything that is not in your BGP table (and consequently your IP routing table) will be sent out of your AS via the default route. If you're getting the paths you're filtering from AS209 that means that more traffic will go to AS7263. > 3. This last question is a little OT, but relates to your access list >In the event of some kind if DOS attack coming from one of > a few AS numbers (in this case we will use 14793), what is > the feesability of using > ip as-path access-list 100 deny _([0-9]+)_\1_\1_\1_\1_ > ip as-path access-list 100 deny 14793 > ip as-path access-list 100 permit .* > > Would this have any affect at all, or would my pipe from my > upstream still be congested with garbage traffic ? No. You cannot influence the inbound traffic apart from not advertising some of your prefixes to some of your neighbors or giving them hints with BGP communities or AS-path prepending. Whatever you do with BGP on your routers influences only the paths the outbound traffic is taking. What you'd actually need is remote-triggered black hole. Search the Nanog archives for RTBH, you'll find a number of links in a message from Frank Bulk sent a few days ago. Hope this helps Ivan http://www.ioshints.info/about http://blog.ioshints.info/
RE: Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ?
> Anybody have a handy route-map that will deny anything with a > as-path longer than say 15-20? ;-) http://wiki.nil.com/Filter_excessively_prepended_BGP_paths Ivan http://www.ioshints.info/about http://blog.ioshints.info/
RE: Data Center QoS equipment breaking http 1.1?
Facts first: name-based virtual hosts depend on the HOST header in the
HTTP/1.1 request to select the virtual web server.
> I poured over my configs (I've done this config countless
> times), and saw this in the apache docs:
>
> http://httpd.apache.org/docs/2.2/vhosts/name-based.html
>
> " Some operating systems and network equipment implement
> bandwidth management techniques that cannot differentiate
> between hosts unless they are on separate IP addresses."
Thanslated into networking engineerese: since the QoS equipment (including
routers unless you use HTTB NBAR) cannot peer into contents of the TCP
session, it cannot find the HOST header and thus cannot decide which virtual
host the traffic belongs to, making it impossible to enforce
per-virtual-host QoS policies.
> So, I installed lynx on the server, and sure enough, it
> worked perfectly fine there, just not from anywhere outside
> eSecuredata's network that I could see.
>
> Can anyone shed any light on this particular practice, of
> this company in particular?
What you're experiencing usually means only one thing: they're using a box
that messes with HTTP headers. It could be a misconfigured DPI box, a
transparent (broken) HTTP proxy or a custom-developed "wizardry".
Configure the Apache logs (http://httpd.apache.org/docs/2.2/logs.html) to
log the virtual host name in the HTTP request (the %{host}i directive) or
use Wireshark on your client and the server to inspect it. If you find out
they're messing with the HOST header (as suspected) switch the provider
immediately.
Ivan
http://www.ioshints.info/about
http://blog.ioshints.info/
RE: BGP Growth projections
Let me be the devil's advocate: why would you need full Internet routing? Taking reasonably sized neighborhoods of your upstreams (AS paths up to X AS numbers) plus a default to your best upstream might do the trick. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -Original Message- > From: Mark Radabaugh [mailto:m...@amplex.net] > Sent: Friday, July 10, 2009 6:42 PM > To: nanog list > Subject: BGP Growth projections > > I'm looking for new core routers for a small ISP and having a > hard time > finding something appropriate and reasonably priced. We don't have > huge traffic levels (<1Gb) and are mostly running Ethernet > interfaces to > upstreams rather than legacy interfaces (when did OC3 become > legacy?). > > Lot's of choices for routers that can handle the existing BGP > tables - but not so much in small platforms (1-10Gb traffic) > if you assume that > IPv6 is going to explode the routing table in the next 5 > years.The > manufacturers still seem to think low traffic routers don't > need much memory or CPU. > > What projections are you using regarding the default free > zone over the next 5 years when picking new hardware? > > -- > > Mark Radabaugh > Amplex > 419.837.5015 x21 > m...@amplex.net > > > >
RE: Point to Point Ethernet
We're halfway there (OK, a bit less, they've messed up OSPF) with the unnumbered VLAN interfaces. http://wiki.nil.com/Unnumbered_Ethernet_VLAN_interfaces What's missing is the removal of MAC layer header, but that would require modifications to the NIC chipsets (= expensive). Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -Original Message- > From: Andre Oppermann [mailto:nanog-l...@nrg4u.com] > Sent: Wednesday, July 08, 2009 12:01 PM > To: nanog@nanog.org > Subject: Point to Point Ethernet > > A few time already I've wished for a fully standardized and > vendor interoperable way of doing a true point to point ethernet link. > > It would work just like an old leased line or synchronous > serial interface and completely do away with ARP, MAC > addresses and all that stuff. Obviously no switches in > between would be allowed. > Each side would run in "promiscuous mode" where every > ethernet frame is received and passed up to the network stack > (just like on a serial link). Since MAC addresses are > useless they can be scrapped and only the ethertype field > remains. This increases the effective MTU by 12 bytes. > > The framing overhead goes away and the packet can directly be > directly placed on the wire without taking a detour through > L3->L2 lookup and encapsulation step. > > More importantly one can specify the just the outgoing > interface again instead of the next hop: > > ip route 10.0.0.0 255.0.0.0 g0/1 > > Do you think this is useful? Maybe vendors will hear me/us. > > -- > Andre > > >
RE: Multi site BGP Routing design
> I am thinking the multiple ASN route is the cleanest but the > idea of letting a default gateway (via static route maybe) > out the local upstream connection to reach the other site > when the backnet link is down sounds like it would work with > minimal to no headaches but it just some how seems like a > duct tape job. Does this sort of technique have any > significant flaws or concerns associated with it? It's a static route, so you're never sure the remote end (upstream router) is truly alive. In this respect, it would be much better to receive default route over BGP (if the upstream carrier is willing to implement it). On the other hand, it's a last-resort mechanism, so you'd only use it if everything else fails (and you don't care how reliable it is). Just make sure it's well documented and understood ... and think about what will happen when you add a third carrier to one of the sites. Last but not least, you could use reliable static routing (static route tied to ping tests). http://blog.ioshints.info/2007/02/reliable-static-routing.html http://blog.ioshints.info/search?q=static+routing Just my $0.002 :) Ivan http://www.ioshints.info/about http://blog.ioshints.info/
RE: Multi site BGP Routing design
> To rephrase the OP's question, would it be BCP to acquire a > second ASN, and without further de-aggregating, continue > advertising each site's IP space to the DFZ, but from > dissimilar ASs as opposed to the same one? This would definitely be the best approach. You're not introducing new IP prefixes and you're not extending AS paths, so the net effect on the global BGP routing is zero (OK, you might have to use the 4 byte AS number :). Just make sure that both ISPs you connect to allow you to advertise "transit" prefixes. If site A public link goes down, but the private link is up, site B will advertise its own address space plus site A's address space with an extra AS number in the AS path (and the upstream ISP might filter that). Ivan http://www.ioshints.info/about http://blog.ioshints.info/
RE: Multi-homed clients and BGP timers
> If you want to converge a little fast than BGP holdtimes here > and the fiber link is directly between the routers, you might > look at something akin to Cisco's "bgp > fast-external-fallover", which immediately resets the session > if the link layer is reset or lost. For fast external fallover, your physical interface has to go down. Inside your network you could use BGP fast fallover (which drops BGP session after the IGP route to the neighbor is lost), details are here: http://www.nil.com/ipcorner/DesigningBGPNetworks/ Fast fallover with EBGP multihop is described here: http://wiki.nil.com/EBGP_load_balancing_with_EBGP_session_between_loopback_i nterfaces Ivan http://www.ioshints.info/about http://blog.ioshints.info/
RE: Multi-homed clients and BGP timers
For BFD to work, you need: * ISR + 12.4(15)T (or later) * 7200 with 12.4T or 12.2SRx * 7600/6500/GSR + 12.2SRB (or later) * ASR A complete list is at the bottom of this document: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fs_bfd.html You'll find some more BFD details and usage guidelines here: http://www.nil.com/ipcorner/bfd/ Best regards Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > > Correct me if I'm wrong, but wasn't this exactly the type > of situation > > that BFD was designed to detect and help with? > > I don't know, but I'm printing it[1] anyway to take home and > read. It's been mentioned a few times, and clearly worth > learning about. > > Thanks, > > Steve > > [1] > http://bgp.potaroo.net/ietf/all-ids/draft-ietf-bfd-v4v6-1hop-09.txt >
Two interfaces one subnet (summary)
> > Anyone else want to unconfused Ben? I obviously cannot. The numerous misconceptions propagated in this thread prompted me to go through the relevant sections of RFC 1122 and write a short article on multihomed IP host issues. http://wiki.nil.com/Multihomed_IP_hosts Your contributions, either as an e-mail reply or direct wiki edit are most welcome. After the kinks have been ironed out, I'll add figures illustrating the points in the text. ** I would prefer wiki edits although I have to admit the registration is a bit of a pain and the anonymous edits are not allowed. Thanks in advance to anyone who decides to contribute :) Ivan http://www.ioshints.info/about http://blog.ioshints.info/
RE: ASPATH Loop
Multiple discontiguous copies of an AS number in the AS-path can also be caused by the "original" Cisco IOS "local-as" feature, but in that case the AS number in the middle would be fixed. http://bit.ly/7TnCi And there's always the AS-path prepending. Cisco IOS allows you to insert anything in the AS path. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -Original Message- > From: yangyang. wang [mailto:wyys...@gmail.com] > Sent: Sunday, May 10, 2009 12:52 PM > To: nanog@nanog.org > Subject: ASPATH Loop > > Hi， NANOG： > >When I was analyzing the BGP RIB data from RouteViews, > I found that there were aspath loop in many bgp rib entries. > For example, in the file rib.wide.20090301.0319, the peer > 202.249.2.169 in AS2497 observed the following aspaths: > > 3130 29283 3130 2914 2497 > 3130 7337 3130 2914 2497
RE: IXP
> > I like would to know what are best practices for an > internet exchange. > > I have some concerns about the following; Can the IXP > members use RFC > > 1918 ip addresses for their peering? > > No. Those IP addresses will at least appear on traceroutes; > also, it might not be such a good idea to use the same RFC1918 space > (accidentally) on different IXPs. This will get your skin > crawling (thing IGP, or at least config databases)... IXPs > can usually get a v4 and a v6 block for their peering grid easily. Anyone with a decently configured firewall would block IP packets with source address from RFC1918 coming from the Internet. Your IXP would appear as a black hole in traceroute printout because the ICMP replies sent from the IXP IP addresses would be blocked. A while ago I've described a few more caveats in an article (see http://blog.ioshints.info/2008/08/private-ip-addresses-in-public-networks.ht ml). Ivan http://www.ioshints.info/about http://blog.ioshints.info/
RE: BGP and ios upgrade question
> According to Cisco feature navigator, ios version 12.4(24)T > (c1841-ipbasek9-mz.124-24.T.bin) can run in the 1841 and > supports BGP (note that feature set is IPBASE): > > 1) It is common that a version with an IPBASE feature set > supports BGP (some docs says that bgp support is included in > "SP" services feature set)? Moving BGP into the IP Base feature set is a recent change. http://6200networks.com/2008/06/02/bgp-support-on-isr/ > 2) Will ios version 12.4(24)T run OK in the 1841? > I think the response will be YES because Cisco feature > navigator says that it is supported and the router has the > DRAM and FLASH needed by 14.4(24)T. Yes. Although I wouldn't necessarily use 12.4(24)T, the latest maintenance build of 12.4(15)T should be more stable. http://6200networks.com/2008/09/23/extended-support-for-cisco-ios-software%C 2%AE-release-12415t/ > 3) Must the customer pay in order to download 12.4(24)T or he > can download if he has a valid Cisco maintenance contract for > that router? It's my understanding that you can download any software of the feature set you're entitled to use if you have SmartNet. Hope it helps Ivan http://www.ioshints.info/about http://blog.ioshints.info/
RE: ISIS route summarization
The short answer is "NO". L2 IS-IS is a single SPF domain and all routers are supposed to have identical view of the network. If you want IS-IS-provided aggregation, you need to use L1 and L2. There are only two protocols that allow unlimited levels of aggregation: BGP and EIGRP :) Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -Original Message- > From: Jack Bates [mailto:jba...@brightok.net] > Sent: Monday, February 23, 2009 10:26 PM > To: nanog@nanog.org > Subject: ISIS route summarization > > In a level2 only ISIS network (not using multiple areas due > to MPLS limitations), is there a better method for handling > aggregate routes than creating an aggregate and > redistributing it into ISIS for each router? Primarily > Cisco/Juniper based. Cisco I believe has an aggregate option > in ISIS (similar to OSPF) and Juniper has a separate > aggregate function which can be distributed into ISIS. > Neither can do summarization per say unless they cross > between levels; unless I'm mistaken. > > Offlist input is fine. Just trying to double check my brain > while setting up IPv6 on the access edges. > > Link state does have it's limitations. ;) > > > -Jack > > >
RE: FW: Ctrl+Shift+6 then X
Just configure a different escape character with "terminal escape x". For example, "term esc 3" will make Ctrl/C the escape character (and Ctrl/C+X the escape sequence). Ctrl/^ is "somewhat" hard to get on "some" terminal emulators :) Ivan > > If anyone can tell me how to resolve this issue there's a strong > possibility > > of a fedex'd beer. > > > > Using Putty or any other ssh/telnet terminal I find that > Ctrl+Shift+6 > > then > X > > (on a cisco) works only sometimes after beating your > keyboard multiple > times > > with a hammer, has anyone else come across or had a solution to this > problem
Followup: anyone else seeing very long AS paths?
I know this is getting boring, but I don't want to see information lying around hinting that the ISPs around the world were to blame for the Monday incident due to their sloppy software upgrade policies. That's not the case; a lot of very recent IOS releases were affected. There was lots of conflicting information flowing around. Rodney did an excellent job with the bug description, but I was still wondering what exactly was going on, so I've tested all potential combinations of inbound/outbound IBGP/EBGP prepending/no-prepending cases to identify exactly what can happen; you should be able to figure out which one affected your network: http://blog.ioshints.info/2009/02/oversized-as-paths-cisco-ios-bug.html And it should be reiterated that anyone that has already configured bgp maxas-limit has avoided this problem. Ivan > -Original Message- > From: Rodney Dunn [mailto:rod...@cisco.com] > Sent: Thursday, February 19, 2009 9:15 PM > To: Rodney Dunn > Cc: German Martinez; Ivan Pepelnjak; nanog@nanog.org > Subject: Re: anyone else seeing very long AS paths? > > We are working on a document for Cisco.com but in the interim > here is the bug that will fix the issue of a Cisco IOS device > sending an incorrectly formatted BGP update when as a result > of prepending it goes over 255 AS hops. > > Note: The Title and Release-note on bug toolkit may be a bit > different as I just updated it to be more accurate. > > Of all the scenarios I've looked at (thanks to those that responded > offline) there wasn't a condition found where this could > happen without AS path prepending being used. > > Please respond offline or let's move the discussion over to > cisco-nsp at this point. > > CSCsx73770 > Invalid BGP formatted update causes peer reset with AS prepending > > Symptom: > > A Cisco IOS device that receives a BGP update message and as > a result of AS prepending needs to send an update downstream > that would have over 255 AS hops will send an invalid > formatted update. This update when received by a downstream > BGP speaker triggers a NOTIFICATION back to the sender which > results in the BGP session being reset. > > Conditions: > > This problem is seen when a Cisco IOS device receives a BGP > update and due to a combination of either inbound, outbound, > or both AS prepending it needs to send an update downstream > that has more than 255 AS hops. > > Workaround: > > The workaround is to implement bgp maxas-limit X > on the device that after prepending would need to > send an update with over 255 AS hops. Since IOS limits the > inbound prepending value to 10 the most that could be added > iss 11 AS hops (10 on ingress, 10 on egress, and 1 for normal > eBGP AS hop addition). Therefore, a conservative value to > configure would be 200 to prevent this condition. > > > > Full support of Section 5.1.2 of RFC4271 is being tracked under > CSCsx75937 > Add BGP support of AS paths longer than 255 per Section 5.1.2 > of RFC4271 > > Thanks to those that worked offline with us to verify the > field results reported. > > Rodney > > > > > On Tue, Feb 17, 2009 at 05:27:01PM -0500, Rodney Dunn wrote: > > If you want to take this offline send it unicast or we > could move it > > to cisco-nsp. > > > > What scenarios are you seeing that appear broken other than when a > > notification is sent when a > 255 hop update is received? > > That's the one I'm working on right now. > > > > Rodney > > > > On Tue, Feb 17, 2009 at 05:31:49PM -0500, German Martinez wrote: > > > On Tue Feb 17, 2009, Rodney Dunn wrote: > > > > > > Hello Rodney, > > > It will be great if you can share with us your findings. > It seems > > > like we are hitting different bugs in different platforms. > > > > > > Thanks > > > German > > > > > > > Ivan, > > > > > > > > It is confusing but from what I have tested you have it correct. > > > > > > > > The confusing part comes from multiple issues. > > > > > > > > a) The documentation about the default maxas limit > being 75 appears to be > > > >incorrect. I'll get that fixed. > > > > > > > > b) Prior to CSCee30718 there was a hard limit of 255. > After that fix > > > >AS sets of more than 255 should work. > > > > > > > > c) CSCeh13489 implemented the maxas command to mark it > as invalid and > > > >not send. > > > > > >
RE: Lots of prepends - AS20912 case
>From the end-user perspective, it makes sense to make the "prepend" parameter an integer. The only thing an end-user really needs is routing policy (primary/backup selection) and sometimes AS path prepending is the only solution. Allowing them to insert third-party AS numbers into the AS path increases their confusion (assuming they were never exposed to Cisco IOS). Obviously, the number of prepends has to be limited to something sensible (10 seems a good number, and it looks like Mikrotik has implemented that restriction). The "set as-path prepend last-as" is a completely different story; it's used to do proxy prepending for your customers. Ivan Pepelnjak http://blog.ioshints.info > -Original Message- > From: Mikael Abrahamsson [mailto:swm...@swm.pp.se] > Sent: Friday, February 20, 2009 3:06 PM > To: nanog@nanog.org > Subject: Re: Lots of prepends - AS20912 case > > On Fri, 20 Feb 2009, Dorn Hetzel wrote: > > > Replacing what is conventially thought to be a string with > an integer > > multiplier seems a massive violation of the principle of > least astonishment. > > On a Cisco running 12.0S: > > route-map test1 > set as-path prepend last-as ? ><1-10> number of last-AS prepends > > Cisco seems to be doing more sensible limits, but I do agree > that the feature makes sense. > > There are two ways of handling when someone puts in a very > high number to number of prepends: > > 1. Say "out of limit" and disallow it in the config checker. > 2. Actually prepend the number of times specified. > > The option done here: > > 3. Prepend number of times entered modulo 256, is just broken. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se
RE: anyone else seeing very long AS paths?
> We were dropping ALL prefixes and the eBGP session was still > resetting. Upstream or downstream? > 1) "bgp maxas-limit 75" had no effect mitigating this problem > on the IOS we were using. That is: it was previously verified > to be working just fine to drop paths longer than 75, but > once we started receiving paths > > 255 then BGP started resetting. I was able to receive BGP paths longer than 255 on IOS release 12.2SRC. The paths were generated by Quagga BGP daemon. 12.2SRC causes the downstream session to break when the installed AS-path length is close to 255 and you use downstream AS-path prepending. In your case, I'm assuming you were hit with an older bug (probably at the 128 AS-path length boundary). It would be very hard to generate just the right AS-path length to unintentionally break your upstream EBGP session (as I said before, it's a nice targeted attack if you know your downstream topology). If your IOS is vulnerable to the older bugs that break inbound processing of AS paths longer than 128, there's nothing you can do on your end. The internal BGP checks reject the inbound update before the inbound filters (or bgp maxas-limit) can touch it and reset the upstream BGP session. Hope this helps Ivan Disclaimer: as I don't have internal access to Cisco, all of the above is a result of lab tests.
RE: anyone else seeing very long AS paths?
As far as I understand the issues :) There are two limits: the first one @ 128 AS numbers (where BGP switches to the 'extended length' of BGP attribute), the other one @ 256 AS numbers (where BGP has to use two AS_SEQUENCE segments). Old IOS releases break on the first boundary when processing INBOUND update. bgp maxas-limit cannot save you, as the router drops UPSTREAM BGP session before the update is fully processed. New IOS releases accept all INBOUND updates. Prefixes with AS-path length above 254 are never valid (the long printout contains maxas-limit status). bgp maxas-limit works on inbound updates and thus drops whatever you feel is oversized. New IOS release fail when sending OUTBOUND updates. If you've configured bgp maxas-limit, you're safe. If not, your DOWNSTREAM BGP session will be dropped by your neighbor receiving invalid BGP update. If your customers are using old IOS, there was nothing they could do to prevent the BGP session reset (apart from upgrading, obviously :). Who was the actual culprit depends on the AS-path length ... See above. Does this make sense? I know it's complex :) Ivan > -Original Message- > From: Jack Bates [mailto:jba...@brightok.net] > Sent: Tuesday, February 17, 2009 8:31 PM > To: Ivan Pepelnjak > Cc: nanog@nanog.org > Subject: Re: anyone else seeing very long AS paths? > > Ivan Pepelnjak wrote: > > Classic IOS (I did not test XE, XR or NX) can handle > inbound updates > > with AS path lengths above 255, but fails miserably when it has to > > send an oversized update (producing invalid BGP UPDATE message), > > resulting in a flapping BGP session (anyone who wants to test this > > behavior and report/fix this bug can get all the files > needed to reproduce it). > > Just to reconfirm. The issue arrives with sending an update, > not receiving? So if an ISP does not have a limit and their > IOS cannot handle this, they will send an invalid BGP UPDATE > to the downstream peers causing them to reset regardless of > their max as-path settings? > > Just trying to reconfirm, so I can inform my customers if > there was anything they could do to prevent it, or if it is > actually their provider that instigated the peer reset by > sending invalid updates. > > -Jack > >
RE: anyone else seeing very long AS paths?
According to publicly available bug toolkit, CSCee30718 did not touch the maxas limit. The hard-coded maxas-limit in recent IOS releases is 254 (not 75 as suggested in a previous e-mail). Classic IOS (I did not test XE, XR or NX) can handle inbound updates with AS path lengths above 255, but fails miserably when it has to send an oversized update (producing invalid BGP UPDATE message), resulting in a flapping BGP session (anyone who wants to test this behavior and report/fix this bug can get all the files needed to reproduce it). The hard-coded maxas-limit prevents this behavior (254 + my AS = 255), but if you use AS-path prepending on outbound update, you're fried. The __ONLY__ way to be on the safe side is to configure "bgp maxas-limit", otherwise someone who knows you're doing AS-path prepending on major peering sessions (and no inbound AS-path filtering) can selectively target your peering points. I've summarized everything I've discovered in various stress tests today (well, not the targeted attack :) in this article: http://wiki.nil.com/Limit_the_maximum_BGP_AS-path_length Feel free to improve it:) Ivan http://blog.ioshints.info > -Original Message- > From: German Martinez [mailto:gmart...@ajax.opentransit.net] > Sent: Tuesday, February 17, 2009 7:55 PM > To: Michael Ulitskiy > Cc: nanog@nanog.org > Subject: Re: anyone else seeing very long AS paths? > > On Tue Feb 17, 2009, Michael Ulitskiy wrote: > > Hello, > CSCee30718 - it removes the default value of bgp max-as from the > router. > > The solution is introduced in CSCeh13489 > > BGP shouldn't propogate an update w excessive AS Path > 255 > Symptoms: A router may reset its Border Gateway Protocol > (BGP) session. > > Conditions: This symptom is observed when a Cisco router that peers > with other routers receives an Autonomous System (AS) path with a > length that is equal to or greater than 255. > > Workaround: Configure the bgp maxas limit command in such as way that > the maximum length of the AS path is a value below 255. When the > router receives an update with an excessive AS path value, the prefix > is rejected and recorded the event in the log. > > This workaround has been suggested previously by Hank. > > Anyone knows about any possible CPU impacts in case that you implement > bgp maxas? > > Thanks > German > > > My bgp speaking devices are a couple of 7200s running 12.2(40). > > Not the newest IOS out there, but it's been doing the job > just fine up until yesterday. > > Yesterday, when that malformed announcement hit my routers > they didn't > > crash, but they did reset bgp sessions (even though I didn't accept > > the route) and they kept doing so until I got my upstream > to filter it out. > > According to cisco bug toolkit CSCdr54230 should be fixed > in 12.2, so obviously it's not enough. > > Does anybody know what IOS version has fix this problem, > 'cause I couldn't find this info at CCO? > > Thanks, > > > > Michael > > > > On Tuesday 17 February 2009 10:21:07 am Etaoin Shrdlu wrote: > > > Jared Mauch wrote: > > > > > > > On Tue, Feb 17, 2009 at 08:07:36AM +0200, Hank Nussbacher wrote: > > > > > > >>"They" will keep trying and until a vast majority of ISPs > > > >>implement maxas, this will keep happening. > > > > > > > Or until people who are still running > multi-year old cisco code > > > > actually upgrade? This seems to primarily impact: > > > > > > > > 1) Old cisco code > > > > 2) PC based bgp daemons > > > > > > > Both of which likely just need to be upgraded. I > actually suspect > > > > that a lot of people who dropped their bgp sessions did > not notice > > > > something happened, and still will not upgrade their codeI > > > > suspect these people don't even know they have a bgp speaking > > > > device anymore. > > > > > > On the other hand, the fact that various entities have > gone out of > > > their way to advertise that they're running old > hardware/out-of-date > > > software has been noted elsewhere. I'd strongly suggest, > if you're reading NANOG, > > > that you update, before someone less pleasant and friendly than > > > myself finds you. Please. > > > > > > > >
