Re: MX204 Virtual Chassis Setup
Aaron Gould писал(а) 2023-08-23 12:38: some of these port capabilities are weird to me. like on the ACX7100-48L you can do 4x100 or 8x50, but ONLY one 40g ?! me@7100> show chassis pic pic-slot 0 fpc-slot 0 | find 400 48 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G 49 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G 50 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G 51 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G 52 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G 53 0 1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G 4x10G 3x100G 54 NA 1x10G Probably because 40G is a product 10G lanes. There are only 4 lanes available, and the speed of a single lane can vary. So, 40G is the max speed for the lowest single lane's speed. Kind regards, Andrey
Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?
David Conrad писал(а) 2022-10-12 11:39: Andrey, There was a period in the mid- to late-90s where some of RIRs allocated longer than /24s, i.e., to match the amount of address space justified by the requester, even if that meant (say) a /29. This didn’t last very long as one of the (at the time) 800 lb gorillas (Sprint) decided to start filtering at /19 (which IIRC was the default prefix length RIPE-NCC chose to allocate to LIRs) to keep their routers from falling over. I'm looking at it only from a practical side. I worked for different ISPs in RIPE region in 2000-s and never saw anything like that. There was a requirement from RIPE to create an object for any assigned /29 subnet and larger for IP space usage documentation, but from allocated block. Anyways, even is it's true, it doesn't change anything. There are /24 PI blocks and if /24s are filtered, default route must be in use to have functional Internet connectivity. Thanks, Andrey
Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?
Matthew Petach писал(а) 2022-10-11 20:33: My point is that it's not a feature of BGP, it's a purely human convention, arrived at through the intersection of pain and laziness. There's nothing inherently "right" or "wrong" about where the line was drawn, so for networks to decide that /24 is causing too much pain, and moving the line to /23 is no more "right" or "wong" than drawing the line at /24. A network that *counts* on its non-connected sites being reachable because they're over a mythical /24 limit is no more right than a customer upset that their /25 announcements aren't being listened to. IMO this line wasn't arbitrary, it was (and it still is) a smallest possible network size allocated by RIRs. So it's just a common sense to receive everything down to /24 to have the complete data about all Internet participants. -- Kind regards, Andrey
Re: Assumptions about network designs...
This is actually not the case. Cable service in some regional areas was restored as late as on Monday and even in the same geographical area there was a partial connectivity, so it looks less probable that network could be overloaded only in some isolated segments longer than the rest of the network and require manual intervention to fix it. OTOH, overloading network core of such big network should be hardly possible. Possible route "poisoning" could be isolated, so that it doesn't affect the whole network cost to cost. It must be very unlucky coincidence of such event to happen on such big scale. Maybe caused by HW or SW bug. I'm talking just about probabilities of different scenarios and trying to compare them. So far, IMO provided version doesn't look very convincing. Kind regards, Andrey Kostin sro...@ronan-online.com писал(а) 2022-07-11 20:18: I’m “guessing” based on all the services that were impacted the outage was likely cause by a change that caused a routing change in their multi-service network which overloaded many network devices, and by isolating the source the routes or traffic the rest of the network was able to recover. But just a guess. Shane
Re: Rogers Outage Canada
It's hard to believe that a same time maintenance affecting so many devices in the core network could be approved. Core networks are build with redundancy, so that failures can't completely destroy the whole network. If it would be just "particular devices" they could be isolated much faster. In this case the outage was so huge that it affected mostly all network gear, maybe all devices from one vendor. And even after most of the services restored we still observed partial connectivity in some areas that means the impact was mush deeper, in some places down to access layer. Kind regards, Andrey Shane Ronan писал(а) 2022-07-11 10:09: What in depth analysis have you seen? Seems to me, this was a failure in a known maintenance activity, and they simply disconnected the devices under maintenance from the network. Shane
Re: A few questions regarding about RPKI/invalids
Seeing this prefix with exactly same path coming from Zayo. My path is 6461 3356 3549 11172 270150 I Kind regards, Andrey Drew Weaver писал(а) 2022-03-30 09:29: Hello, We've noticed that there are a number of routes being passed along from 3356 with invalid origin AS. Of those, almost all of them are being passed to 3356 from 3549 (legacy Global Crossing) and there is no valid path available for any of these prefixes (at least according to the ROA). Ex 45.176.191.0/24 3356 3549 11172 270150 RPKI ROA entry for 45.176.191.0/24-24 Origin-AS: 265621 Two questions: First, are you also seeing this on this specific route? Second, is there a certain number of "expected" invalid routes? (not including unknowns) Third, how are you handling specifically the large number of routes from 3356 3549 which invalid origin AS? Are you just "letting the bodies hit the floor"? or are you carving those out somehow? I'm mostly just curious what other members of the community are seeing/doing in regards to this. Thanks, -Drew
Re: Famous operational issues
Jen Linkova писал 2021-02-19 00:04: OK, Warren, achievement unlocked. You've just made a network engineer to google 'router' He meant that we call "frezer" machine... (in our language ;) I heard a similar story from my colleague who was working at that time for Huawei as DWDM engineer and had to fly frequently with testing devices. One time he tried to explain at airport security control what DWDM spectrum analyser is for, the officer called another for help and he said something like this: "DWDM spectrum analyser? Pass it, usual thing..." -- Kind regards, Andrey Kostin
Re: SRv6
aar...@gvtc.com писал 2020-09-15 20:31: Hi Aaron, Also, with VPN's over SRv6 would this enable automatic vpn capability over the internet? I mean if I can do VPN's over an IPv6 network, seems that I could do that across the Internet as well. I think you already can do it over any kind of tunnel, and there are a lot of SDWAN solutions are available. Or do you expect from a transit provider a capability to respect and process SID stack programmed by another provider? I wouldn't bet on this ;) From administrative PoV it's similar to Inter-AS or CsC, based on trusted relations between parties, but seems not very popular in real life. Otherwise, it will be the same best path routing as for any general tunnel. Doesn't look as a distinctive advantage of SRv6 at least. - Aaron -- Kind regards, Andrey
Re: [c-nsp] LDPv6 Census Check
Saku Ytti писал 2020-06-12 12:10: On Fri, 12 Jun 2020 at 18:52, David Sinn wrote: Unless you want ECMP then it VERY much matters. But I guess since we are only talking about theoretical instead of building an actual practical network, it doesn't matter. Well blatantly we are, because in the real world most of the value of MPLS tunnels is not available as IP tunnels. Again technically entirely possible to replace MPLS tunnels with IP tunnels, just question how much overhead you have in transporting the tunnel key and how wide they are. Should we design a rational cost-efficient solution, we should choose the lowest overhead and narrowest working keys. Sorry for jumping in in the mddle of discussion, as a side note, in case of IPIP tunneling, shouldn't another protocol type be utilized in MAC header? As I understand, in VXLAN VTEP ip is dedicated for this purpose, so receiving a packet with VTEP DST IP already means "decapsulate and lookup the next header". But in traditional routers loopback IPs are used for multiple purposes and usually receiving a packet with lo0 IP means punt it to control plane. Isn't additional differentiator is needed here to tell a router which type of action it has to do? Or, as alternative, if dedicated stack of IPs is used for tunneling, then another lookup table is needed for it, isn't it? And now looks like we are coming to the header structure and forwarding process similar that we already have in MPLS, only with different label format. Please correct me if I went off track somewhere in this logical chain. To David's point about ECMP I'd like to mention that in WAN networks number of diverse paths is always limited, so having multiple links taking same path doesn't make much sense. With current economics 4x10G and 1x100G are usually close from price POV. Obviously, there are different situations when multiple links are the only option, but how many, usually 4-8. Sure if you need multiple 400G then there is currently no option to go to higher speeds, but that's more DC use case than WAN network. So ECMP in WAN network isn't that big scale problem imho, also there are existing and proposed solutions, like SR, for it. Kind regards, Andrey
Re: Abuse Desks
Maybe there is a market opportunity there? Develop reporting standard (or use one that was posted here), then develop reporting, processing and analytic tools, and then provide it as a service? Looks like a nice use case how to utilise clouds ;) Kind regards, Andrey Mike Hammett писал 2020-04-30 08:10: I did not want to target anyone in particular, so I have responded to my original e-mail. I have seen comments about the big guys just ignoring everything. I have had a non-zero number of e-mails from each of Azure, GCP, AWS, and Hetzner claiming that they have acted on my report. It isn't a significant percentage, but they're doing something about some of the reports. I don't think I've seen anything back from the biggest offender, Digital Ocean, other than auto-responders acknowledging the report. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com
Re: "Is BGP safe yet?" test
Vincent Bernat писал 2020-04-22 15:26: ❦ 22 avril 2020 12:51 -04, Andrey Kostin: BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes received from peer-as to make ingress filtering more dynamic and move away prefix filters from the routers? It could be used as is if the client implementations were a bit more flexible. With BIRD, you decide which AS to match. So you can match on the neighbor AS instead of the origin AS. Then, you can use something like GoRTR which accepts using JSON files instead of the RPKI as source. BIRD also allows you to have several ROA tables. So, you can check against the "real" RPKI as well as against your custom IRR-based RPKI. That's what I meant. So I guess IX operators already can use BIRD on route-servers for prefix filtering. I think it could be useful on hw routers as well. Kind regards, Andrey
Re: "Is BGP safe yet?" test
Christopher Morrow писал 2020-04-22 14:05: a question about the data types here... So, a neighbor with no downstream ASN could be filtered directly with ROA == prefixlist-content. A neighbor with a downstream ASN has to be ROA (per asn downstream) == prefixlist-content. So you'd now have to do some calculations which are more complicated than just; "is roa for this prefix here and valid" to construct a prefix-list. correct? Sorry, and this sidesteps the intent of the peer as well. For instance you may have a peer with 2 'downstream' asn, only 1 of which they wish to provide transit to you (from you?) for... how would you know this intent/policy from the peer's perspective? today you know that (most likely) from IRR data. is your answer ASPA / AS-Cone ? ASPA/As-Cone is a concept about whole as-path verification afaik, but I may be mistaken. ROA validation prevents hijacking but doesn't prevent route-leaks. If my transit providers already do ROV, effect of doing it in local network will be limited to direct peers only and expected to be considerably small. For route-leaks prevention we still have to rely on IRR and filters configured directly on routers. Maintaining filters on routers is quite intensive task and they took a lot of space in the configuration. Adopting validation or similar mechanism for it could make it more dynamic and less resources-consuming. Or maybe I'm trying to invent a bicycle? Kind regards, Andrey
Re: "Is BGP safe yet?" test
Jay R. Ashworth писал 2020-04-22 11:02: Well, given how little the BCP38 website below has moved that football, you're not likely in much danger... :-) Cheers, -- jra BCP38 website doesn't proclaim anybody in person to be unsafe, but if it would be possible to make such test it'd be more useful than that RPKI test. BTW, has anybody yet thought/looked into extending RPKI-RTR protocol for validation of prefixes received from peer-as to make ingress filtering more dynamic and move away prefix filters from the routers? Kind regards, Andrey
Re: "Is BGP safe yet?" test
Baldur Norddahl писал 2020-04-21 02:49: My company is in Europe. Lets say an attacker joins the IX in Seattle a long way from here and a place we definitely are not present at. We do however use Hurricane Electric as transit and they are peering freely at Seattle. Everyone there thus sees our prefix with an as path length of two. The attacker can originate the prefixes himself and that way his fake announcements win at Seattle by having the length 1. With RPKI he needs to use our ASN to originate and have his own ASN in between to facilitate peering. Thus the fake path also has the length of two. The real announcement wins by virtue of being the oldest announcement and the attack fails. The situation is even worse for the attacker if he needs an IP transit company to pick up the fake announcement. We have Telia, which filters invalids, and if the attacker tries to get his fake prefix picked up by them, his path will end up being one longer than ours, so he can never succeed. There are of course plenty of situations where the attack still succeeds. I am not claiming this is a magical bullet. Just saying it might do more than some thinks it will. Definitely better than nothing. I think that for peering sessions regular filters can do their job more directly and effectively. But I see that discussion moved away from initial topic to general dispute about RPKI usefullness. The initial topic though initially was about public web page that claimes your network secure or insecure based on evaluation of only one technology checking one particular specially crafted prefix. Kind regards, Andrey
Re: "Is BGP safe yet?" test
Denys Fedoryshchenko писал 2020-04-20 15:27: And most important, the most common answer: All Tier-1 implemented it? No. Major hosting operators, such as AWS, gcloud, etc? - No. So... Absolutely, RPKI has different scale of effectiveness and benefits for big telecoms or clouds vs small ISPs or datacenters. On the other hand, the impact of such "BGP safety" test is completely the opposite. For big guys it is the most effective to implement, but being "not BGP safe yet" - "yeah, who cares!" or in best case add to the plan for the next fiscal year. But for small market players it's vise-versa: effect of filtering is minimal but pressure from "not being safe" may be very real. Kind regards, Andrey
Re: "Is BGP safe yet?" test
Mark Tinka писал 2020-04-20 12:57: On 20/Apr/20 18:50, Tom Beecher wrote: I (and Ben, and a few others) are all too familiar with the ARIN madness around their TAL. Simple - we just don't accept it, which means our networks will be unsafe against North American resources. Highly doubtful my organization is that interested in how the ARIN region may or may not impact our interest in deploying RPKI on this side of the planet, when the rest of the world are less mad about it :-). So this means that there is no single source of truth for PRKI implementation all around the world and there are different shades, right? As a logical conclusion, the information provided on that page may be considered incorrect in terms of proclaiming particular network safe or not safe, but when it's claimed (sometimes blatantly) we now have to prove to our clients that we are not bad guys. Kind regards, Andrey
Re: "Is BGP safe yet?" test
Thank you Mark, Tom and Chris for your responses that confirmed my "mixed feelings" about this tool. As a side note, I mentioned from https://bgp.he.net/AS13335#_prefixes that AS13335 advertises a bunch or prefixes without RoA and even one invalid prefix, although I don't see it (only invalid one) from other sources. So it looks like an attempt to jump ahead and announce competitive leadership using marketing rather than technology. So for myself with your help I'd qualify it as aggressive push from technical PoV and offensive from marketing PoV. The former definitely has some positive effect which however could or could not be outweighted by the latter. Kind regards, Andrey Tom Beecher писал 2020-04-20 12:24: Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space. I believe that will change the calculus and make it a more difficult sell for technical people to get resources approved to make it happen. On Mon, Apr 20, 2020 at 11:38 AM Cummings, Chris wrote: Why do you think that RPKI adoption will be slowed due to this action by CloudFlare? — Chris Cummings FROM: NANOG on behalf of Tom Beecher DATE: Monday, April 20, 2020 at 10:35 TO: Andrey Kostin CC: Nanog SUBJECT: Re: "Is BGP safe yet?" test ( Speaking 100% for myself. ) I think it was tremendously irresponsible, especially in the context of current events, to take a complex technical issue like this and frame it to the general public as a 'safety' issue. It's created articles like this : https://www.wired.com/story/cloudflare-bgp-routing-safe-yet/ , which are terrible because they imply that RPKI is just some simple thing that anyone not doing is just lazy or stupid. Very few people will read to the bottom note about vendors implementing RPKI support, or do any other research on the issue and challenges that some companies face to do it. It's not their job; that's ours. I feel like there has been more momentum in getting more people to implement PKI in the last 18-24 months. ( Maybe others with different visibility have different opinions there. ) There are legitimate technical and business reasons why this isn't just a switch that can be turned on, and everyone in our industry knows that. In my opinion, Mr. Prince is doing a great disservice by taking this approach, and in the longer term RPKI adoption will likely be slower than it would have been otherwise. I genuinely appreciate much of what Cloudflare does for the sake of 'internet good' , but I believe they wildly missed the mark here.
Re: EVPN multicast route (multi home case ) implementation / deployment information
Hi Mankamana, For Juniper: Starting in Junos OS 18.4R1, devices with IGMP snooping enabled use selective multicast forwarding in a centrally routed EVPN-VXLAN network to replicate and forward multicast traffic. As before, IGMP snooping allows the leaf device to send multicast traffic only to the access interface with an interested receiver. But now, when IGMP snooping is enabled, the leaf device selectively sends multicast traffic to only the leaf devices in the core that have expressed an interest in that multicast group. In selective multicast forwarding, leaf devices always send multicast traffic to the spine device so that it can route inter-VLAN multicast traffic through its IRB interface. https://www.juniper.net/documentation/en_US/junos/topics/concept/evpn-selective-multicast-forwarding.html Kind regards, Andrey Mankamana Mishra (mankamis) via NANOG писал 2020-02-03 18:34: Folks Wondering if there is any known implementation of EVPN multihome multicast routes which are defined in https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04 there is some change planned in NLRI , we want to make sure to have solution which does work well with existing implementation. NOTE: Discussion INVOLVES NOKIA, JUNIPER, CISCO, ARISTA ALREADY. SO LOOKING FOR ANY OTHER VENDOR WHO HAVE IMPLEMENTATION. Mankamana
Re: 5G roadblock: labor
Paul Nash писал 2020-01-06 18:45: Depending on what you are after, folk like Ruckus and Cisco have had centrally-managed enterprise WiFi for many years. I manage a Ruckus installation for an apartment building where there is one SSID from about 150 APs, users have a unique password per apartment, which lands them onto that apartment’s VLAN, regardless of where they are in the building. Works really well. I'm had some aquintance with this technology and participated once in WiFi network rollout on a relatively big stadium. All these wifi controllers have their limits that in my understanding are significantly lower than mobile networks. You can cover one building or campus, but how about the next building on the street? It it's owner has a different system it may be difficult to connect them even aside of bureaucratic reasons. The main asset of wireless networks is their infrastructure and coverage that they were building from 90-s. If you have the network that covers a large area you can deploy any technology that fits in it. Definitely people from mobile networks have their own way of thinking as well as transport and telephony engineers but if wifi could satisfy all the requirements they would probably be deploying it. Do you remember Wimax? At that time it was better for data then mobile networks but probably demand for data services wasn't big enough at that time and then new specs were developed that partially used existing mobile technologies. I'm not a protagonist of mobile networks as I'm working in fixed networks field, but you can't ignore the fact that at the moment they have widest coverage, not the best everywhere but the most unversal service, non-elastic demand and the best prospective for future growth. Kind regards, Andrey
Re: 5G roadblock: labor
Sabri Berisha писал 2020-01-06 16:21: - On Jan 5, 2020, at 10:07 PM, Mark Tinka mark.ti...@seacom.mu wrote: I predict that your in-flight wifi will become a lot cheaper as a result of this. Thanks, Sabri On Lufthansa flights unlimited Internet access is 12 Euro, and 3 Euro is for "checking email". Don't think it's going to be cheaper, but higher speed - yes, definitely. Kind regards, Andrey
Re: 5G roadblock: labor
Mark Tinka писал 2020-01-04 00:43: On 4/Jan/20 00:26, Andrey Kostin wrote: Could be true very soon. When supporting cable infrastructure will become too expensive they will cut it in lieu of mobile, like many railways were decomissioned earlier. Must be a local tipping point in each area but it shouldn't be long to wait. Ummh, and what technology do you think is running the base stations that are transmitting at 6G, 7G? Mark. I'm talking only about last mile access. Wireless is going the same path as fixed access before: from big central facilities to end-user as much close as provided services bring enough revenue to cover upgrade costs and create some profit. With copper phone lines the situation has already turned backward because revenue from services isn't sufficient. We all know physics and Shennon/Kotelnikov theorema. To get more speed more spectrum is needed but more spectrum is available in higher frequencies, that have shorter coverage. Where it's going to stop - I don't know, 6G or 7G or XG ;) Only making enough money is needed to go to the next G. Regarding comparison WiFi and cellular networks, it's clear that WiFi won't be able to compete with mobile in terms of scalability. Building WiFi in public places like stadiums is already became a job specialization, but every such implementation has it's limit. On the other hand, 5G as I can see is a big step in this direction in terms of spectrum and subscribers management. Mobile networks are developed for central control of all the components on all layers, that's why mobile standards contain thousands pages. WiFi is a technology for local access and to make it more scalable means to go through the same development process as mobile networks did. Something can probably be improved but even if it succeed it won't be cheap anymore. Currently WiFi is only describes single layer of connectivity, and this is why it's cheap, but on the next layer (i.e. IPv6 implementation) we can see incompatibility between "standardised" WiFi devices. Compatibility on many layers is necessary to orchestrate all of them, so not going to happen. Yes, WiFi and mobile can be compared in radio, but not in anything else. Kind regards, Andrey
Re: 5G roadblock: labor
John D'Ambrosia писал 2020-01-05 07:48: Sabri At the very end you note 100base-t as a precursor to 400g. 100baset really found its success as an access solution - computer connections. 400GbE will be an aggregation / core solution. It will be some time if ever where 400GbE is used as an access solution - perhaps some hpc applications. I used to work in the company that used to be a one of ISP pioneers in Russia. There was an anecdotic situation back in 1993 when they brought up a new E3 link to Finland but didn't change reverse DNS records for IPs. When a customer called support and asked "Why do I see hops with 'dialup' in the path, are you connecting to Internet by dialup connection?", support replied: "May be it's our future to have 34Mbps on dialup connection". So, who knows ;) Kind regards, Andrey
Re: 5G roadblock: labor
Sabri Berisha писал 2020-01-03 16:53: I predict that there will be a time where, just like POTS lines were exchanged for cellular phones, people will disconnect their cable internet and rely on 6g or 7g alone. And probably still with IPv4 addresses. Could be true very soon. When supporting cable infrastructure will become too expensive they will cut it in lieu of mobile, like many railways were decomissioned earlier. Must be a local tipping point in each area but it shouldn't be long to wait. Kind regards, Andrey
Re: 5G roadblock: labor
Mark Tinka писал 2020-01-03 04:36: And more interestingly, if that city's residents and visitors had the option of connecting to active 5G or wi-fi, what do we think they'd choose? Currently /me don't bother switching to wifi in public places bcz LTE provides enough bw for my humble needs. And when the next phone will be released with 4k 120fps camera and 4k display there will be a lot of people (not only kids) who will use it and abuse it all the time for gaming, streaming ,etc. It's not about competition with WiFi, it's just a new thing that is coming. But 5G will take away it's share of fixed users for sure. When first iphone was released it was pretty much useless toy because all apps were bound to Internet and cell networks were you know where at that time with public WiFi only starting to take off. But now we can't live without services which are novadays considered as basic and then were fancy technology break-outs for geeks. Kind regards, Andrey
Deutsche Telecom AS3320 contact
Hi NANOG, Looking for a contact from AS3320 Deutsche Telekom to ask a question about their routing policy/filtering causing that some globally routed prefixes aren't seen in AS3320. Kind regards, Andrey Kostin
