Re: Best TAC Services from Equipment Vendors

2024-03-20 Thread Mark Tinka
Ultimately, I think every vendor will have customers with good experiences, and customers with not-so-good experiences. Without sufficient data, it is hard to say which vendor, in general, does a good job for their customer base re: TAC. What I will say, albeit anecdotally also, is that TAC

Re: XGS-PON & "Dedicated" Service

2023-10-24 Thread Mark Tinka
On 10/25/23 01:56, Neader, Brent wrote: Hello! Interested in getting the larger community’s thought on this. The primary question being does XGS-PON have a place in providing a dedicated enterprise level service (at least sold as one) in the marketplace?  Delivered via a residential (per

Re: RPKI unknown for superprefixes of existing ROA ?

2023-10-21 Thread Mark Tinka
On 10/21/23 16:03, Amir Herzberg wrote: Hi Owen, Randy, Job and other NANOGers, I surely agree with you all that we shouldn't expect discarding of ROA-unknown `anytime soon' (or ever?). But I have a question: what about discarding ROA-unknowns for very large prefixes (say, /12), or for

Re: Low to Mid Range DWDM Platforms

2023-10-20 Thread Mark Tinka
On 10/19/23 22:24, Chad Lamb via NANOG wrote: XKL is still here ... Some caveats on 400G ZR/ZR+ devices: - They are power hungry, cooling is a challenge.  800G even more so.  The OSFP package for 800G looks like the better choice than QSFP-DD for this reason.  We'll see, we need more

Re: MX204 tunnel services BW

2023-10-16 Thread Mark Tinka
On 10/17/23 03:20, Ryan Kozak wrote: "The MX204 router supports two inline tunnels - one per PIC. To configure the tunnel interfaces, include the tunnel-services statement and an optional bandwidth of 1 Gbps through 200 Gbps at the \[edit chassis fpc fpc-slot pic number\] hierarchy

Re: MX204 tunnel services BW

2023-10-16 Thread Mark Tinka
On 10/16/23 21:49, Jeff Behrns via NANOG wrote: Also leaving tunnel-services bandwidth unspecified is not possible on the 204. This is true of other MX platforms as well, unless I misunderstand. Mark.

APRICOT 2024: Call for Presentations

2023-10-10 Thread Mark Tinka
questions or concerns should be addressed to the Programme Committee Chairs by e-mail at:     pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka, Achie Atienza & Mark Duffell APRICOT 2024 Programme Committee Chairs --

Re: FastNetMon Usage in the wild

2023-10-10 Thread Mark Tinka
On 10/11/23 04:34, Dobbins, Roland via NANOG wrote: To clarify, Sightline has supported virtualization for many years, FYI. It does do, yes. But pricing for the software license is not too far off from if you chose to buy Netscout's own hardware. Not a major drama for me - I appreciate

Re: Low to Mid Range DWDM Platforms

2023-10-07 Thread Mark Tinka
Finally, the name came to me :-): https://www.xkl.com/ Looks like they are still in business. Mark. On 10/6/23 16:02, Mark Tinka wrote: On 10/6/23 15:52, Dave Bell wrote: Smartoptics? https://smartoptics.com/ Not them. I want to say they had an "X" in their name, but memor

Re: maximum ipv4 bgp prefix length of /24 ?

2023-10-07 Thread Mark Tinka
On 10/7/23 14:32, Willy Manga wrote: How about we educate each other to not assume you must deaggregate your prefix especially with IPv6? I see 'some' (it's highly relative) networks on IPv4, they 'believe' they have to advertise every single /24 they have. And when they start with IPv6,

Re: Low to Mid Range DWDM Platforms

2023-10-06 Thread Mark Tinka
On 10/6/23 15:53, Dave Cohen wrote: My experience is primarily with the traditional carrier-grade folks like Ciena, Infinera, etc. but over the last decade all of those vendors have focused on improving how they scale down without sacrificing (most of the) quality and functionality - to

Re: Low to Mid Range DWDM Platforms

2023-10-06 Thread Mark Tinka
On 10/6/23 15:52, Dave Bell wrote: Smartoptics? https://smartoptics.com/ Not them. I want to say they had an "X" in their name, but memory is fuzzy. Mark.

Re: Low to Mid Range DWDM Platforms

2023-10-06 Thread Mark Tinka
On 10/6/23 15:07, Mike Hammett wrote: I've been using various forms of passive WDM for years. I have a couple different projects on my plate that require me to look at the next level of platform. In some projects, I'll be looking for needing to have someone long distances of glass

APRICOT 2024: Call for Programme Committee Volunteers

2023-10-05 Thread Mark Tinka
nd a brief description about why you would make a good addition to the PC. The PC Chairs will accept nominations received by 17:00 UTC+8 on Friday 20th October 2023, and will announce the new PC shortly thereafter. Many thanks! Mark Tinka & Mark Duffell For the APRICOT 2024 Organising Committee --

Re: maximum ipv4 bgp prefix length of /24 ?

2023-10-05 Thread Mark Tinka
On 10/5/23 08:32, Geoff Huston wrote: Not really. The stability of number in IPv4 as compared to the monotonic rise in IPv6 is what I find to be curious. I think the fact that RIR's allocate very large IPv6 address space to their members may well be what is driving this. Historically,

Re: maximum ipv4 bgp prefix length of /24 ?

2023-10-05 Thread Mark Tinka
On 10/5/23 08:24, Geoff Huston wrote: The IPv6 FIB is under the same pressure from more specifics. Its taken 20 years to get there, but the IPv6 FIB is now looking stable at 60% opf the total FIB size [2]. For me, thats a very surprising outcome in an essentially unmanaged system. Were

Re: maximum ipv4 bgp prefix length of /24 ?

2023-10-05 Thread Mark Tinka
On 10/5/23 07:49, Crist Clark wrote: But if the assumption is that networks will always eventually totally deaggregate to the maximum, we're screwed. Routing IPv4 /32s would be nothing. The current practice of accepting /48s could swell to about 2^(48 - 3) = 2^45 = 35184372088832. What

Re: maximum ipv4 bgp prefix length of /24 ?

2023-10-04 Thread Mark Tinka
On 10/4/23 09:27, Elmar K. Bins wrote: Justin, I'm not sure you're not confusing scope here. Everybody and their sister accept smaller blocks from their customers; we're all talking about the DFZ here, not customer routes that you aggregate. Actually, we don't. From our customers, the

Re: maximum ipv4 bgp prefix length of /24 ?

2023-10-04 Thread Mark Tinka
On 10/4/23 12:11, Musa Stephen Honlue wrote: Which one is easier, 1. Convincing the tens of thousands of network operators and equipment vendors to modify configs and code to accept more specifics than /24, or Equipment vendors can already support 10 million entries in FIB. They just

Re: cogent spamming directly from ARIN records?

2023-10-02 Thread Mark Tinka
On 10/2/23 22:59, Matthew Petach wrote: Huh? In all my decades of time in the network industry, I have never seen a case where a smaller transit contract had lower per mbit cost than a larger volume contract. I would expect that HE would make *more* money off 10 smaller customer

Re: maximum ipv4 bgp prefix length of /24 ?

2023-10-02 Thread Mark Tinka
On 10/2/23 20:44, Tim Franklin wrote: Had NOT considered the looping - that's what you get for writing in public without thinking it all the way through *blush*. Thanks for poking holes appropriately, Like I said, it's going to be a messy experiment - for probably a decade, at least.

Re: cogent spamming directly from ARIN records?

2023-10-02 Thread Mark Tinka
On 10/2/23 20:58, Tim Burke wrote: Hurricane has been doing the same thing lately... but their schtick is to say that "we are seeing a significant amount of hops in your AS path and wanted to know if you are open to resolve this issue". I get what HE are trying to do here, as I am sure

Re: maximum ipv4 bgp prefix length of /24 ?

2023-09-30 Thread Mark Tinka
On 9/30/23 01:36, William Herrin wrote: If I were designing the product, I'd size the SRAM with that in mind. I'd also keep two full copies of the FIB in the outer DRAM so that the PPEs could locklessly access the active one while the standby one gets updated with changes from the RIB. But

Re: maximum ipv4 bgp prefix length of /24 ?

2023-09-30 Thread Mark Tinka
On 9/29/23 22:56, William Herrin wrote: Actually, BGP can swing that. Routing involves two distinct components: the routing information base (RIB) and the forwarding information base (FIB). BGP is part of the RIB portion of that process. It's always implemented in software (no hardware

Re: maximum ipv4 bgp prefix length of /24 ?

2023-09-30 Thread Mark Tinka
On 9/29/23 06:43, VOLKAN SALİH wrote: But when everybody upgrades, memory and processor unit prices decrease.. Vendors gain from demand. I am yet to see that trend... Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

2023-09-29 Thread Mark Tinka
On 9/28/23 23:25, VOLKAN SALİH wrote: hello, I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24.. I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 address. considering IPv4 world is now mostly

Re: TACACS+ server recommendations?

2023-09-20 Thread Mark Tinka
On 9/20/23 17:39, Jeff Moore wrote: We have also used https://www.shrubbery.net/tac_plus/ for some time as well. Great product! Yes, that's one of the ones in the FreeBSD ports. Works very well. Mark.

Re: TACACS+ server recommendations?

2023-09-20 Thread Mark Tinka
On 9/20/23 17:09, Bryan Holloway wrote: Ah, the good old days when I could download the latest tac_plus code from the Cisco FTP site, compile it, and off I go. But I digress. Curious if there are any operators out there that have a good recommendation on a lightweight TACACS+ server for

Re: Zayo woes

2023-09-20 Thread Mark Tinka
On 9/19/23 18:05, Mike Hammett wrote: Some of it is scale-related. Someone's operating just fine at the size they are, but the next order of magnitude larger enjoys many benefits from that size, but it takes either A) luck or B) the right skills to be able to move up to get those benefits.

Re: Zayo woes

2023-09-20 Thread Mark Tinka
On 9/19/23 17:54, Mike Hammett wrote: Well sure, and I would like to think (probably mistakenly) that just no one important enough (to the money people) made the money people that these other things are *REQUIRED* to make the deal work. Obviously, people lower on the ladder say it all of

Re: Zayo woes

2023-09-19 Thread Mark Tinka
On 9/19/23 17:40, Anne Mitchell wrote: And sometimes the acquisition is really just about acquiring the assets, such as the customer list*, and then they are left with having to run something that they never really wanted until they can figure out what to do with it. Right, buying the

Re: Zayo woes

2023-09-19 Thread Mark Tinka
On 9/19/23 16:48, Mike Hammett wrote: As someone that has been planning to be in the acquiring seat for a while (but yet to do one), I've consistently passed to the money people that there's the purchase price and then there's the % on top of that for equipment, contractors, etc. to

Re: Zayo woes

2023-09-19 Thread Mark Tinka
On 9/19/23 16:41, Matthew Petach wrote: c) your executives have promised there will be cost savings after the merger due to "synergies" between the two companies. Couldn't have said the exact same words any better myself - "cost savings from synergies" :-). Always interesting when a year

Re: Zayo woes

2023-09-19 Thread Mark Tinka
On 9/19/23 14:19, Mike Hammett wrote: I've never understood companies that acquire and don't completely integrate as quickly as they can. Sometimes it does not add any material value to either network. Sometimes it takes too long. If the acquired company is orders of magnitude smaller

Re: Lossy cogent p2p experiences?

2023-09-09 Thread Mark Tinka
On 9/9/23 22:29, Dave Cohen wrote: At a previous $dayjob at a Tier 1, we would only support LAG for a customer L2/3 service if the ports were on the same card. The response we gave if customers pushed back was "we don't consider LAG a form of circuit protection, so we're not going to

Re: Lossy cogent p2p experiences?

2023-09-09 Thread Mark Tinka
On 9/9/23 20:44, Randy Bush wrote: i am going to be foolish and comment, as i have not seen this raised if i am running a lag, i can not resist adding a bit of resilience by having it spread across line cards. surprise! line cards from vendor do not have uniform hashing or rotating

Re: Lossy cogent p2p experiences?

2023-09-08 Thread Mark Tinka
On 9/7/23 09:51, Saku Ytti wrote: Perhaps if congestion control used latency or FEC instead of loss, we could tolerate reordering while not underperforming under loss, but I'm sure in decades following that decision we'd learn new ways how we don't understand any of this. Isn't this partly

Re: Lossy cogent p2p experiences?

2023-09-08 Thread Mark Tinka
On 9/7/23 09:31, Benny Lyne Amorsen wrote: Unfortunately that is not strict round-robin load balancing. Oh? What is it then, if it's not spraying successive packets across member links? I do not know about any equipment that offers actual round-robin load-balancing. Cisco had both

Re: Lossy cogent p2p experiences?

2023-09-06 Thread Mark Tinka
On 9/6/23 18:52, Tom Beecher wrote: Well, not exactly the same thing. (But it's my mistake, I was referring to L3 balancing, not L2 interface stuff.) Fair enough. load-balance per-packet will cause massive reordering, because it's random spray , caring about nothing except equal loading

Re: Lossy cogent p2p experiences?

2023-09-06 Thread Mark Tinka
On 9/6/23 12:01, Saku Ytti wrote: Fun fact about the real world, devices do not internally guarantee order. That is, even if you have identical latency links, 0 congestion, order is not guaranteed between packet1 coming from interfaceI1 and packet2 coming from interfaceI2, which packet first

Re: Lossy cogent p2p experiences?

2023-09-06 Thread Mark Tinka
On 9/6/23 11:20, Benny Lyne Amorsen wrote: TCP looks quite different in 2023 than it did in 1998. It should handle packet reordering quite gracefully; in the best case the NIC will reassemble the out-of-order TCP packets into a 64k packet and the OS will never even know they were reordered.

Re: Lossy cogent p2p experiences?

2023-09-06 Thread Mark Tinka
On 9/6/23 17:27, Tom Beecher wrote: At least on MX, what Juniper calls 'per-packet' is really 'per-flow'. Unless you specifically configure true "per-packet" on your LAG:     set interfaces ae2 aggregated-ether-options load-balance per-packet I ran per-packet on a Juniper LAG 10 years

Re: Lossy cogent p2p experiences?

2023-09-06 Thread Mark Tinka
On 9/6/23 16:14, Saku Ytti wrote: For example Juniper offers true per-packet, I think mostly used in high performance computing. Cisco did it too with CEF supporting "ip load-sharing per-packet" at the interface level. I am not sure this is still supported on modern code/boxes. Mark.

Re: Lossy cogent p2p experiences?

2023-09-06 Thread Mark Tinka
On 9/6/23 09:12, Masataka Ohta wrote: you now recognize that per-flow load balancing is not a very good idea. You keep moving the goal posts. Stay on-topic. I was asking you to clarify your post as to whether you were speaking of per-flow or per-packet load balancing. You did not do

Re: Lossy cogent p2p experiences?

2023-09-06 Thread Mark Tinka
On 9/4/23 13:27, Nick Hilliard wrote: this is an excellent example of what we're not talking about in this thread. It is amusing how he tried to pivot the discussion. Nobody was talking about how lane transport in optical modules works. Mark.

Re: Lossy cogent p2p experiences?

2023-09-06 Thread Mark Tinka
On 9/4/23 13:04, Masataka Ohta wrote: Are you saying you thought a 100G Ethernet link actually consisting of 4 parallel 25G links, which is an example of "equal speed multi parallel point to point links", were relying on hashing? No... you are saying that. Mark.

Re: Lossy cogent p2p experiences?

2023-09-03 Thread Mark Tinka
On 9/3/23 15:01, Masataka Ohta wrote: Why, do you think, you can rely on existence of flows? You have not quite answered my question - but I will assume you are in favour of per-packet load balancing. I have deployed per-packet load balancing before, ironically, trying to deal with

Re: Lossy cogent p2p experiences?

2023-09-03 Thread Mark Tinka
On 9/3/23 15:01, Masataka Ohta wrote: Why, do you think, you can rely on existence of flows? You have not quite answered my question - but I will assume you are in favour of per-packet load balancing. I have deployed per-packet load balancing before, ironically, trying to deal with

Re: Lossy cogent p2p experiences?

2023-09-03 Thread Mark Tinka
On 9/3/23 09:59, Masataka Ohta wrote: If you have multiple parallel links over which many slow TCP connections are running, which should be your assumption, the proper thing to do is to use the links with round robin fashion without hashing. Without buffer bloat, packet reordering

Re: Lossy cogent p2p experiences?

2023-09-02 Thread Mark Tinka
On 9/2/23 17:38, Masataka Ohta wrote: Wrong. It can be performed only at the edges by policing total incoming traffic without detecting flows. I am not talking about policing in the core, I am talking about detection in the core. Policing at the edge is pretty standard. You can police a

Re: Lossy cogent p2p experiences?

2023-09-02 Thread Mark Tinka
On 9/2/23 17:04, Masataka Ohta wrote: Both of you are totally wrong, because the proper thing to do here is to police, if *ANY*, based on total traffic without detecting any flow. I don't think it's as much an issue of flow detection as it is the core's ability to balance the Layer 2

Re: Lossy cogent p2p experiences?

2023-09-02 Thread Mark Tinka
On 9/2/23 08:43, Saku Ytti wrote: What in particular are you missing? As I explained, PTX/MX both allow for example speculating on transit pseudowires having CW on them. Which is non-default and requires 'zero-control-word'. You should be looking at 'hash-key' on PTX and 'enhanced-hash-key'

Re: Lossy cogent p2p experiences?

2023-09-01 Thread Mark Tinka
On 9/1/23 21:52, Mike Hammett wrote: It doesn't help the OP at all, but this is why (thus far, anyway), I overwhelmingly prefer wavelength transport to anything switched. Can't have over-subscription or congestion issues on a wavelength. Large IP/MPLS operators insist on optical transport

Re: Lossy cogent p2p experiences?

2023-09-01 Thread Mark Tinka
On 9/1/23 15:55, Saku Ytti wrote: Personally I would recommend turning off LSR payload heuristics, because there is no accurate way for LSR to tell what the label is carrying, and wrong guess while rare will be extremely hard to root cause, because you will never hear it, because the person

Re: Lossy cogent p2p experiences?

2023-09-01 Thread Mark Tinka
On 9/1/23 15:59, Mike Hammett wrote: I wouldn't call 50 megabit/s an elephant flow Fair point. Mark.

Re: Lossy cogent p2p experiences?

2023-09-01 Thread Mark Tinka
On 9/1/23 15:44, Mike Hammett wrote: and I would say the OP wasn't even about elephant flows, just about a network that can't deliver anything acceptable. Unless Cogent are not trying to accept (and by extension, may not be able to guarantee) large Ethernet flows because they can't balance

Re: Lossy cogent p2p experiences?

2023-09-01 Thread Mark Tinka
On 9/1/23 15:29, Saku Ytti wrote: PTX and MX as LSR look inside pseudowire to see if it's IP (dangerous guess to make for LSR), CSR/ASR9k does not. So PTX and MX LSR will balance your pseudowire even without FAT. Yes, this was our conclusion as well after moving our core to PTX1000/10001.

Re: Lossy cogent p2p experiences?

2023-09-01 Thread Mark Tinka
On 9/1/23 10:50, Saku Ytti wrote: It is a very plausible theory, and everyone has this problem to a lesser or greater degree. There was a time when edge interfaces were much lower capacity than backbone interfaces, but I don't think that time will ever come back. So this problem is systemic.

Re: Destination Preference Attribute for BGP

2023-08-30 Thread Mark Tinka
On 8/30/23 18:56, michael brooks - ESC wrote: I, too, am looking for something sexy (explained below). But can you explain why you think AS_PATH is "useless," Mark? Because most network operators use LOCAL_PREF heavily, and no amount of AS_PATH prepending will be able fight that with any

Re: MX204 Virtual Chassis Setup

2023-08-28 Thread Mark Tinka
On 8/28/23 07:55, Daniel Marks wrote: (Enterprise AS for context) This hasn’t been my experience in the US, however we mostly deal in tier 2 markets (I.e. Detroit, Miami, Dallas, etc…) and we have plenty of 40G private interconnects. I don’t doubt 40G is going away, I’ve just never had

Re: MX204 Virtual Chassis Setup

2023-08-27 Thread Mark Tinka
On 8/28/23 03:05, Mike Hammett wrote: Well, or they simply found a potential deal on hardware that came with 40 gig ports. 40 gigs is still a lot of bits to a lot of people. For internal use, sure. But when connecting to another AS, the chances of them supporting 40Gbps in one or more

Re: MX204 Virtual Chassis Setup

2023-08-26 Thread Mark Tinka
On 8/27/23 04:52, Eric Kuhnke wrote: I sincerely doubt there is much demand for *new* 40G these days. Look at the population of 40G members on major IXes. People have either one 10G, 2 x 10G, or 100G. 40G was a dead-end 9 years ago and much so more now. We have customers that sometimes

Re: MX204 Virtual Chassis Setup

2023-08-25 Thread Mark Tinka
On 8/26/23 00:54, Tom Beecher wrote: It would, sure. Instead of storing a single prefix/next-hop with flags in memory, you now have to store every prefix/next-hop that you are announcing as well. Indeed. But it has been worth it. The load balancing from PE-to-PE has been fantastic,

Re: MX204 Virtual Chassis Setup

2023-08-25 Thread Mark Tinka
On 8/25/23 19:16, Tom Beecher wrote: In my experience and testing with them, you have a decent bit of headroom past the published RIB/FIB limits before they'll fall over. They are holding up pretty well for us, mainly because we do a lot more BGP on MX480's than on MX204's. We use the

Re: MX204 Virtual Chassis Setup

2023-08-25 Thread Mark Tinka
On 8/23/23 17:14, Matt Erculiani wrote: Does Fusion not make sense in this case? I've not had a ton of experience with it, but it does well to add a crazy port count to an otherwise very port limited device. In small edge PoP's, we attach an Arista 1U switch with tons of 1/10Gbps ports

Re: Deployments of Provider Backbone Bridging (PBB)

2023-08-25 Thread Mark Tinka
On 8/25/23 09:41, Tarko Tikan wrote: AFAIK this reflects the reality very well. There are huge PBB deployments in very large networks but the overall number of networks, using PBB, is very low. Even in those networks PBB is/will be phased out so don't expect any new deployments. It is

Re: MX204 Virtual Chassis Setup

2023-08-23 Thread Mark Tinka
On 8/23/23 18:29, t...@pelican.org wrote: Not Trio, and different PLM :) Yes, aware... I was just speaking in general for what is likely to be a very popular platform :-). MX304 (well, strictly LMIC16) has the same restriction, and a need for another entry in the magic port checker

Re: MX204 Virtual Chassis Setup

2023-08-23 Thread Mark Tinka
On 8/23/23 17:01, Tom Beecher wrote: I'm not sure they allow oversubscription on anything in the MX line anymore honestly. I could be wrong, I've been face down in a specific subset of equipment for a while, someone please correct me if I am. On the new ACX line, yes. If I look at the

Re: MX204 Virtual Chassis Setup

2023-08-23 Thread Mark Tinka
On 8/23/23 08:00, Pascal Masha wrote: Thanks just wanted to know whether it was a supported feature. What would have been nice is if Juniper oversubscribed the face plate of this platform, as most people are more likely to run out of ports than they would the 400Gbps forwarding capacity

Re: Destination Preference Attribute for BGP

2023-08-22 Thread Mark Tinka
On 8/22/23 16:46, Tom Beecher wrote: Again, as it was stated, the size of or number of BGP communities wasn't the problem anyway; it was hashing / memory storage. And you know what? Hashing / memory storage HAS been a problem with multiple vendors in many other contexts, not just BGP

Re: Destination Preference Attribute for BGP

2023-08-21 Thread Mark Tinka
On 8/21/23 17:44, Tom Beecher wrote: So, while this all sounds good, without any specifics on vendor, box, code, code revision number, fix, year it happened, current status, e.t.c., I can't offer any meaningful engagement. If you clicked Matt's link to the Google search, you

Re: MX204 Virtual Chassis Setup

2023-08-21 Thread Mark Tinka
On 8/21/23 16:51, Ryan Hamel wrote: Paschal, It is not supported, nor is it recommended for redundancy in a routed setup. Please describe your (desired) topology, that way the community can discuss alternatives. Sounds like the OP wants to build a chassis-based system out of

Re: Destination Preference Attribute for BGP

2023-08-18 Thread Mark Tinka
On 8/19/23 00:22, Matthew Petach wrote: Hi Mark, I know it's annoying that I won't mention specifics. Unfortunately, the last time I mentioned $vendor-specific information on NANOG, it was picked up by the press, and turned into a multimillion dollar kerfuffle with me at the center of the

Re: Destination Preference Attribute for BGP

2023-08-18 Thread Mark Tinka
On 8/18/23 22:40, Matthew Petach wrote: Hi Robert, Without naming any names, I will note that at some point in the not-too-distant past, I was part of a new-years-eve-holiday-escalation to $BACKBONE_ROUTER_PROVIDER when the global network I was involved with started seeing excessive

Re: Destination Preference Attribute for BGP

2023-08-18 Thread Mark Tinka
On 8/18/23 22:20, Jakob Heitz (jheitz) via NANOG wrote: We support platforms of various capacities. While we would all like to sell the large ones, people buy the cheap ones too. Even a bare bones x86 platform of some sort with at least 8GB of RAM would make the cheapest routers still,

Re: Destination Preference Attribute for BGP

2023-08-18 Thread Mark Tinka
On 8/18/23 19:38, Jakob Heitz (jheitz) via NANOG wrote: That's true Robert. However, communities and med only work with neighbors. Communities routinely get scrubbed because they cause increased memory usage and convergence time in routers. Really? We only scrub a specific string of

Re: Destination Preference Attribute for BGP

2023-08-18 Thread Mark Tinka
On 8/18/23 09:38, Robert Raszuk wrote: Jakob, With AS-PATH prepend you have no control on the choice of which ASN should do what action on your advertisements. My comprehension of DPA would have been more directed than the "spray & pray" approach AS_PATH prepending provides. However,

Re: Destination Preference Attribute for BGP

2023-08-18 Thread Mark Tinka
On 8/18/23 09:38, Robert Raszuk wrote: Jakob, With AS-PATH prepend you have no control on the choice of which ASN should do what action on your advertisements. My comprehension of DPA would have been more directed than the "spray & pray" approach AS_PATH prepending provides. However,

Re: Destination Preference Attribute for BGP

2023-08-17 Thread Mark Tinka
On 8/17/23 21:43, Jakob Heitz (jheitz) via NANOG wrote: "prepend as-path" has taken its place. That pours water on my imaginary fire :-). I was imagining something sexier, especially given how pretty "useless" AS_PATH prepending is nowadays. Mark.

Re: Destination Preference Attribute for BGP

2023-08-16 Thread Mark Tinka
On 8/16/23 16:16, michael brooks - ESC wrote: Perhaps (probably) naively, it seems to me that DPA would have been a useful BGP attribute. Can anyone shed light on why this RFC never moved beyond draft status? I cannot find much information on this other than IETF's data tracker

Re: Dodgy AS327933 ...?

2023-08-15 Thread Mark Tinka
On 8/16/23 00:28, Nick Hilliard wrote: Whatever about the web / winbox UI, there are some fairly serious weaknesses in the cli and api: 1. there's no atomic configuration commit + auto rollback. 2. the CLI is non-idempotent, for example if you're in a list context and issue the command

Re: Dodgy AS327933 ...?

2023-08-11 Thread Mark Tinka
On 8/11/23 12:56, Nick Hilliard wrote: bgp is a policy based distance vector protocol. If you can't adjust the primary inter-domain metric to handle your policy requirements, it's not much use. I am not talking about appending one's own AS in the AS_PATH. I am talking about appending

Re: Dodgy AS327933 ...?

2023-08-11 Thread Mark Tinka
On 8/11/23 11:26, Nick Hilliard wrote: If your asn is 327933, then: add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend=2 ... will produce: "327933 327933", and: add chain=foo prefix=192.0.2.0/24 action=accept set-bgp-prepend-path=2 ... will produce: "327933 2". Routeros

Re: Dodgy AS327933 ...?

2023-08-11 Thread Mark Tinka
On 8/11/23 11:08, Nick Hilliard wrote: yep, sure did.  Check out the "set-bgp-prepend" action on routeros - it's right next to "set-bgp-prepend-path". https://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters So how would one fumble it to the degree where a fat-finger results in

Re: Dodgy AS327933 ...?

2023-08-11 Thread Mark Tinka
On 8/11/23 10:15, b...@uu3.net wrote: Haha :) you are right. I just checked Caida AS ranking: http://as-rank.uu3.net/?as=2 A lot of "providers" for UDEL-DCN. Yeah right.. They all indeed probably try to prepend their AS 2 times ending up having ASN 2 in path. Did I miss the memo where

Re: Hawaiian ILEC infrastructure and fire

2023-08-10 Thread Mark Tinka
On 8/11/23 05:17, Eric Kuhnke wrote: Recently saw an aerial video where an entire neighborhood in Laihana had burned down *except* for the concrete block structure small ILEC CO. Pictures I have seen of other ILEC sites in Hawaii closely resemble some GTE sites in the Pacific Northwest

Re: Dodgy AS327933 ...?

2023-08-10 Thread Mark Tinka
On 8/10/23 20:43, Randy Bush wrote: classic microtik prepend syntax confusion? Uncertain. I have a Mikrotik CPE for my home router, but I can't tell you how BGP works on it. It seems that AS2, in the path, is not genuine. We are verifying that, though. Mark.

Re: Dodgy AS327933 ...?

2023-08-10 Thread Mark Tinka
On 8/10/23 15:22, Frank Habicht wrote: ouch! I see in your LG that this AS 2 is originating 197.157.254.0/24 . which seems to mean that it's not just a plain "we want to prepend 2 times, put the number 2 into config and the NOS takes this as the ASN to insert" putting someone from 

Re: Dodgy AS327933 ...?

2023-08-10 Thread Mark Tinka
On 8/10/23 12:01, d...@darwincosta.com wrote: I know someone you might know them. Happy to introduce off-list. Yes, Darwin. That would be most appreciated. Thanks. Mark.

Re: Dodgy AS327933 ...?

2023-08-10 Thread Mark Tinka
On 8/10/23 11:38, Frank Habicht wrote: from a 2019 DB snapshot: aut-num:    AS327933 as-name:    GROUPE-TELECOM-SPRL descr:  GROUPE TELECOM SPRL status: ASSIGNED org:    ORG-GTS2-AFRINIC admin-c:    YM8-AFRINIC tech-c: YM9-AFRINIC notify:

Dodgy AS327933 ...?

2023-08-10 Thread Mark Tinka
Hi all. Anyone know anything about this AS: https://bgp.he.net/AS327933 Mark.

Re: NTP Sync Issue Across Tata (Europe)

2023-08-07 Thread Mark Tinka
On 8/7/23 11:04, Giovane C. M. Moura via NANOG wrote: TL;DR: I'd guess your NTP Server IP address is geolocated to Mauritius. The Mauritius zone[0] on the pool has only one server, so you'll only see this one. To fix it, use europe.pool.ntp.org (_do not_ use pool.ntp.org). So the Anycast

Re: NTP Sync Issue Across Tata (Europe)

2023-08-07 Thread Mark Tinka
On 8/5/23 21:26, Mel Beckman wrote: Mark, You might consider setting up your own GPS-based NTP network. Commercial Ethernet GPS-sourced NTP servers, such as the Time Machines, TM1000A, are as little as $400. Or you can roll your own using a Raspberry Pi or similar nano computer with a

Re: NTP Sync Issue Across Tata (Europe)

2023-08-05 Thread Mark Tinka
On 8/5/23 20:17, Chris Adams wrote: It's the NTP pool people you need to talk to - the .freebsd. bit is just a vendored entry into the pool (more for load tracking and management). Yes, Andreas clarified in unicast. Will do. Thanks. Mark.

Re: NTP Sync Issue Across Tata (Europe)

2023-08-05 Thread Mark Tinka
On 8/5/23 19:51, Andreas Ott wrote: See for yourself how his pool server scores at https://www.ntppool.org/scores/197.224.66.40 I am not sure why it would be inserted into DNS answers for a worldwide pool like 0.freebsd as it clearly does have connectivity issues from some of the pool

Re: NTP Sync Issue Across Tata (Europe)

2023-08-05 Thread Mark Tinka
On 8/5/23 18:30, Matthew McGehrin wrote: Hi Mark. Wouldn't a local server be more optimal? IE: server 0.nl.pool.ntp.org server 1.nl.pool.ntp.org server 2.nl.pool.ntp.org server 3.nl.pool.ntp.org I have a bunch of servers all over Europe I'd

NTP Sync Issue Across Tata (Europe)

2023-08-05 Thread Mark Tinka
Hi all. I have NTP servers in Europe that are choosing Tata (6453) to get to 0.freebsd.pool.ntp.org which lives on 197.224.66.40: traceroute -I 0.freebsd.pool.ntp.org traceroute to 0.freebsd.pool.ntp.org (197.224.66.40), 64 hops max, 48 byte packets  1  ae-2-24.er-01-ams.nl.seacomnet.com

Re: Flapping Transport

2023-08-01 Thread Mark Tinka
On 8/1/23 21:34, Mike Hammett wrote: *nods* I know optical transport can be difficult to track down, but they had admitted to a faulty card, then said they weren't going to do anything because it hadn't faulted again. Yeah, it's probably just being cheap. Well, kinda. I mean they've also

Re: Flapping Transport

2023-08-01 Thread Mark Tinka
On 8/1/23 20:18, Mike Hammett wrote: I have a wave transport vendor that suffered issues twice about ten days apart, causing my link to flap a bunch. I put in a ticket on the second set of occurrences. I was told that there was a card issue identified and would be notified when the

Re: Flapping Transport

2023-08-01 Thread Mark Tinka
On 8/1/23 20:37, Jared Mauch wrote: Some providers have a much more disruptive layer-1 infrastructure and will ask you to configure a 1s+ up timer. I think there’s an interesting question that could go either way, do you want transport side faults to be exposed to you, or should the

  1   2   3   4   5   6   7   8   9   10   >