We appeared to be impacted with some address space within 206.47.0.0/16
which AS577 normally advertises, but that was between 15:50 and 16:30
Eastern.
Jeff
On Wed, Jul 29, 2020, 10:48 PM Clinton Work wrote:
> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until
> 20:23 MDT.
Northern CA is fine. Cable and fiber both operating
On 7/29/2020 7:36 PM, Kenneth McRae via NANOG wrote:
Anyone outside of S. California affected?
We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until 20:23
MDT. Anybody else have problems with that.
ASpath: 1299 7219 10990
50.92.0.0/17AS10990
198.166.0.0/17 AS10990
198.166.128.0/17AS10990
162.157.128.0/17AS10990
162.157.0.0/17 AS10990
Anyone outside of S. California affected?
Got a contact, delisted and found a local contact we had too, thank you
everyone.
Chris Gross
NineStar Connect
From: NANOG on behalf of
Chris Gross
Sent: Tuesday, July 28, 2020 4:22 PM
To: nanog list
Subject: Finish Line/JD Sports Contact
Does anyone have a
For national (U.S.), on site techs I can recommend
http://www.servicecommunications.com we subcontract for them on the regular
and they run a tight ship and have many large national accounts. I would
not get hung up on choosing someone with their own employees vs.
contracting or hybrid, but more
> On Jul 29, 2020, at 09:43 , Douglas Fischer wrote:
>
> Does anybody here knows what Gambiarra means?
The english translation would be “Jury Rig” or “Hack”.
Synonyms include “McGyverism”, “Rube Goldberg”, “Kludge”, etc.
Foreign address family as next-hop is definitely in this category.
>
I back Mike’s comments, they support some of our on-prem hardware/software. To
my knowledge their senior techs/engineers work remote. For on-site they do not
farm services to 3rd parties but to the local BB office. This means the field
tech may be trained in the solution but may not be an
We currently use BlackBox and they use their own techs where I'm at
(Phoenix). We also used them extensively when I worked for Level 3 several
years ago. As with anything, your experience with them will vary largely by
location and can even vary within a market. I have dealt with some awesome
Do you know or have experience with either company? Do they have their own
techs are they just bidding out for local techs in the area? I have work
that needs to be done all across the US and just trying to look for some
options.
Does anybody here knows what Gambiarra means?
Alejandro mentioned that IPv6 NextHop on IPv4 routing breaks traceroute and
difficult troubleshooting.
Well... Since a while I have been thinking about a Gambiarra that I'm using
on other scenarios, but I think could help to reduce de bad impacts of
*“In talking to some of the other women in the industry, I'm sort of a
unicorn — I‘ve actually been very, very fortunate.”*
Our newest series on NANOG TV explores the stories and career paths of some
of the most exceptional women we know. Watch our second interview,
featuring Kat Ronay of
On 29/Jul/20 18:35, Nick Hilliard wrote:
> You can't use hostnames, if that's what you're asking.
Yes, couldn't fathom how.
So really it's convenience of troubleshooting, not convenience of setup
:-). I can live with that.
> FRR will also do
> unnumbered BGP with auto-config.
Mark Tinka wrote on 29/07/2020 17:06:
> Meaning the initial setup would still require the use of literal IP
> addresses?
You can't use hostnames, if that's what you're asking. FRR will also do
unnumbered BGP with auto-config.
Nick
On Wed, 29 Jul 2020 at 18:06, Mark Tinka wrote:
> On 29/Jul/20 16:54, Nick Hilliard wrote:
> > it's a capability negotiation, so is handled on session setup.
>
> Meaning the initial setup would still require the use of literal IP addresses?
Unless your (e.g. DC equipment) is set up for automatic
On 29/Jul/20 16:57, Saku Ytti wrote:
> I'm not sure I understand what the option space is. This is like ISIS
> TLV137, protocol will populate some trash there and you'll politely
> access. It won't allow you to refer to the peer with any name prior to
> having the session up. Much like you
On 29/Jul/20 16:54, Nick Hilliard wrote:
>
> it's a capability negotiation, so is handled on session setup.
Meaning the initial setup would still require the use of literal IP
addresses?
Mark.
On Wed, 29 Jul 2020 at 18:51, Owen DeLong wrote:
> In reality, next hop isn’t really a layer 3 address. The layer 3 address is a
> stand-in that is resolved to
> a layer 2 address for forwarding. The layer 3 next-hop address never makes it
> into the packet.
I wish you had shared in the draft
> On Jul 29, 2020, at 02:13 , Saku Ytti wrote:
>
> On Wed, 29 Jul 2020 at 10:03, Vincent Bernat wrote:
>
>> This is the solution Cumulus is advocating to its users, so I suppose
>> they have some real users behind that. Juniper also supports RFC 5549
>> but, from the documentation, the
On Wed, 29 Jul 2020 at 17:54, Mark Tinka wrote:
> I'm curious to know if this is after-the-fact, as I can't think of a way
> that BGP would find hostnames to setup sessions with, outside of some
> kind of upper layer name resolution capability.
>
> The draft isn't clear on how this happens, if
Mark Tinka wrote on 29/07/2020 15:51:
> I'm curious to know if this is after-the-fact, as I can't think of a way
> that BGP would find hostnames to setup sessions with, outside of some
> kind of upper layer name resolution capability.
>
> The draft isn't clear on how this happens, if it is,
On 29/Jul/20 16:30, Nick Hilliard wrote:
>
> afaik, this is an implementation of draft-walton-bgp-hostname-capability.
Nice.
I'm curious to know if this is after-the-fact, as I can't think of a way
that BGP would find hostnames to setup sessions with, outside of some
kind of upper layer name
The primary thing that you need to do is to create ROAs of your block
allowing only your ASN as Origin.
Second, as Siyuan and Justin mentioned, get in touch with Merit RADB.
They are great! If you do the full job right in the first e-mail,
presenting the allocation of the RIR and the transfer,
Mark Tinka wrote on 29/07/2020 15:09:
> Are the names based on DNS look-ups, or is there some kind of protocol
> association between the device underlay and its hostname, as it pertains
> to neighbors?
afaik, this is an implementation of draft-walton-bgp-hostname-capability.
Nick
On 29/Jul/20 15:51, Simon Leinen wrote:
>
> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> State/PfxRcd
> sw-o(swp16)465108 953559 938348000 03w5d00h
> 688
> sw-m(swp18)465108 885442 9383480
Douglas Fischer writes:
> And today, I reached on https://tools.ietf.org/html/rfc5549
[...]
> But the questions are:
> There is any network that really implements RFC5549?
We've been using it for more than two years in our data center networks.
We use the Cumulus/FRR implementation on switches
Hey,
On Wed, 29 Jul 2020 at 14:26, Alejandro Acosta
wrote:
> https://blog.acostasite.com/2013/02/publicar-prefijos-ipv4-sobre-una-sesion.html
> https://blog.acostasite.com/2013/02/publicando-prefijos-ipv6-sobre-sesiones.html
>
> I did not like, difficult troubleshooting in case something goes
Long time ago I tried it out:
https://blog.acostasite.com/2013/02/publicar-prefijos-ipv4-sobre-una-sesion.html
https://blog.acostasite.com/2013/02/publicando-prefijos-ipv6-sobre-sesiones.html
I did not like, difficult troubleshooting in case something goes wrong
(however I can understand
On Wed, 29 Jul 2020 at 12:58, Vincent Bernat wrote:
> I didn't test, but the documentation states:
I think only disconnect here is definition of tunnel, there are no
additional headers and I don't think the document implies it and the
RFC it refers to does not. I've not tried it myself, but my
❦ 29 juillet 2020 12:13 +03, Saku Ytti:
>> This is the solution Cumulus is advocating to its users, so I suppose
>> they have some real users behind that. Juniper also supports RFC 5549
>> but, from the documentation, the forwarding part is done using
>> lightweight tunnels.
>
> I'm not sure if
On Wed, 29 Jul 2020 at 10:03, Vincent Bernat wrote:
> This is the solution Cumulus is advocating to its users, so I suppose
> they have some real users behind that. Juniper also supports RFC 5549
> but, from the documentation, the forwarding part is done using
> lightweight tunnels.
I'm not
Hi, Fred,
On 29/7/20 05:15, Fred Baker wrote:
Fernando, I asked a specific question, not "send me all of your comments".
General discussion of your draft still belongs on the v6...@ietf.org list. Please don't
confuse the issue.
Apologies if I may have lead to confusion. I just meant to
Fernando, I asked a specific question, not "send me all of your comments".
General discussion of your draft still belongs on the v6...@ietf.org list.
Please don't confuse the issue.
> On Jul 28, 2020, at 11:44 PM, Fernando Gont wrote:
>
> Folks,
>
> FYI. You can send your comments to if you
Hello,
This is implemented in FRR and will also be available in BIRD 2.0.8.
Linux accepts IPv6 next-hop for IPv4 natively since 5.3 (no tunnels).
This is the solution Cumulus is advocating to its users, so I suppose
they have some real users behind that. Juniper also supports RFC 5549
but, from
Folks,
FYI. You can send your comments to if you wish.
Thanks,
Fernando
Forwarded Message
Subject: [v6ops] Question about "Operational Implications of IPv6
Packets with Extension Headers"
Date: Tue, 28 Jul 2020 22:55:45 -0700
From: Fred Baker
Reply-To: V6Ops-Chairs
35 matches
Mail list logo
