Re: Re udp port overload on ipv4 (was Re: V6 still not supported)
On 10/03/2022 21:03, Matthew Walster wrote: If that was feasible, we would likely be using SCTP by now. TCP, UDP, and ICMP are likely to be the only reliable IP protocols for the foreseeable future on the internet. (As in, inter-domain) But QUIC runs on UDP - it is not a new protocol, we are just using stupid UDP. UDP nat is as old as nat itself. And anyway QUIC is dead and all the development goes now over its successor - HTTP/3. -- Grzegorz Janoszka
Re: IPv6 and CDN's
On 26/11/2021 22:47, Jean St-Laurent via NANOG wrote: "And when IPv6 is in use, the median connection setup is 1.4 times faster than IPv4. This is primarily due to reduced NAT usage and improved routing." Oh I believe IPv6 is faster but because of completely different reasons. Modern faster connections more likely have IPv6 while old low-bandwidth circuits may provide v4 only. Some users may also use VPN which is almost always v4 only. Their VPN may do funny routing, hair-pinning and similar behavior thus impacting their performance. -- Grzegorz Janoszka
Re: "Tactical" /24 announcements
On 2021-08-09 17:47, Billy Croan wrote: How does the community feel about using /24 originations in BGP as a tactical advantage against potential bgp hijackers? RPKI is more effective than a competing /24. Unless they hijack you ASn as well. -- Grzegorz Janoszka
Re: COVID-19 vs. our Networks
On 2020-03-16 15:04, Alexandre Petrescu wrote: There is no other way to do that information filterning now. Nobody has any authority of knowing better than others. There is a good word for information filtering. It is called 'censorship'. Times like now are perfect opportunity to limit the remains of our freedom. Please think twice before you complain for lack of information filtering. Because the government will surely make you happy. -- Grzegorz Janoszka
Re: Equinix
On 05/12/2019 17:10, Martijn Schmidt via NANOG wrote: You're probably best off ordering those crossconnects through the Equinix portal, then you can choose the exact positions for the order that goes to the facility rather than relying on a human to transcribe them correctly from your PDF. If only Equinix portal reflected how your patch panels really look like... -- Grzegorz Janoszka
nanog@nanog.org
Hi, Whenever I try to send something to emails in @att.net I get a reply: host ff-ip4-mx-vip1.prodigy.net[144.160.159.21] said: 553 5.3.0 flph831 DNSBL:RBL 521< MY.IP4.ADD.RES >_is_blocked.For assistance forward this error to abuse_...@abuse-att.net (in reply to MAIL FROM command) Of course emails to abuse_rbl go unanswered. My IP turns clean on https://www.dnsbl.info/ (all green and one blue timeout). Anyone had such issues? Any working contacts to AT&T email? Any help appreciated. -- Grzegorz Janoszka
Re: This DNS over HTTP thing
On 01/10/2019 09:22, Brandon Butterworth wrote: Here are some UKNOF presentations on it - Also very interesting from NLNOG (but in English): https://www.youtube.com/watch?v=pjin3nv8jAo -- Grzegorz Janoszka
Re: well-known Anycast prefixes
On 2019-03-19 21:04, Hansen, Christoffer wrote: https://github.com/netravnen/well-known-anycast-prefixes/blob/master/list.txt PR's and/or suggestions appreciated! (Can be turned into $lirDB friendly format->style RPSL) Most DNS root servers are anycasted. -- Grzegorz Janoszka
Re: Rising sea levels are going to mess with the internet
On 23/07/2018 20:03, Owen DeLong wrote: It shows China, the most heavy handed of the three economies in the graphic as having an accelerating growth in carbon emissions. It does show that the EU started a downward trend earlier than the US, but that the downward trend in the EU appears to be leveling off and the US downward trend looks to be steeper now and accelerating. In addition, if you drill down to the individual EU countries, several of them are, in fact, headed up while the more market-based members of the EU seem to be headed down or having leveled off after a sharp decline earlier. The data is flawed. The carbon emissions per country don't include import, so you can just import the most carbon-heavy product from China and you will see your country emissions falling and China's growing. And the carbon emission of USA doesn't include Pentagon, while any other army is included in it's country numbers. So we can' really compare such flawed data - these are just numbers for politicians but they have nothing in common with reality. Regarding rising sea levels - I wonder why nobody mentioned submarine fiber landing stations. If something will be affected, it will be them. -- Grzegorz Janoszka
Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks
On 2018-02-28 13:42, Denys Fedoryshchenko wrote: I want to add one software vendor, who is major contributor to ddos attacks. Mikrotik till now shipping their quite popular routers, with wide open DNS recursor, that don't have even mechanism for ACL in it. Significant part of DNS amplification attacks are such Mikrotik recursors. They don't care till now. I have mixed experiences with Mikrotik, but I don't think they would do such a stupid thing. A friend of my has three offices and each one has mikrotik to form tunnels and one domain for all the company. He is not too IP savvy, so he copy-pasted the VPN config from internet and left the rest as it was. His routers are not open DNS resolvers. When I asked them I got no reply and their logs showed: _drop input: in:ether1 out:(unknown 0), src-mac 00:AB:CD:81:c2:71, proto UDP, AAA.47.138.134:9082->BBB.146.251.103:53, len 51 His settings showed the DNS server ON with all the queries for the local network and he actually had a toggle "allow remote queries" on, but his routers were not open resolvers. -- Grzegorz Janoszka
Re: Question about Customer Population by ASN for Canada
On 2017-10-02 21:57, Jacques Latour wrote: The question I have is why does OVH come #6 with an estimated population of 1,480,927 behind its ASN? Remember these are actual placement of ads. Should I count those users as part of my stats? I would say VPN - OVH has cheap servers and is quite popular in this industry. There are countries where many active users have to use a sort of VPN to access banned sites. So they are users, but rather not from Canada. -- Grzegorz Janoszka
Re: MTU
On 2016-07-22 20:20, Phil Rosenthal wrote: On Jul 22, 2016, at 1:37 PM, Grzegorz Janoszka wrote: What I noticed a few years ago was that BGP convergence time was faster with higher MTU. Full BGP table load took twice less time on MTU 9192 than on 1500. Of course BGP has to be allowed to use higher MTU. Anyone else observed something similar? I have read about others experiencing this, and did some testing a few months back -- my experience was that for low latency links, there was a measurable but not huge difference. For high latency links, with Juniper anyway, there was a very negligible difference, because the TCP Window size is hard-coded at something small (16384?), so that ends up being the limit more than the tcp slow-start issues that MTU helps with. I tested Cisco CRS-1 (or maybe already upgraded to CRS-3) to Juniper MX480 or MX960 on about 10 ms latency link. It was iBGP carrying internal routes plus full BGP table (both ways). I think the bottleneck was CPU on the CRS side and maxing MSS helped a lot. I recall doing later on tests Juniper to Juniper and indeed the gain was not that big, but it was still visible. Juniper command 'show system connections' showed MSS around 9kB. I haven't checked TCP Window size. -- Grzegorz Janoszka
Re: MTU
On 2016-07-22 15:57, William Herrin wrote: On a link containing only routers, you can safely increase the MTU to any mutually agreed value with these caveats: What I noticed a few years ago was that BGP convergence time was faster with higher MTU. Full BGP table load took twice less time on MTU 9192 than on 1500. Of course BGP has to be allowed to use higher MTU. Anyone else observed something similar? -- Grzegorz Janoszka
Re: Internet Exchanges supporting jumbo frames?
On 09/03/2016 15:26, Kurt Kraut via NANOG wrote: Could anyone share with me Internet Exchanges you know that allow jumbo frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit from it? Netnod does it in separate vlan's. -- Grzegorz Janoszka
Re: How to force rapid ipv6 adoption
On 02/10/2015 04:52, Curtis Maurand wrote: If Time Warner (my ISP) put up IPv6 tomorrow, my firewall would no longer work. I could put up a pfsnse or vyatta box pretty quickly, but my off the shelf Cisco/Linksys home router has no ipv6 support hence the need to replace the hardware. There's no firmware update for it supporting ipv6 either. There would be millions of people in the same boat. There should be a software for your box which supports IPv6 - DD-WRT or anything similar. However I agree that it is not a solutions for millions of Johnny Sixpacks. -- Grzegorz Janoszka
Re: How to force rapid ipv6 adoption
On 2015-10-01 20:29, Owen DeLong wrote: However, I think eventually the residential ISPs are going to start charging extra for IPv4 service. ISP's will not charge too much. With too expensive IPv4 many customers will migrate from v4/dual stack to v6-only and ISP's will be left with unused IPv4 addresses and less income. Will ISP's still find other profitable usage for v4 addresses? If not, they will be probably be quite slowly rising IPv4 pricing, not wanting to overprice it. Even with $1/IPv4/month - what will be the ROI of a brand new home router? -- Grzegorz Janoszka
Route leak in Bangladesh
We have just received alert from bgpmon that AS58587 Fiber @ Home Limited has hijacked most of our (AS43996) prefixes and Hurricane Electric gladly accepted them. Anybody see their prefixes hijacked as well? -- Grzegorz Janoszka
Re: Open letter to Level3 concerning the global routing issues on June 12th
On 2015-06-13 12:34, Mark Tinka wrote: I know the largest transit providers tend to be more relaxed for various reasons. Some rely on filters generated by IRR entries, others don't. Actually I had pretty good experiences with Level3 as it has been years as they could use IRR filters to update automatically your prefix list. I remember that Level3 was one of the first carriers to enable that feature and several years afterwards there were still global networks (tier1) that could only do static prefix-lists. -- Grzegorz Janoszka
Re: Peering and Network Cost
On 2015-04-15 19:50, Max Tulyev wrote: transit cost is lowering close to peering cost, so it is doubghtful economy on small channels. If you don't live in Amsterdam/Frankfurt/London - add the DWDM cost from you to one of major IX. That's the magic. In large scale peering is still efficient. It is efficient on local traffic which is often huge. Even in the three cities you mentioned peering on small scale is usually not cheaper at all or only very little. Please keep in mind that some companies peer despite it offers no savings for them and at the end of the day it might be even more expensive. They do it because of performance and reliability reasons. -- Grzegorz Janoszka
Re: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact
Isn't it better actually to use they? https://en.wikipedia.org/wiki/Singular_they -- Grzegorz Janoszka On 2014-12-27 20:35, Clayton Zekelman wrote: That is why the better pronoun choice would have been 'you', not 'he' or 'she'. Sent from my iPhone On Dec 27, 2014, at 1:47 PM, Javier J wrote: What if they don't identify as a he or a she? On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman wrote: What if the peering team member is a she? Should she not contact you if so? Sent from my iPhone On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr wrote: Hello, If someone from IAM peering team is watching, could he please get in touch OFF-list please ? Best regards. -- Youssef BENGELLOUN-ZAHR
Re: Applications that break when not using /64
On 17/06/14 23:13 , Jeroen Massar wrote: Thus, can you please identify these applications so that we can hammer on the developers of those applications and fix that problem? I haven't done extensive testing. I have just tried to divide a /64 into smaller subnets and to run Debian and Windows on it (as Matthew Petach did with his FreeBSD). I think I have tried /112 or /120. Debian was mostly fine, just one torrent or newsgroups client couldn't do v6 (can't recall which one), with Windows it was a different story and basically nothing really worked. It was some time ago and I haven't tried Windows 7 SP1, maybe it has been fixed till now. Does anyone have Windows with IPv6 and netmask > /64? -- Grzegorz Janoszka
Re: Credit to Digital Ocean for ipv6 offering
On 2014-06-17 22:13, David Conrad wrote: On Jun 17, 2014, at 12:55 PM, Grzegorz Janoszka wrote: There are still applications that break with subnet smaller than /64, so all VPS providers probably have to use /64 addressing. Wouldn't that argue for /64s? /64 netmask, but not /64 for a customer. There are application which break if provided with /80 or /120, but I am not aware of an application requesting /64 for itself. /64 for one customer seems to be too much, In what way? What are you trying to protect against? It can't be address exhaustion (there are 2,305,843,009,213,693,952 possible /64s in the currently used format specifier. If there are 1,000,000,000 customer assignments every day of the year, the current format specifier will last over 6 million years). Too much hassle, like too big config of your router. If you have 1000 customers in a subnet, you would have to have 1000 separate gateway IP's on your router interface plus 1000 local /64 routes. -- Grzegorz Janoszka
Re: Credit to Digital Ocean for ipv6 offering
On 2014-06-17 21:46, David Conrad wrote: No, 8 individual IPv6 addresses. Wow. Harsh. I burn more than that just in my living room. I don't think that is too harsh as all 8 are assigned to a single server. So if I have three VPS's, I have 24 total addresses. In the case of my 3 VPS's, I've received /64s from both RootBSD.net and Arp Networks or 55,340,232,221,128,654,848 addresses. I'm not sure I see a rationale for assigning 8 addresses. That is, I could understand assigning a single address or a /64 but 8 addresses? I'd think that'd be more complicated/error prone than either the /128 or /64 options. A bit odd. There are still applications that break with subnet smaller than /64, so all VPS providers probably have to use /64 addressing. /64 for one customer seems to be too much, on the other side 8 IP's can be not enough in some cases. I think 65536 out of shared /64 for one server can be enough. You can easily automate provisioning and reverse DNS assuming you assign /112 for each server. If you block SLAAC and provide connectivity to only the static IP's, your abuse folks should appreciate it (yes, I know you can spoof v6). -- Grzegorz Janoszka
Re: Fundamental questions of backbone design
On 2013-10-18 20:03, Anurag Bhatia wrote: 1. As I understand it's (sort off) common practice to give highest localpref to customer routes then peering and finally transit. Does this works well or you see issues with people who have 10+ prepends on some peering routes calling you to not send traffic via those circuits? Does it makes sense to put a rule to avoid routes 2-3 AS path away when changing local preference? Hi, You may try a different trick on peering routes. You rather don't peer with the tier 1 networks, so you may filter out (or assign a low localpref to) all prefixes received from peering partners which contain in as-path some well known asn's, like let's say 174, 1299, 3356 and so on. Such routes are most likely leaked and traffic via those paths will be either blackholed or, in the best case, going via not really optimal path. 2. If I have more peering capacity and relatively less capacity between my own PoPs and I start injecting routes in my IGP then how to prevent change of choking of backbone? Is it standard practice to have more capacity on backbone then peering links? Or I have to inject less routes in IGP - say a few % of total routes? You may always prefer peering routes local to the PoP (giving them the highest localpref). This way you will not carry so much traffic on your backbone. -- Grzegorz Janoszka
Re: BGPmon.net /32 hijack alerts
On 26-07-13 14:59, NetSecGuy wrote: > BGPMon.net has alerted me to /32 hijacks. Does anyone have thoughts on > what this might be and if it's malicious or misconfiguration? > My first thought is leaked null routes.Is this even worth alerting on? We had similar cases. In most cases they appeared to be indeed leaked null routes. -- Grzegorz Janoszka
Re: Google's QUIC
I am surprised nobody mentioned security issues. To minimize latency the following would be best: the client sends one UDP packet and receives stream of UDP packets with page code, styles, images and whatever else could be needed. The waiting time is just RTT plus browser processing. It is a great amplification tools, isn't it? There are pages which require loading megabytes of data just for one request, so definitely more than 1000 UDP packets (MTU 1500). Amplification factor 1:1000+ in packets, 1:1+ in octets :) Of course you can add to the protocol some small initial response, key exchange, whatever, but then the page appears after N*RTT, which is already happening with TCP now. I am sure Google considered it, so I am really curious how they are going to solve it. -- Grzegorz Janoszka
Re: /25's prefixes announced into global routing table?
On 22-06-13 17:30, Owen DeLong wrote: > Looking at the number of autonomous systems in the IPv6 routing table and the > total number of routes, it looks like it will shake out somewhere in the > neighborhood of 3-5 prefixes/ASN. Since there are ~35,000 unique ASNs in the > IPv4 table, I figured simple multiplication provided as good an estimate as > any at this early time. Deaggregating of IPv4 announcements is done for traffic engineering and to fight ddoses (just the attacked /24 stops being announced to internet). I think some people will just copy their v4 habits into v6 and then we might have explosion of /48's. I wouldn't be so sure about just 3-5 prefixes/ASN. -- Grzegorz Janoszka
Re: /25's prefixes announced into global routing table?
On 21-06-13 21:56, Michael McConnell wrote: > As the IPv4 space get smaller and smaller, does anyone think we'll see a time > when /25's will be accepted for global BGP prefix announcement. The current > smallest size is a /24 and generally ok for most people, but the crunch gets > tighter, routers continue to have more and more ram will it always be /24 the > smallest size? As the fragmentation will progress and we will be closing to the magic limit of 500.000, people will filter out /24 and then /23 and so on. Back to static (default) routing! -- Grzegorz Janoszka
Re: Color vision for network techs
On 31-08-12 16:15, Berry Mobley wrote: > Do any of you do any color vision screening in your interview process? > How do those of you with color vision impairments compensate? I'd never > considered this until I was in one of our facilities with my son (who > has limited color vision) and we had a discussion about the LEDs. He > could only determine on/off - not amber/red/green on the equipment we > had. I'm wondering if we need a color vision requirement (or test) as > part of our hiring requirements. I have troubles with orange-yellow-greenish colors. Red is fine, most of greens as well. Already 15 years within the industry, several different jobs. Nobody ever asked me, but I think I mentioned it to all potential employers during interviews. For some of them it was funny or even interesting but I don't think anybody considered it as my disadvantage. Despite in most cases I cannot tell amber LED from yellow or orange one, I don't think it affects my duties. Usually different colors have also different luminosity, so shortly you learn characteristics of different products, like that with Cisco amber is the "darker one". I have also seen blades with broken LED's that had all the colors but one (like 6704 port with green and no amber), so to be 100% sure one should always check the console. -- Grzegorz Janoszka
Re: Level 3 BGP Advertisements
On 29-08-12 22:55, STARNES, CURTIS wrote: > We are announcing our /19 network as one block via BGP through AT&T, not > broken up into smaller announcements. > Earlier in the year I started receiving complaints that some of our client > systems were having problems connecting to different web sites. > After much troubleshooting I noticed that in every instance the xlate in our > Cisco ASA for the client's IP last octet was either a 0 or 255. > Since I am announcing our network as a /19, the subnet mask is 255.255.224.0, > that would make our network address x.x.192.0 and the broadcast x.x.223.255. > So somewhere the /24 boundary addresses were being dropped. > > Just curious if anyone else has seen this before. Yes, actually there are people over Internet blocking all IP's ending with 0 or 255 as a kind of bogon or other old wives' tale. -- Grzegorz Janoszka
Re: using "reserved" IPv6 space
On 2012-07-15 15:30, Scott Morris wrote: >> There was also in the past fec0::/10. For BGP updates you should be safe >> to filter out FC00::/6. > Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So > while FE00::/7 may yet be unallocated, I don't think I'd set filters in > that fashion. > Reasonably, wouldn't it be more likely to permit BGP advertisements > within the 2000::/3 range as that's the "active" space currently? FF00::/8 are multicast, FE80::/10 are reserved for link-local. In the past you had FEC0::/10 as a kind of private addresses. Allowing 2000::/3 is fine as well. Btw - what are the estimates - how long are we going to be within 2000::/3? -- Grzegorz Janoszka
Re: using "reserved" IPv6 space
On 2012-07-15 00:45, Tony Hain wrote: > There is no difference in the local filtering function, but *IF* all transit > providers put FC00::/7 in bogon space and filter it at every border, there > is a clear benefit when someone fat-fingers the config script and announces > what should be a locally filtered prefix (don't we routinely see unintended > announcements in the global BGP table). I realize that is a big IF, but There was also in the past fec0::/10. For BGP updates you should be safe to filter out FC00::/6. -- Grzegorz Janoszka
Re: IPv6 explicit BGP group configs
On 08-02-12 17:59, keith tokash wrote: > I'm prepping an environment for v6 and I'm wondering what, if > any, benefit there is to splitting v4 and v6 into separate groups. > We're running Junipers and things are fairly neat and ordered; we have > multiple links to a few providers in many sites, so we group them and > apply the policies at the group level. We could stick the new v6 > neighbors into the same group and apply the policies at the neighbor > level, or create new groups (i.e. Level3 and Level3v6). Sometimes we have the same group for v4 and v6, but in most cases we have different ones. One of the basic reasons is different max-pref setting. Most policies can be used in two address families, you can also match prefixes, but you cannot have v4 and v6 prefixes in one term. So in your policies you have to have at least two terms - one for v4 prefixes, one for v6 prefixes. -- Grzegorz Janoszka
Re: MD5 considered harmful
On 27-01-12 21:52, Patrick W. Gilmore wrote: > Who would want to reset a BGP that will come back up in 30-90 seconds when > you can packet an entire router off the 'Net easier, more quickly, and for > longer a period? +1 Actually, when you have lot of MD5 BGP session coming up at the same time (a connection to internet exchanges went up), you have longer convergence time because of higher cpu load. MD5 offers no security advantages and in some cases it causes more downtime by slowing down convergence. -- Grzegorz Janoszka
Another internet depeering?
Telia (AS1299) stopped announce some prefixes to us, ie 83.8.0.0/13. Is it another internet depeering? Do you also see it? -- Grzegorz Janoszka
Re: Cogent IPv6
On 09-06-11 14:01, Chuck Anderson wrote: > Please don't use /127: > > Use of /127 Prefix Length Between Routers Considered Harmful > http://tools.ietf.org/html/rfc3627 Well, this RFC says not to use PREFIX::/127. You are safe to use other /127's within your prefix. -- Grzegorz Janoszka
Re: IPv6: numbering of point-to-point-links
On 24-01-11 13:59, Carlos Friacas wrote: > Using /126s or /127s (or even /120s) is a result of going with the v4 > mindset of conservation. Not only, there are some other advantages of using /126's, like reducing number of ND requests on the link and the size of neighbor tables. -- Grzegorz Janoszka
Re: IPv6
On 21-11-10 22:31, Cameron Byrne wrote: Yahoo just dropped in on the IPv6 content party http://ipv6.weather.yahoo.com/ I just bookmarked it. Well done Yahoos. Well, ipv6.ycpi.ops.yahoo.net has IPv6 address 2a00:1288:f006:1fe::1000 ipv6.ycpi.ops.yahoo.net has IPv6 address 2001:4998:f00b:1fe::1000 ipv6.ycpi.ops.yahoo.net has IPv6 address 2001:4998:f011:1fe::1000 In my bgp I see only the first address, I don't see any path to two others. Do you have the route to them? -- Grzegorz Janoszka
Re: Did your BGP crash today?
On 27-08-10 20:41, Thomas Mangin wrote: I think most of the impact was limited to Europe, especially Amsterdam area. Yes, It had an effect on ISPs which are connected to RIS. http://www.ripe.net/ris/ AFAIK this mean ASes at LINX and AMS-IX . The LINX graph shows a similar (but smaller) dip of 50-60 GB. Not only. We don't peer with RIS, but about 8-10 our peers announce to us RIS. The nasty update we got from completely different AS, not RIS. You may just check whether you see AS12654 - it is RIS. -- Grzegorz Janoszka
Re: Did your BGP crash today?
On 27-08-10 19:31, valdis.kletni...@vt.edu wrote: On Fri, 27 Aug 2010 19:27:06 +0200, Kasper Adel said: Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? If it in fact "crashed the internet", as opposed to "gave a few buggy routers here and there indigestion", you wouldn't be posting to NANOG looking for confirmation. :) https://www.ams-ix.net/statistics/ Not whole internet, but a part. And the "few buggy routers here and there" were mostly Cisco CRS-1's which didn't understand the new attribute and sent a malformed message to all peers, causing them to close the BGP session. I think most of the impact was limited to Europe, especially Amsterdam area. -- Grzegorz Janoszka
Re: Mikrotik RouterOS
On 12-4-2010 21:44, Gustavo Santos wrote: its was an old bug, that had been fixed for a while.. You should still keep in mind Mikrotik is just Linux, with all its (dis)advantages, plus some scripts and weird CLI. -- Grzegorz Janoszka
Re: Peering Exchange Configurations
On 8-4-2010 18:02, Brad Fleming wrote: 1) Is a private AS typically used for the exchange side of the session? No. 2) Are RFC1918 IPs typically used for the p2p links into the exchange? No. In EU usually it is separate public /24, /23 or /22. The IPv6 range in RIPE region for exchanges is assigned from within special pool 2001:7f8::/32 (each IX gets /48). 3) Do peering exchanges typically remove their AS from the path advertised to exchange participants? The direct peering is between participants AS'es, there is nothing in between, including IX AS. Route-servers based on Cisco box put their AS number in between, but Quagga/Bird usually remove the IX as, however it may be configured per peer not to do so. 3a) If no: Do participants typically preference exchange-learned routes over other sources? Most do. 4) Do exchanges typically support the following address families? IPv4 Multicast no IPv6 Unicast Almost all. IPv6 Multicast No. In exchanges where a route server is employed: 4) Do participants have a p2p link into a simple routing environment then multi-hop to a route server? Route-server is just like one of the members of the exchange. You get /23 or similar prefix of the exchange. You may have a BGP session with the route-server, but you are also free to have direct BGP sessions with other parties. Route-servers are mostly used by peers with open peering policies, but you still may steer your announcements basing on BGP communities. 5) I see that Bird, OpenBDGd, and Quagga are all options for route server software. Does one of those packages stand out as the clear current choice for production peering exchanges? Quagga was used most often, but recently most biggest EU exchanges replaced it with Bird and it is much more stable. -- Grzegorz Janoszka
China prefix hijack
Just half an hour ago China Telecom hijacked one of our prefixes: Your prefix: X.Y.Z.0/19: Prefix Description: NETNAME Update time: 2010-04-08 15:58 (UTC) Detected by #peers: 1 Detected prefix: X.Y.Z.0/19 Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation) Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street) ASpath: 39792 4134 23724 23724 Luckily it had to be limited as only one BGPmon peer saw it. Anyone else noticed it? -- Grzegorz Janoszka
Re: DNS server software
On 22-2-2010 15:39, Phil Regnauld wrote: PowerDNS also has an open source solution (www.powerdns.com). PowerDNS is easily modified with custom backends (using a simple pipe interface). All of the above support DNSSEC. I do not think so: http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software DNSSEC support in PowerDNS is currently restricted to being able to serve DNSSEC-related RRs. No further DNSSEC processing takes place. I have reviewed all popular DNS software recently, PowerDNS was really OK, but eventually I have decided not to go with it due to lack of full DNSSEC support. -- Grzegorz Janoszka
Re: Using /126 for IPv6 router links
On 27-1-2010 2:16, Steve Bertrand wrote: ip address x.x.x.x 255.255.255.252 ipv6 address 2607:F118:x:x::/64 eui-64 ipv6 nd suppress-ra ipv6 ospf 1 area 0.0.0.0 I've found that this setup, in conjunction with iBGP peering between loopback /128's works well. When OSPFv3 goes down and you are trying to debug, what IPv6 will you ping to check if the second side is accessible? -- Grzegorz Janoszka
Re: Using /126 for IPv6 router links
On 26-1-2010 1:33, Owen DeLong wrote: - "Waste" of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections. If you have shared racks with different customers within, you can use 16 or 32 bits out of 64 as customer ID, allowing the customer to use the rest, so in fact giving him trillions (possible) IP's for one server. It can be use with autoconfiguration which always has FF:FE in the middle - you just use some other bits here for your customer assignments. Thus you identify a customer just by looking at the IP address. -- Grzegorz Janoszka
Re: Minimum IPv6 size
Christian Seitz wrote: There ist also a loose and a strict filter recommendation by Gert Doering [1], but the strict filter is very strict at the moment. It allows only /48s from RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also assignes /47 or /46 from this range. Also there should be some deaggregation allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for some reason, because he cannot get a second /32, he should be able to use (eg.) 4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32 prefixes, but I would accept prefixes up to a /36. [1] http://www.space.net/~gert/RIPE/ipv6-filters.html I was thinking about such filters still for v4. Does anyone know if there are any /8's which have no /24 prefixes assigned? I thought about filtering out all deaggregated /24's from such /8's. (I care more about memory of my routers than on a traffic profile of a small company on another continent). Another thing: http://www.db.ripe.net/whois?form_type=simple&full_query_string=&searchtext=193.34.199.0&submit.x=0&submit.y=0&submit=Search This is a normal /25 assigned as PI with route record /25. Are they assigned in any given /8 prefix? If yes, you could easily allow /25's from given /8. -- Grzegorz Janoszka
Re: Redundancy & Summarization
Gaynor, Jonathan wrote: My institution has a single /16 spread across 2 sites: the lower /17 is used at site A, the upper /17 at site B. Sites A & B are connected internally. Currently both sites have their own ISPs and only advertise their own /17's. For redundancy we proposed that each site advertise both their own /17 and the whole /16, so that an ISP failure at either site would trigger traffic from both /17s to reconverge towards the unaffected location. My worry/question: will carriers down the line auto-summarize my advertisements into a single /16, resulting in a 'load sharing' while both sites are active? If you're a backbone carrier and you saw x.x/16 and x.x/17 (or x.x/16 and x.x.128/17) being advertised from the same peer would you drop the longer match? No, BGP does not work this way. But you may force some carriers to have only /16. First, you may try to announce the /17's with the community no-export, so they will be seen only by your direct ISP, not by the rest of the world. Or you may try to use some other communities to limit announcements of your shorter prefixes, only to some part of the world. -- Grzegorz Janoszka
Re: Google Over IPV6
Robert D. Scott wrote: When I posted my original note, I was not really looking for end user feedback, but rather is anyone peering V6 with them on either a public fabric or private peer. Any idea if they have native V6 transit, or are tunneling, and to where. No tuneling I think. We have with them several peerings, IPv6 native together with IPv4. -- Grzegorz Janoszka
Re: Google Over IPV6
Daniel Verlouw wrote: yes. We participate in the Google IPv6 trial program so our recursors get records for www.google.com and so far it's been great, no issues whatsoever. Same experiences - it just works. dan...@jun1> traceroute www.google.com traceroute6 to www.l.google.com (2001:4860:a003::68) from 2001:7f8:1::a501:2859:2, 64 hops max, 12 byte packets 1 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 2.388 ms 1.798 ms 1.712 ms 2 2001:4860::23 (2001:4860::23) 8.664 ms 8.480 ms 8.364 ms 3 2001:4860:a003::68 (2001:4860:a003::68) 8.624 ms 8.639 ms 8.719 ms Yes, but only www records have record, the domain (google.com without www prefix) is still IPv4 only. -- Grzegorz Janoszka
Re: What is the most standard subnet length on internet
Nathan Ward wrote: Let me rephrase; Are there people who are filtering /24s received from eBGP peers who do not have a default route? of course. Curiously, it was really meant as a rhetorical question where the answer was "no". Why are people doing this? Are they lacking clue, or, is there some reasonable purpose? Memory mostly I think. /24 prefixes are ~ the half of all prefixes, but they cover only a small percent of the address space. If your router has > 6 full BGP sessions, you can filter /24 on half of them, your memory usage will drop significantly. -- Grzegorz Janoszka Leaseweb
