On 11/18/20 14:58, adamv0...@netconsultings.com wrote:
From my experience, most of the SPs spend a considerable time testing for SW
defects on features (and combinations of features) that will be used and at
scale intended,
I'm not so sure about that, actually.
I'd say there are some
>
> I also put a lot of blame on C, it was a terrific language when
> compiling had to be fast. Basically macro assembler. Now the utility
> of being 'close to HW' is gone, as the CPU does so much C compiler has
> no control over, it's not really even executing the same code
> as-written anymore.
> Saku Ytti
> Sent: Tuesday, November 17, 2020 6:55 AM
>
> On Tue, 17 Nov 2020 at 03:40, Sabri Berisha wrote:
>
> Hey Sabri,
>
> > Also, in the case that I described it wasn't a Junos device. Makes me
> > wonder how bugs like that get introduced. One would expect that after
> > 20+ years of
> On Behalf Of Mark Tinka
> Sent: Tuesday, November 17, 2020 4:32 PM
>
> On 11/17/20 08:54, Saku Ytti wrote:
>
> > I put most of the blame on the market, we've modelled commercial
> > router market so that poor quality NOS is good for business and good
> > quality NOS is bad for business, I
On 11/17/20 08:54, Saku Ytti wrote:
I put most of the blame on the market, we've modelled commercial
router market so that poor quality NOS is good for business and good
quality NOS is bad for business, I don't think this is in anyone's
formal business plan or that companies even realise
On 17.11.2020 around 02:36 Sabri Berisha wrote:
Interesting. A long time ago, in a galaxy far far away, where I was a
JTAC engineer, policy was that once a PR was hit in the field, it
would be marked public.
Also, in the case that I described it wasn't a Junos device. Makes me
wonder how bugs
On Tue, 17 Nov 2020 at 03:40, Sabri Berisha wrote:
Hey Sabri,
> Also, in the case that I described it wasn't a Junos device. Makes me wonder
> how bugs
> like that get introduced. One would expect that after 20+ years of writing
> BGP code,
> handling a withdrawl would be easy-peasy.
I don't
Surely they can just put them in an array.
;)
On Mon, Nov 16, 2020, 21:54 Valdis Klētnieks
wrote:
> On Mon, 16 Nov 2020 17:36:58 -0800, Sabri Berisha said:
>
> > Also, in the case that I described it wasn't a Junos device. Makes me
> wonder how bugs
> > like that get introduced. One would
On Mon, 16 Nov 2020 17:36:58 -0800, Sabri Berisha said:
> Also, in the case that I described it wasn't a Junos device. Makes me wonder
> how bugs
> like that get introduced. One would expect that after 20+ years of writing
> BGP code,
> handling a withdrawl would be easy-peasy.
Handling a
- On Nov 16, 2020, at 11:45 AM, Matt Corallo na...@as397444.net wrote:
Hi,
> See my latest response from this morning. Telia's "Head of Network
> Engineering &
> Architecture" confirmed on Twitter this
> was due to a (now-worked-around) bug in JunOS.
>
>
See my latest response from this morning. Telia's "Head of Network Engineering & Architecture" confirmed on Twitter this
was due to a (now-worked-around) bug in JunOS.
https://twitter.com/gustawsson/status/1328298914785730561
Matt
On 11/16/20 2:13 PM, Sabri Berisha wrote:
- On Nov 15,
- On Nov 15, 2020, at 5:58 PM, Matt Corallo na...@as397444.net wrote:
> Has anyone else experienced issues where Telia won't withdraw (though will
> happily accept an overriding) prefixes for the past week, at least?
I have seen issues like this in a network that I operated. In that
For those curious, Johan indicated on Twitter this was a JunOS bug.
https://twitter.com/gustawsson/status/1328298914785730561
Matt
> On Nov 15, 2020, at 23:13, Matt Corallo wrote:
>
> Maybe? Never been an issue before. In this case the route does have a depref
> community on Telia hence why
Maybe? Never been an issue before. In this case the route does have a depref
community on Telia hence why one wouldn’t expect it via the same path, but the
other ghost route in question never had anything similar.
Matt
> On Nov 15, 2020, at 23:07, Olivier Benghozi
> wrote:
>
> One of the
One of the routing gears on the path don't like the large community inside
those routes maybe ? :)
By the way we currently see 2620:6e:a002::/48 at LINX LON1 from Choopa and HE...
> Le 16 nov. 2020 à 04:44, Matt Corallo a écrit :
>
> Yea, I did try that on that test prefix but it just stuck
Yea, I did try that on that test prefix but it just stuck around anyway.. I don't care too much, its just some stale
test prefix.
Sadly, I now see it again with 2620:6e:a002::/48, which, somewhat more impressively, is now generating a routing loop
Ashburn <-> NYC, and has always been announced
Probably a ghost route. Such thing happens :(
https://labs.ripe.net/Members/romain_fontugne/bgp-zombies
Their (nice) LG shows that it's still advertised from a router of theirs in
Frankfurt (iBGP next hop :::2.255.251.224 – so by the way they use 6PE).
Your best option would probably be to
This same issue happened in Los Angeles a number of years ago, but for IPv4 and
v6. They need to setup sane BGP timers, and/or advocate the use of BFD for BGP
sessions both customer facing and internal.
Ryan
On Nov 15 2020, at 5:58 pm, Matt Corallo wrote:
> Has anyone else experienced issues
Has anyone else experienced issues where Telia won't withdraw (though will happily accept an overriding) prefixes for
the past week, at least?
eg 2620:6e:a003::/48 was a test prefix and should not now appear in any DFZ, has not been announced for a few days at
least, but shows up in Telia's LG
19 matches
Mail list logo
