On Fri, 9 Dec 2022 at 20:19, t...@pelican.org wrote:
Hey Tim,
> Or at least, you've moved the problem from "generate config" to "have
> complete and correct data". Which statement should probably come with some
> kind of trigger-warning...
I think it's a lot easier than you think. I understa
On Thu, Dec 8, 2022 at 9:35 AM Randy Bush wrote:
> while i think the announcement is, shall we say, embarrassing, i do not
> see how it would be damaging. real/correct announcements would be for
> longer prefixes, yes?
>
> randy
>
Putting on a probably-overly-paranoid hat for a moment...
If
> I know of a few people in a Discord that filter out anything bigger
> than /16 routes, would this be wise to implement as a best practice?
once upon a time, a very large provider took two /8s and announced as a
/7. a vendor who thought a /8 was as short as they would ever see had
routers fall o
On Friday, 9 December, 2022 16:04, "Saku Ytti" said:
> If you remove the need for deltas the whole problem becomes extremely
> trivial. Fill in all the templates with data, push it.
Or at least, you've moved the problem from "generate config" to "have complete
and correct data". Which statemen
Sander,
How big? How slow?
You can reply to me off or on list.
About 8 to 10 years ago, we had a large effort to improve this.
Now customers push many megabytes of prefix-sets several times a day and it
works.
I have sent some questions internally to get a better answer.
Related, in 7.2.1, we a
I know of a few people in a Discord that filter out anything bigger than /16
routes, would this be wise to implement as a best practice?
From: Warren Kumari
Sent: Friday, December 9, 2022 9:13 AM
To: Job Snijders
Cc: r...@rkhtech.org; North American Network Operators' Group
Subject: Re: AS
This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
Daily listings are sent to bgp-st...
Fri, Dec 09, 2022 at 05:33:09PM +0200, Saku Ytti:
> If you read carefully, that is what Steffann is doing. He is doing
> 'load location:file' + 'commit'. He is not punching anything by hand.
>
> So the answer we are looking for is how to make that go faster.
>
> In Junos answer would be 'ephemera
Hi Ytti,
>> Pushing thousands of lines via CLI/expect automation is def not a great
>> idea, no. Putting everything into a file, copying that to the device, and
>> loading from there is generally best regardless. The slowness you refer to
>> is almost certainly just because of how XR handles co
On Thu, Dec 8 2022 at 12:38 PM, Job Snijders wrote:
Hi all,
>
> On Wed, Dec 07, 2022 at 08:24:54PM -0800, Ryan Hamel wrote:
>
> AS3356 has been announcing 2000::/12 for about 3 hours now, an aggregate
> covering over 23K prefixes (just over 25%) of the IPv6 DFZ.
>
> A few months ago I wrote: "Fre
On Fri, 9 Dec 2022 at 17:58, Joshua Miller wrote:
> In terms of structured vs unstructured data, sure, assembling text is not a
> huge lift. Though, when you're talking about layering on complex use cases,
> then it gets more complicated. Especially if you want to compute the inverse
> config
I agree, I don't think you can get around the XR config bottleneck. But
that's not really the end of the story.
Let's think about why the loading time matters to Sander (Sander, please
chime in here):
1. They have to address an immediate issue for a customer (internal or
external) and the custome
On Fri, 9 Dec 2022 at 17:30, Tom Beecher wrote:
> Pushing thousands of lines via CLI/expect automation is def not a great idea,
> no. Putting everything into a file, copying that to the device, and loading
> from there is generally best regardless. The slowness you refer to is almost
> certain
Pushing thousands of lines via CLI/expect automation is def not a great
idea, no. Putting everything into a file, copying that to the device, and
loading from there is generally best regardless. The slowness you refer to
is almost certainly just because of how XR handles config application. If
I'm
On Fri, 9 Dec 2022 at 17:07, Joshua Miller wrote:
> I don't know that Netconf or gRPC are any faster than loading cli. Those
> protocols facilitate automation so that the time it takes to load any one
> device is not a significant factor, especially when you can roll out changes
> to devices i
Hi Saku.
I don't know that Netconf or gRPC are any faster than loading cli. Those
protocols facilitate automation so that the time it takes to load any one
device is not a significant factor, especially when you can roll out
changes to devices in parallel. Also, it's easier to build the changes in
Can Andrian and Joshua explain what they specifically mean, and how
they expect it to perform over what Steffann is already doing (e.g.
load https://nms/cfg/router.txt)? How much faster will it be, and why?
Can Steffan explain how large a file they are copying, over what
protocol, how long does it
Two options:
- gRPC
- Netconf
You can use tools like paramiko,netmiko or napalm that are widely used
to programmatically configure and manage your XR router.
On Fri, Dec 9, 2022 at 2:24 AM Joshua Miller wrote:
> Netconf is really nice for atomic changes to network devices, though it
> would st
18 matches
Mail list logo
