Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
Hello, On 10.6.2014 19:04, Blake Hudson wrote: > I haven't seen anyone bring up this point yet, but I feel like I'm > missing something... > I receive a full BGP table from several providers. They send me ~490k > *prefixes* each. However, my router shows ~332k *subnets* in the routing > table. As I understand it, the BGP table contains duplicate information > (for example a supernet is announced as well as all subnets within that > supernet) or excess information (prefix is announced as two /17's > instead of a single /16) and can otherwise be summarized to save space > in the RIB. many people deaggregate their address space purposely, including large networks like Google, Akamai, Netflix etc. Full list for analysis like "who does that" is available at http://www.cidr-report.org/as2.0/aggr.html These days also some people split their allocated aggregatable space (PA) with different routing policies for each subnet, substituting old PI addresses (at least in RIPE region). Technically nothing blocks this and politically - it's up to each, what accepts. But some unreachable subnet means problems with customers... There's no summarization in hardware/software from RIB to FIB. From the vendor perspective, they would like to sell you new hardware with larger TCAMs/etc, of course... :-) With regards, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Re: Google Fiber - keeps you regular
There's one tiny detail: Published on Apr 1, 2012... It's April fool... :-) - Daniel On 12/07/2012 12:53 AM, Otis L. Surratt, Jr. wrote: > Yep. But you know I wouldn't be surprised if Google entered that market. > That's why I was asking. You never know these days. > > From: Suresh Ramasubramanian [mailto:ops.li...@gmail.com] > Sent: Thursday, December 06, 2012 5:36 PM > To: Otis L. Surratt, Jr. > Cc: nanog@nanog.org > Subject: Re: Google Fiber - keeps you regular > > All jokes about crappy Internet service aside, that is? > > On Friday, December 7, 2012, Otis L. Surratt, Jr. wrote: > Why does the youtube video link lead back to their Fiber Internet/TV > offering? > Maybe I'm lost but the video is about a Google Fiber Bar right? > > Otis > > -Original Message- > From: Suresh Ramasubramanian [mailto:ops.li...@gmail.com] > Sent: Thursday, December 06, 2012 5:31 AM > To: nanog@nanog.org > Subject: Google Fiber - keeps you regular > > Introducing the Google Fiber Bar > > you'll probably laugh so hard you won't even need the fiber > >
HE.net BGP origin attribute rewriting
Hello, we discovered, that at least Hurricane Electric (HE, AS 6939) does rewrite BGP origin attribute unconditionally in all routes traversing their network. This mandatory, but probably not widely known/used attribute should not be changed by any speaker except originating router (RFC 4271, section 5.1.1). HE rewrites origin for all routes. I tried communicate this issue with HE, but they're not willing change their configuration and respect mentioned RFC document, and they're claiming, that another networks (Level3 was mentioned exactly) does similar thing. In my experience, there're not so many service providers doing that. What's your view on this, do you think, that service providers can simply ignore existing RFCs? With regards, Daniel
Re: HE.net BGP origin attribute rewriting
On 05/31/2012 07:06 PM, Saku Ytti wrote: > On (2012-05-31 08:46 -0700), David Barak wrote: > >> On what precisely do you base the idea that a mandatory transitive attribute >> of a BGP prefix is a "purely advisory flag which has no real meaning"? I >> encourage you to reconsider that opinion - it's actually a useful attribute, >> much the way that MED is a useful attribute. Many providers re-write MED, >> and apparently some re-write ORIGIN. Neither of those is "network abuse" - >> it's more accurately described as "network routing policy." As has been >> stated here before: your network, your rules. > > When provider rewrites MED, they do it, because they don't want peer to > cause them to cold-potato, to which they may have compelling reason. > Then some clever people realise they forgot to rewrite origin, working > around the implicit agreement you had with them. > You CAN rewrite MED, as stated in RFC 4271, section 5.1.4 - but you SHOULD NOT change origin attribute, as stated in section 5.1.1. So, in terms of rewriting, MED is not comparable to origin. I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear here. Back to the standard, why condone it's violation? Yes, statement about origin is here since January 2006 - older RFC 1771 didn't contain similar rule. But 6 years after publishing I think everyone had enough time to implement this correctly. I still think, that professionals shoult follow RFC and not insert their own creativity to places, where's not expected - just because they decide that as a "cool" idea. For local routing policy - there're still lot of knobs, which can be used internally (typically MED, LOCPREF) to enforce expected policy and there's technically no reason to change origin. -- Daniel
Re: HE.net BGP origin attribute rewriting
On 06/01/2012 07:38 PM, Joe Provo wrote: > You clearly did not read the previous posts involving actual historical > evidence [and apparently ongoing] of remote networks attempting action > at a distance knowing that many overlook this part of the decision tree. > Preventing your company from bleeding money or degrading performance at > whim of remote parties certainly is "cool" but also just good business > and proper network hygiene. By overwriting origin field, there's no warranty that someone improves performance at all - it's just imagination. In extreme cases, performance can be degraded when someone in the middle plays with origin field and doesn't know reasons, why originating network uses something else than IGP origin. In RFC 2119 words, full implications were not understanded - when this overwriting is done generally. Also, there must be some historical reason, why origin should not be rewritten (this changed in January 2006). For internal reasons within the network operator still haves enough knobs to enforce own policy (by setting localpref, med on his network). Daniel
Re: HE.net BGP origin attribute rewriting
On 06/02/2012 02:42 AM, Richard A Steenbergen wrote: > On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote: >> By overwriting origin field, there's no warranty that someone improves >> performance at all - it's just imagination. In extreme cases, >> performance can be degraded when someone in the middle plays with >> origin field and doesn't know reasons, why originating network uses >> something else than IGP origin. In RFC 2119 words, full implications >> were not understanded - when this overwriting is done generally. > > Uh, what part of "to prevent remote networks from improperly forcing a > cold potato routing behavior on you" sounds imaginary? It depends, not everything looking as proper from single network operator in the middle can be proper in end-to-end user experience, where multiple networks are traversed. >> Also, there must be some historical reason, why origin should not be >> rewritten (this changed in January 2006). For internal reasons within >> the network operator still haves enough knobs to enforce own policy >> (by setting localpref, med on his network). > > Not really, no. Not every RFC is 100% correct, and they're often written > by people who are not operators (because operators are too busy running > real networks :P). Besides, "SHOULD NOT" means "you probably don't want > to do this, unless you have a really good reason", and enforcing such an > important point in a peering policy is a pretty good reason. If someone comes with some implementation overwriting ASPATH (even it may not) and excuses this by RFC incorrectness from his perspective, you'll understand it? Probably not. It's relative. > You also clearly don't understand the practical use of localpref. When > you're trying to implement a simple and relatively common policy like > "closest exit routing to a peer with multiple exits", you set the > localprefs the same (localpref is usually used to determine WHICH peer > you'll be sending to), you set the MEDs the same (if you don't want to > artifically select which EXIT to use), AS-PATH lengths are obviously the > same if you have multiple exits, and then the next one down is origin > code. If you can't reset origin code, you run the risk of a remote > network being able to force your network to do something you probably > don't want to do (or at least probably wouldn't want to do, if you had > any idea what you were doing :P). Well, this matches situatios, where two networks have more than single interconnection and still for prefixes originated from that particular network. But when there's only one interconnection, there's no such reason. Intermediate networks, even having multiple peers will probably see similar origin on all their peers. > Please see the previous commentary from Joe Provo, Saku Ytti, etc, they > are quite correct. I don't think they admits all consequences. When some knob (origin) is not disabled by policy for single prefix visible at multiple points, some "creative" operators should come with other methods to achieve what they wants. Prefix deagregation is first thing, that comes to mind. Even they'll also slightly violate RFC (having not single policy - well, they assume RFC is not correct), they simply start to announce deagregated prefixes next to aggregate one. But deaggregated prefixes are announced only to specific peers - and yes, this works. Then, you can have any policy, have everything normalized at all peers - but most specific prefix in your table visible over particular path simply wins over everything. And this is not a imaginary case - this is clearly visible in real routing table - 41% of address space (in IPv4) is deaggreated, in my experience mainly due to "traffic engineering" purposes - smaller end networks are simply enforced to do this, and some people here confirmed this in this discussion... - Daniel
Re: HE.net BGP origin attribute rewriting
On 06/02/2012 02:53 AM, Joe Provo wrote: > Cost and performance were merely two reasons someone may wish to prevent > remote parties from using origin to influence outbound traffic from my > network. As I mentioned already, it will influence that by another way. And this costs *you* more money - you have to pay for router with larger TCAMs, more memory, faster CPUs... and yes, deaggregation is very simple task for originating network - much easier than playing with the origin flag, which is not understanded widely. > I can state it is not imagination when I encountered networks > doing this in the past for prefixes they were sourcing. To be clear - > these were prefixes being sourced by a neighbor who was providing > different origin codes on different sessions. Either they were [to > Nick Hilliard's point] using different kit and unaware of the differnt > implementations or [as evidence bore out] purposefully shifting traffic > without arrangement on links that were worse for me and in violation > of the agreement we entered into when peering. More specific prefix in addition to aggregate one visible only over specific peers will do the job, too. And will do that job better... but for what cost (not only to you)...? > There certainly were historical reasons for treating origin as sacrosanct. > Time has marched on and those reasons are now *historical*, hence the > quite reasonable updat eto the RFC. You seem to fail to understand that > MED comes after origin on the decision tree, and therefore someone can > influence traffic carriage without agreement. You seem to fail realize other (easier) ways to influence traffic carriage. Deaggregation with selective route announcement is quite common way, many networks do that. - Daniel
Re: HE.net BGP origin attribute rewriting
On 06/02/2012 12:43 PM, Joe Provo wrote: > Last post on this topic for me. You seem to wish to argue > against the lessons of history and the reality of running > a network on the global Internet. Based on observations from routeviews / RIPE RIS / other public sources, overwriting BGP origin isn't a common practice. I did some analysis before I opened this topic. >From tier-1 networks, only Level3 seems to do this, from other major networks only HE. Based on network listed at http://en.wikipedia.org/wiki/Tier_1_network, there're 2 of 22 major (and only 11 tier-1) worldwide networks performing origin overwritting. That's really not a representation of common and widely used practice. I'm not arguing with common practice on the internet. Majority doesn't touch origin attribute... (and yes, basically I don't care about pure tier-2/3 networks, their impact isn't peremptory in terms of their global impact) > The two issues are orthogonal. Deaggregating sources have > been cost-shifting [in a highly visible and easily examined > and often trivially-filtered] manner for ages. In global table, there's 41% overhead, in terms of prefixes announced. I don't think it's trivial to filter this overhead. If you're correct (I don't think so), why there's this huge ammount of unfiltered deaggregated prefixes in global table? Because it's easier to buy new hardware. > A midspan network deaggregating someone else's prefixes is > broken and gets called out, generally by the originator if > they have a clue. This is bad at all - but sometimes also happens with huge impact and this is historically documented on some cases like Pakistan Telecom/Youtube. And this happened, even you said that filtering is trivial... - Daniel
Google/Youtube problems
Hello, for approx. last 14 days we're seeing problems with video playing from youtube (page loads without problems, but player shows error), and also other applications like maps are having problems. As these problems were only for some of prefixes announced out of AS 8251, we recognised that as problem with Google's CDN and reported it to Google. As workaround, filtering affected prefixes from peering in Prague partially helped. We already tried communicate problem with Google from the beginning (in our network, around 5 end users are directly afected), and they're claiming, that problem is related only to our network and there's no global issue. But similar issues we're seeing from some other networks, which are peering with Google and have nothing common with our AS8251. We sent emails to Google NOC/NST, also tried to phone them about the problems, but according to end-user claims, problem persist. Problem is isolated only to peak hours, when something seems to be saturated. If I recall past optional IPv6 from Google, they said: "It is very important to us that our users always receive the best possible experience". But majority of end users still uses IPv4 and we're seeing problems here - and response is minimal. At least information about cause of the problem and expected time for problem resolution. Is anyone else seeing similar problems with Google/Youtube? With regards, Daniel
Re: /27 the new /24
It's not only about TCAM (and it's price), but also about convergence times... On 2.10.2015 17:48, Matthew Kaufman wrote: > Cheaper than buying everyone TCAM > > Matthew Kaufman smime.p7s Description: S/MIME Cryptographic Signature
Re: Cisco Routers Vulnerability
Hello, ask your customers, if they had VTY access secured properly. Brute-force password attacks against management interface (telnet, SSH) aren't rare these days and once you have management access, you can do anything independently on known code vulnerabilies. With regards, Daniel On 13.4.2015 23:29, Rashed Alwarrag wrote: > Hi > Today we have a lot of customers report that their Cisco routers got a root > access and the IOS got erased , is there any known vulnerability in cisco > products thats they report in their Security alerts about this recently ? > is there any one face the same issue ? > > Regards >
Re: /25's prefixes announced into global routing table?
On 06/22/2013 12:27 AM, Jakob Heitz wrote: >> Date: Fri, 21 Jun 2013 16:14:07 -0400 >> From: "Majdi S. Abbas" >> The forwarding hardware is generally going to be the limit, and >> that's going to be painful enough as we approach a half million >> prefixes. > > There are techniques to fix that. For example, Simple Virtual Aggregation > http://tools.ietf.org/html/rfc6769 > I'm not sure, if hardware vendors will implement something like this. I expect they'll sell you router with larger hardware FIB instead. - Daniel
Re: Europe-to-US congestion and packet loss on he.net network, and their NOC@ won't even respond
On 1.12.2013 11:49, Randy Bush wrote: >>> Using a 1/10th of a second interval is rather anti-social. >>> I know we rate-limit ICMP traffic down, and such a >>> short interval would be detected as attack traffic, >>> and treated as such. >> For what it is worth, I used to think the same, until I saw several >> providers themselves suggest that 1000 packets should be sent, with >> the 0.1 s interval. So, this is considered normal and appropriate >> nowadays. > > matthew is correct > > go back to your old way of thinking. while some providers may tolerate > fast pings, few if any grown-ups do. and even thouse who think they do > have routing engines which consider all pings as low priority rubbish to > be dropped when there is any real work to do. > From router control-plane perspective, rate-limiting should be always expected and result evaluation should take that in account. From router perspective, packet with TTL=1 is handled typically in software, in CPU with limited power (compared to modern hardware) and it's not a primary job of router to answer to each TTL=1 packet - that's correct view. But, provided reports shows ALSO end-to-end packet loss, which never will be caused by control-plane policers on transit routers, these packets will never hit router CPU. And there we talk about basic network neutrality - everyone should treat all data equally, independently of protocol used for data transport. Daniel smime.p7s Description: S/MIME Cryptographic Signature
Re: AS 3356 (Level 3) -- Community 3356:666
Hello, there's exactly *one* blackhole well-known community, which should be used for this purpose - 65535:666 (standardised in RFC 7999). There's no reason to use even "ASN:666" format these days... - Daniel On 8/4/21 3:28 PM, Sriram, Kotikalapudi (Fed) via NANOG wrote: There is an old NANOG thread from 2005 that said AS 3356 (Level 3) were applying 3356:666 to indicate Peer route: https://archive.nanog.org/mailinglist/mailarchives/old_archive/2005-12/msg00280.html Also, see: https://onestep.net/communities/as3356/ Now network operators commonly use ASN:666 for BGP Blackholing Community. (ASN = the operator's AS number) See, for example, https://www.he.net/adm/blackhole.html Does anyone know if AS 3356 has changed how it uses 3356:666? I.e., is it known if they now use it for Blackholing Community? Thank you. Sriram
Re: Ukraine request yikes
Hello, On 3/1/22 21:08, David Conrad wrote: - Shutdown the root server instances operated by ICANN that are within Russia ICANN could conceivably do this unilaterally, but there are a lot more root server instances operated by other RSOs (including RIPE NCC, Verisign, ISC, and NASA). It's also technically possible to perform full AXFR from some official root-server (it's allowed on some instances) and bring your own root-server locally-anycasted instance anywhere you want. Shutdown of root servers in Russia will not solve anything. - Daniel
Re: Question re prevention of enumeration with DNSSEC (NSEC3, etc.)
On 5/8/22 19:48, Warren Kumari wrote: If zone enumeration was not a real concern, NSEC3 would not exist. Ackchyually, that's only partly true — a significant amount of the driver (some would say hte large majority) behind NSEC3 was that it supports "opt-out". This was important in very large, delegation-centric zones (e.g like .com), where the vast majority of delegations were initially not signed. This allows just signing the signed delegation and the holes between them, and not all of the unsigned delegations. But, with op-out, there're some security concerns around... so TL;DR generally you should avoid-it. http://www.e-ontap.com/dns/entpoison.html https://theory.stanford.edu/people/jcm/papers/dnssec_ndss10.pdf
