Re: RPKI race

[Baldur Norddahl]

On Wed, Jun 17, 2020 at 1:43 AM Rubens Kuhl  wrote:

>
> Any default route to a non-ROV enabled upstream ?
> Do you receive the test prefix from more than one upstream and the
> previous test success could be a function of upstream ROV ?
>
>
No this is how it looks:

admin@gc-edge1> show route 2606:4700:7000::6715:f40f

internet.inet6.0: 92472 destinations, 288208 routes (90838 active, 0
holddown, 6565 hidden)
+ = Active Route, - = Last Active, * = Both

2606:4700:7000::/48*[BGP/170] 1d 21:46:42, MED 100, localpref 100, from
2001:7f8:13::a503:4307:1
  AS path: 13335 I, validation-state: unknown
>  to 2001:7f8:13::a501:3335:1 via nl-ix
[BGP/170] 1d 21:46:39, MED 100, localpref 100, from
2001:7f8:13::a503:4307:2
  AS path: 13335 I, validation-state: unknown
>  to 2001:7f8:13::a501:3335:1 via nl-ix
[BGP/170] 1d 21:46:50, MED 290, localpref 100
  AS path: 174 37100 13335 I, validation-state: unknown
>  to 2001:978:2:d::25:1 via cogent

admin@gc-edge1> show route 103.21.244.14

internet.inet.0: 818706 destinations, 2528384 routes (816242 active, 4
holddown, 32715 hidden)
+ = Active Route, - = Last Active, * = Both

103.21.244.0/24*[BGP/170] 1d 21:35:34, MED 100, localpref 100, from
193.239.117.0
  AS path: 13335 I, validation-state: unknown
>  to 193.239.117.114 via nl-ix
[BGP/170] 1d 21:35:29, MED 100, localpref 100, from
193.239.116.255
  AS path: 13335 I, validation-state: unknown
>  to 193.239.117.114 via nl-ix

Plenty of prefixes in valid state:

admin@gc-edge1> show route table internet.inet.0 validation-state valid

internet.inet.0: 811569 destinations, 2519989 routes (809383 active, 1
holddown, 28989 hidden)
+ = Active Route, - = Last Active, * = Both

1.9.0.0/16 *[BGP/170] 08:05:51, MED 100, localpref 100, from
193.239.117.0
  AS path: 6939 4788 I, validation-state: valid
>  to 193.239.116.14 via nl-ix
[BGP/170] 08:04:24, MED 100, localpref 100, from
193.239.116.255
  AS path: 6939 4788 I, validation-state: valid
>  to 193.239.116.14 via nl-ix
1.9.250.0/24   *[BGP/170] 08:05:48, MED 100, localpref 100, from
193.239.117.0
  AS path: 6939 4788 I, validation-state: valid
>  to 193.239.116.14 via nl-ix
[BGP/170] 08:04:21, MED 100, localpref 100, from
193.239.116.255
  AS path: 6939 4788 I, validation-state: valid
>  to 193.239.116.14 via nl-ix
1.32.218.0/24   [BGP/170] 2d 05:48:33, MED 210, localpref 100
  AS path: 1299 2914 64050 4842 I, validation-state:
valid
>  to 62.115.180.72 via telia
[BGP/170] 2d 05:47:35, MED 290, localpref 100
  AS path: 174 2914 64050 4842 I, validation-state:
valid
>  to 149.6.137.49 via cogent
etc

After clearing the relevant BGP sessions the Cloudflare invalid prefixes
are gone from our routing table and we pass the test again.

Regards,

Baldur

Re: Reactive RPKI ROV (Was: Hurricane Electric has reached 0 RPKI INVALIDs)

[Mark Tinka]

On 16/Jun/20 22:07, Job Snijders wrote:

> Since it is with words that we construct the magic of our reality, let's
> assign a name specific to this engineering effort:
>
> Reactive RPKI ROV
> =

Reactive RPKI ROV, it is, then :-).

A great effort by HE for a network that may not yet completely support
RFC 6811.

We're quickly running out reasons.

Mark.

Re: Router Suggestions

[Mark Tinka]

On 16/Jun/20 23:26, Owen DeLong wrote:

> Count your blessings…

I know that we are lucky that in the markets we operate, local depots
are available. There are other markets in Africa that may not be so
lucky. If we ever built into those markets, we'd certainly cold spare as
much as possible, as we used to in the current markets that the vendors
didn't have local depots for 10 or so years ago.


> As I said, YMMV, but I’m betting your vendor doesn’t stock a second copy of 
> every piece of covered equipment in the local depot. They’re playing the 
> statistical probabilities just
> like anyone else stocking their own spares pool. The biggest difference is 
> that they’re
> spreading the risk across a (potentially) much wider sample size which may 
> better normalize
> the numbers.

Yes, it's just like a bank - they hope not all customers come to
withdraw all their cash on the same morning.

We run a CRS 4-port 100Gbps line card that I know is not very popular
among other operators in the markets where we have them. We had one fail
in a smaller city a few weeks ago. We pay for NBD, not 24/7. A new line
card arrived promptly, the morning after. I did hold my breath, but they
managed.

But yes, this is one of those things to seriously consider before you go
standing up a network in a new market.

Mark.

Re: RPKI race

[Mark Tinka]

On 17/Jun/20 09:22, Baldur Norddahl wrote:

>
> After clearing the relevant BGP sessions the Cloudflare invalid
> prefixes are gone from our routing table and we pass the test again.

Are you running RTR to the validator for the router, or using RPKI
communities?

Mark.

Re: RPKI race

[Baldur Norddahl]

On Wed, Jun 17, 2020 at 10:07 AM Niels den Otter 
wrote:

> Hello Baldur,
>
> If you want to validate routes in a VRF you need to configure;
>
> set routing-options validation notification-rib 
>
> Have you done so?
>
>
>
That was missing from the config. After adding it and running the command
"request validation policy" I got the prefixes validated.

Thanks for the help.

Baldur

Re: RPKI race

[Mark Tinka]

On 17/Jun/20 10:20, Baldur Norddahl wrote:

>
>
> On Wed, Jun 17, 2020 at 10:07 AM Niels den Otter
> mailto:niels.denot...@surfnet.nl>> wrote:
>
> Hello Baldur,
>
> If you want to validate routes in a VRF you need to configure;
>
> set routing-options validation notification-rib 
>
> Have you done so?
>
>>
>
> That was missing from the config. After adding it and running the
> command "request validation policy" I got the prefixes validated.

Not to sound funny, but this is one of the reasons I am still afraid to
run the Internet in a VRF. There are a lot more things to consider, I've
often found, compared to what you take for granted in the global table.

That said, this is great to know, given that many operators run the
Internet in a VRF, and we need RPKI + ROV to be supported far and wide.

Mark.

Re: [c-nsp] LDPv6 Census Check

[Mark Tinka]

On 16/Jun/20 14:24, adamv0...@netconsultings.com wrote:

> Actually I was exactly I that situation and v4 RFC 1918 space worked out just 
> fine.

In that way, you are braver than me. But hey, if you need IPv4 and can't
get the public stuff, I won't fault you for going with the private stuff
:-).


> I've been dependent solely on v4 all my life and I still am. 
> But I see your fate-sharing argument, similar to my argument around separate 
> iBGP infrastructure (Route-Reflector plane) for Internet vs for other 
> customer private VPN prefixes. 
> But in the multiplanar iBGP case one plane is statistically more likely to 
> fail than the other, whereas in case of v4 vs v6 control plane I'd say it's 
> actually the NEW v6 that's more likely hiding some unforeseen bug. 
> So let me ask the following "devil's advocate" type of question, under the 
> assumption that the LDPv6 is a new thing (not as proven as LDPv4), are you 
> taking dependency away by splitting control plane to v4 and v6 or actually 
> adding dependency - where the NEW v6 control plane components could 
> negatively affect the existing v4 control plane components after all they 
> share a common RE (or even RDP in Junos). 

Well, that's a bottomless rabbit hole that go could all to the way to
the data centre providing A+B power feeds, but connected to a single
grid on the outside. At some point, redundancy stops making sense and
eats into your margins as much as it does your sanity :-).

But back to the question at hand, even with 6PE, you can't avoid running
a dual-stack network... you'd need to at the edge. So if your goal is to
use 6PE to avoid running IPv6 in some native form anywhere in your
network, that won't work out, as I'm sure you know :-).

But more importantly, I, as have many others on this group, have been
running IPv6 since about 2003 (others, even longer, I'm sure). IPv6, in
and of itself, has never been an issue for me. The problems have always
been the ancillary services that need to run on top of it in order to
work. For the past 17 years, my IPv6 headaches have been about feature
parity with IPv4, mostly, in routers and switches (in general-purpose
server OS's too, but those got fixed much more quickly):

  * DNS over IPv6 took a while to arrive.
  * TACACS+ over IPv6 took a while to arrive.
  * IPv6 ACL's took a while to get proper support.
  * SNMP over IPv6 took a while to arrive.
  * NTP over IPv6 took a while to arrive.
  * SSH over IPv6 took a while to arrive.
  * OSPFv3 Authentication was very clunky.
  * Multi Topoloy IS-IS support was very clunky.

You get the idea.

I've always operated a native dual-stack network, so having to go back
and upgrade routers every so often when one of the above limitations got
fixed in a later revision of code was tiresome, but worthwhile. We take
a lot of these things for granted in 2020, but it was no joke more than
a decade ago.

So for me, I've never really experienced any problems from basic IPv6
that have negatively impacted IPv4.

The corner case I am aware of that didn't even bother IPv4 was Ethernet
switches and some popular Chinese GPON AN's that silently dropped
Ethernet frames carrying IPv6 packets because they did not know how to
handle the 0x86DD EtherType. But AFAIK, these have all been since fixed.

So based on pure experience, I don't expect this "32-year old new IPv6"
thing to be hiding some unforeseen bug that will break our IPv4 network :-).

LDPv6 was first implemented in IOS XR, Junos and SR-OS in 2015/2016, so
it has been around for a while. The biggest challenge was with IOS XR in
2015 (5.3.0) which didn't support dual-stack TLV's. So if the LDP
neighbor negotiated LDPv4 and LDPv6 in the same LDP session, IOS XR
didn't know what to do. It could do LDPv4-only or LDPv6-only, and not
both. That issue was fixed in IOS XR 6.0.1, when the Dual-Stack
Capability TLV feature was introduced. That was May of 2016, so also not
that new.

Mark.

Re: Reactive RPKI ROV (Was: Hurricane Electric has reached 0 RPKI INVALIDs)

[Baldur Norddahl]

Lets say someone makes an announcement that creates a RPKI invalid and 
it is determined to be a mistake. They then go back and add ROA objects 
to fix the problem. With this reactive RPKI approach then continue to 
block the route because filters where already generated and pushed out 
to routers? Or in other words, if the system can insert the filter in 
less than 60 seconds, how long does it take to get rid of the filter 
again when someone publish valid a ROA ?


Regards,

Baldur

RE: BGP FLowspec to Yang/Yaml ACL

[adamv0025]

In order to use YANG you need a device that can speak NETCONF/RESTCONF and 
understands YANG.

There’s no such thing as “The YANG ACL” -there’s IETF YANG model for ACLs, 
there’s OpenConfig one, and your switch vendor might have another YANG model 
for representing ACLs. 

Whichever model provides sufficient coverage for your use case (i.e. can use 
the model to specify SRC/DST/MASK/DENY/ACCEPT) and is supported natively by 
your device (can send the ACL config in this format to the device at it knows 
what to do) is the right for you.   

 

If your devices do not support NETCONF/RESTCONF nor understand YANG you can 
still push the ACL changes via CLI scraping (Ansible)

 

Now in either case (netconf-yang/ansible), what you’re better off with is a 
tool that allows operator to enter the details of the ACL line to be added 
(details of the flow) and just take that input and insert it into the 
pre-defined/prepared template (yang/ansible template), then the script just 
prompts the resulting config to be pushed onto the device (devices).

 

 

adam

 

From: NANOG  On Behalf Of Douglas Fischer
Sent: Tuesday, June 16, 2020 7:40 PM
To: nanog@nanog.org
Subject: BGP FLowspec to Yang/Yaml ACL

 

We were looking for some way to implement BGP Flowspec Filtering(just the 
permit/deny basic) using L3 switches  in an automated way.

Searching a bit we found   
https://github.com/ios-xr/bgpfs2acl

 

Is almost what we are looking for!
But is focused on Cisco devices.

We even considered fork it to our specific vendor.
But before reinventing the wheel, I decide to ask to colleagues if anybody 
knows some tool that converts BGP Flowspec ACLs into YAML or even to YANG.

 

If that exists, with Ansible/Netconf/RestConf(or some similar tool), it would 
be easy to delegate to Switchs doing the basic filtering that only More 
expensive Routers can do by now.


P.S.: This Idea does not include(on the first moment) more complex features of 
Flowspec like Redirect ou Rate-Limt.

 

Any suggestions or ideas? 

 

 

 

 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação

Re: Reactive RPKI ROV (Was: Hurricane Electric has reached 0 RPKI INVALIDs)

[Job Snijders]

Dear Baldur,

On Wed, Jun 17, 2020 at 01:42:36PM +0200, Baldur Norddahl wrote:
> Lets say someone makes an announcement that creates a RPKI invalid and
> it is determined to be a mistake. They then go back and add ROA
> objects to fix the problem. With this reactive RPKI approach then
> continue to block the route because filters where already generated
> and pushed out to routers? Or in other words, if the system can insert
> the filter in less than 60 seconds, how long does it take to get rid
> of the filter again when someone publish valid a ROA ?

What you describe here is what I'd call a "Garbage Collection" process.
Garbage collection has to happen periodically.

Probably not slower than once an hour. See the following link for an
attempt to document that type of aspect of RPKI ROV deployments:
https://tools.ietf.org/html/draft-ietf-sidrops-rpki-rov-timing-00.html

Maybe HE can comment on their current timers?

Kind regards,

Job

favourite YANG data-store?

[adamv0025]

Hi folks,
Was just wondering what are you folks using as production YANG data store
and what do you like about the particular one you're using? Or maybe folks
using OANP what is your YANG DS of choice? 
Plan on using it as in memory DS primarily for service, network YANG
modules, (in addition to the usual use case of device modules), 
- so quite a lot of data as you can imagine storing data for higher
abstraction layers Service & Network. 
Been looking at ODL and Confd thus far. 

adam

Fwd: [routing-wg] From Zero to RPKI Hero: Live Demo

[Melchior Aelmans]

For those who still need to deploy RPKI OV we are running a 'live show' on
Friday. Feel free to join.

Cheers,
Melchior

-- Forwarded message -
From: Nathalie Trenaman 
Date: Wed, Jun 17, 2020 at 12:39 PM
Subject: [routing-wg] From Zero to RPKI Hero: Live Demo
To: ripedenis--- via routing-wg 


Hi all,

The community has teamed up to bring something very exiting to network
operators around the world!
This Friday, from 17:00 CEST, we are doing a live demo “From Zero to RPKI
Hero” where we will show how to create ROAs, set up Routinator, RIPE NCC
Validator, configure Juniper, Arista, Nokia and Cisco routers to perform
RPKI Origin Validation. This has never been done before! And it will be
live!  People can join over Zoom: https://arista.zoom.us/s/93051476697 <
https://arista.zoom.us/s/93051476697> or join the Facebook live stream:
https://www.facebook.com/events/183972346373123/186010836169274/ Later on,
this will be uploaded to YouTube.

Please note: This is not an event organised by any of the vendors, nor is
it a commercial event. Just a bunch of techies (Ties de Kock, Florian
Hibler, Greg Hankins, Jeff Tantsura, Orhan Ergun, Melchior Aelmans, Alex
Band and Nathalie Trenaman)  coming together to show “how it’s done”

Best regards,
Nathalie Trenaman

Re: favourite YANG data-store?

[Mikael Abrahamsson via NANOG]

On Wed, 17 Jun 2020, adamv0...@netconsultings.com wrote:


Hi folks,
Was just wondering what are you folks using as production YANG data store
and what do you like about the particular one you're using? Or maybe folks
using OANP what is your YANG DS of choice?
Plan on using it as in memory DS primarily for service, network YANG
modules, (in addition to the usual use case of device modules),
- so quite a lot of data as you can imagine storing data for higher
abstraction layers Service & Network.
Been looking at ODL and Confd thus far.


http://www.sysrepo.org/

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: BGP FLowspec to Yang/Yaml ACL

[Tim Jackson]

Use ExaBGP to insert the routes? (https://github.com/Exa-Networks/exabgp)

This is some old Perl that generates the older ExaBGP 2.0 style entries,
but it uses template toolkit which means you can easily change the output
format:

https://paste.somuch.fail/?744af55b8bea1414#WlXYkcfATNRxpRcr4NGOtxw4cqzStbCpApxmIevRPDk=

There's a lot more you could do to make this even more flexible, you don't
need YANG or to modify any config, just build something that accepts what
you're after and sends it as flowspec routes from ExaBGP to the routers you
care about.

--
Tim

On Tue, Jun 16, 2020 at 1:46 PM Douglas Fischer 
wrote:

> We were looking for some way to implement BGP Flowspec Filtering(just the
> permit/deny basic) using L3 switches  in an automated way.
>
> Searching a bit we found https://github.com/ios-xr/bgpfs2acl
>
> Is almost what we are looking for!
> But is focused on Cisco devices.
>
> We even considered fork it to our specific vendor.
> But before reinventing the wheel, I decide to ask to colleagues if anybody
> knows some tool that converts BGP Flowspec ACLs into YAML or even to YANG.
>
> If that exists, with Ansible/Netconf/RestConf(or some similar tool), it
> would be easy to delegate to Switchs doing the basic filtering that only
> More expensive Routers can do by now.
>
>
> P.S.: This Idea does not include(on the first moment) more
> complex features of Flowspec like Redirect ou Rate-Limt.
>
> Any suggestions or ideas?
>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

Re: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table

[Jon Lewis]

On Mon, 15 Jun 2020, Mike Leber via NANOG wrote:


I'm pleased to announce Hurricane Electric has completed our RPKI
INVALID filtering project and we now have 0 RPKI INVALIDs in our routing
table.

Hurricane Electric has 29021 BGP sessions with 22109 prefix filters with
7191 networks directly and 8239 networks including Internet exchanges.


The flip side of this though is that every time an IP space owner 
publishes an ROA for an aggregate IP block and overlooks the fact that 
they have customers BGP originating a subnet of the aggregate with an ASN 
not permitted by an ROA, HE has "less than a full table".  :(


i.e. I'm questioning whether the system is mature enough and properly used 
widely enough for dropping RPKI invalids to be a good idea?


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Cogent sales reps who actually respond

[Robert Blayzor]

On 9/16/19 9:30 AM, Jon Sands wrote:
> The last time I dealt with them, it took a little over 3 months to get
> them to turn up basic BGP service. To top it off the sales rep was fired
> in the middle of our deployment. Cogent seems to have higher rep
> turnover than anything else I've dealt with. Buckle up and have fun!


They are truly ridiculous to deal with. Turning up a new 10G dual stack
link with BGP. At turn-up time they tell us we have to order BGP for
IPv6 separately. So you order a circuit with IPv4+IPv6 w/ BGP, but it
doesn't click to them you need it for both AF's? Assuming (wrong) that
maybe they can do both over AF's over the same session, NOPE!...

To top it off, they refuse to enable something as simple as TTL security
on your BGP peering session... but "Oh you can do MD5". Wait, what?

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table

[Saku Ytti]

On Wed, 17 Jun 2020 at 17:28, Jon Lewis  wrote:

> The flip side of this though is that every time an IP space owner
> publishes an ROA for an aggregate IP block and overlooks the fact that
> they have customers BGP originating a subnet of the aggregate with an ASN
> not permitted by an ROA, HE has "less than a full table".  :(

It's hard to imagine RPKI doing its MVP function as a flip side.

If this argument is against RPKI fundamentally, I can understand it,
but that ship has sailed.
-- 
  ++ytti

Re: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table

[Mark Tinka]

On 17/Jun/20 16:25, Jon Lewis wrote:

>
> The flip side of this though is that every time an IP space owner
> publishes an ROA for an aggregate IP block and overlooks the fact that
> they have customers BGP originating a subnet of the aggregate with an
> ASN not permitted by an ROA, HE has "less than a full table".  :(

This is a known business use-case and it's incumbent upon the address
and AS holders to co-ordinate this.

We dropped some prefixes due to this in October of last year. Once we
raised the issue with the remote network, it was fixed in 30 minutes.


>
> i.e. I'm questioning whether the system is mature enough and properly
> used widely enough for dropping RPKI invalids to be a good idea?

Well, if we don't deploy, nothing matures.

The problems we hit in the field will help to make the entire system
better.

Mark.

Re: Cogent sales reps who actually respond

[Mark Tinka]

On 17/Jun/20 16:30, Robert Blayzor wrote:

>
> They are truly ridiculous to deal with. Turning up a new 10G dual stack
> link with BGP. At turn-up time they tell us we have to order BGP for
> IPv6 separately. So you order a circuit with IPv4+IPv6 w/ BGP, but it
> doesn't click to them you need it for both AF's? Assuming (wrong) that
> maybe they can do both over AF's over the same session, NOPE!...

Confused - were you asking that them to carry both address families over
a single BGP session?

Mark.

Mystery CDN

[Clinton Work]

I'm struggling to determine which CDN owns the servers in CenturyLink prefix 
8.240.0.0/12.   During the Call of Duty Season 4 update on June 11th from 06:00 
UTC until 08:30 UTC, we had 240 Gbps of traffic steaming into our network from 
CenturyLink prefix 8.240.0.0/12.   We originally thought it was Akamai, but 
they swear up and down that the servers don't belong to them.   

Here are some of the HTTP/HTTPS servers in 8.240.0.0/12:
8.253.151.248 
8.251.135.126 
8.240.167.126
8.240.228.126
8.240.168.126
8.240.126.254
8.240.191.254


--
Clinton Work
Airdrie, AB

Re: Mystery CDN

[Stephen Satchell]

On 6/17/20 8:29 AM, Clinton Work wrote:

I'm struggling to determine which CDN owns the servers in CenturyLink prefix 
8.240.0.0/12.   During the Call of Duty Season 4 update on June 11th from 06:00 
UTC until 08:30 UTC, we had 240 Gbps of traffic steaming into our network from 
CenturyLink prefix 8.240.0.0/12.   We originally thought it was Akamai, but 
they swear up and down that the servers don't belong to them.

Here are some of the HTTP/HTTPS servers in 8.240.0.0/12:
8.253.151.248
8.251.135.126
8.240.167.126
8.240.228.126
8.240.168.126
8.240.126.254
8.240.191.254


You might ask Level3.

Re: Mystery CDN

[niels=nanog]

* clin...@scripty.com (Clinton Work) [Wed 17 Jun 2020, 17:31 CEST]:
I'm struggling to determine which CDN owns the servers in 
CenturyLink prefix 8.240.0.0/12.  During the Call of Duty Season 4 
update on June 11th from 06:00 UTC until 08:30 UTC, we had 240 Gbps 
of traffic steaming into our network from CenturyLink prefix 
8.240.0.0/12.  We originally thought it was Akamai, but they swear 
up and down that the servers don't belong to them.


Akamai:

% curl -sv http://95.100.96.208/ |& fgrep Server:
< Server: AkamaiGHost



Here are some of the HTTP/HTTPS servers in 8.240.0.0/12:
8.253.151.248
8.251.135.126
8.240.167.126
8.240.228.126
8.240.168.126
8.240.126.254
8.240.191.254


Not Akamai:

% curl -sv http://8.240.191.254/ |& fgrep Server:
< Server: FP6.1.1866.55

Have you tried a Shodan search for this fingerprint?

HTH,


-- Niels.

Re: RPKI race

[Melchior Aelmans]

Hi all,

We (Juniper) are aware of the challenges with internet-in-a-VRF and RPKI
OV. Hence work is in progress to solve some of these issues.
If there's news (and I remember this promise) I will update. Feel free to
ping me.

Cheers,
Melchior

On Wed, Jun 17, 2020 at 10:30 AM Mark Tinka  wrote:

>
>
> On 17/Jun/20 10:20, Baldur Norddahl wrote:
>
>
>
> On Wed, Jun 17, 2020 at 10:07 AM Niels den Otter <
> niels.denot...@surfnet.nl> wrote:
>
>> Hello Baldur,
>>
>> If you want to validate routes in a VRF you need to configure;
>>
>> set routing-options validation notification-rib 
>>
>> Have you done so?
>>
>>
>>
> That was missing from the config. After adding it and running the command
> "request validation policy" I got the prefixes validated.
>
>
> Not to sound funny, but this is one of the reasons I am still afraid to
> run the Internet in a VRF. There are a lot more things to consider, I've
> often found, compared to what you take for granted in the global table.
>
> That said, this is great to know, given that many operators run the
> Internet in a VRF, and we need RPKI + ROV to be supported far and wide.
>
> Mark.
>

Re: Mystery CDN

[Justin Oeder]

Former Level3 operates a CDN.  Might be worth looking into.

On Wed, Jun 17, 2020, 11:43 AM Stephen Satchell  wrote:

> On 6/17/20 8:29 AM, Clinton Work wrote:
> > I'm struggling to determine which CDN owns the servers in CenturyLink
> prefix 8.240.0.0/12.   During the Call of Duty Season 4 update on June
> 11th from 06:00 UTC until 08:30 UTC, we had 240 Gbps of traffic steaming
> into our network from CenturyLink prefix 8.240.0.0/12.   We originally
> thought it was Akamai, but they swear up and down that the servers don't
> belong to them.
> >
> > Here are some of the HTTP/HTTPS servers in 8.240.0.0/12:
> > 8.253.151.248
> > 8.251.135.126
> > 8.240.167.126
> > 8.240.228.126
> > 8.240.168.126
> > 8.240.126.254
> > 8.240.191.254
>
> You might ask Level3.
>
>

IPv4 routes spiking from 10PM EST until 8AM EST

[Drew Weaver]

Has anyone noticed over the last week or so that the IPv4 routes appear to be 
spiking up temporarily every night from about 10PM EST until about 8AM EST?

Is that just someone trying to test flipping over other network's TCAMs?

Just wondering.

Devil's Advocate - Segment Routing, Why?

[Mark Tinka]

Hi all.

When the whole SR concept was being first dreamed up, I was mildly
excited about it. But then real life happened and global deployment (be
it basic SR-MPLS or SRv6) is what it is, and I became less excited. This
was back in 2015.

All the talk about LDPv6 this and last week has had me reflecting a
great deal on where we are, as an industry, in why we are having to
think about SR and all its incarnations.

So, let me be the one that stirs up the hornets' nest...

Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?

I've heard a lot about "network programmability", e.t.c., but can anyone
point me toward a solution that actually does this in the way that it
has been touted for years? A true flow that shows the implementation of
"network programming" over any incarnation of SR? Perhaps one a customer
can go to the shop and grab off the shelf?

A lot of kit does not currently support SR, be it in hardware or
software. So are operators expected to dispose of boxes that are happily
moving MPLS frames along with no complaints, and replace them with some
newfangled creations that will support SR in code and silicon? At whose
cost? Not just money, but time, people and working the day-to-day kinks out?

I've heard about "end-to-end service chaining" as a use-case for SR. To
service-chain what? Classic telco's don't offer complex over-the-top
services that operate at a such a scale that "service chaining" in SR
would make lives easier. More than half of the traffic we are carrying
is coming in over the public Internet, and not some private VPN. And if
"service chaining" makes sense to the cloud and content operators who
run humongous data centres where the servers significantly outnumber the
routing/switching/transport gear, I'd naively posit that they have built
a myriad of custom, in-house solutions, systems, tools and controllers
to do all the "service chaining" they could ever need, and have been at
it for more than 10 years, if not more, all to manage an MPLS/DWDM
backbone. So what off-the-shelf "service chaining" controller are they
going to walk into the shop and pay money for?

If I had to think of the number of network, content and cloud operators
who have either said they've deployed some kind of SR, or intend to,
you're looking at probably 10% - 15% of a market. What about the other
85% - 90% of the operators whose requirements are so simple, thinking
about dumping existing boxes, systems, tools and solutions that work
very well in order to join the SR club doesn't seem feasible. What
problems are 90% of the operators running MPLS having that SR will truly
fix, given that they don't operate large, distributed data centres or
have a 5G license?

What's even more wild, is that there are equally a number of networks
that are stalling IPv6 deployment, for some reason or other, meaning it
will probably take us another 1 to 2 decades to see worldwide adoption
of IPv6. If SRv6 or SRv6+ is "where the market is dying to go", and a
bunch of operators don't have IPv6 in their plans, what gives?

To be clear, I'm not against SR; what has to come will come. What I am
less enthused about is being forced into an all-or-nothing scenario for
the going concern of my network. For those that are keen on SR, give
them SR. But for those who would prefer to keep things simple in
networks that are not about to fall over and die, let's have LDPv6 and
let's implement RFC 7439.

Then let the operators choose.

On a personal note, it's a pity Juniper gave in to the SRv6 fight,
despite all the initial resistance. If they'd gone a different direction
and simply implemented RFC 7439 (they have LDPv6 already), not only
would that have put Cisco under serious pressure, but it would have
solved the problems of many network operators that are desperately
looking to go IPv6-only, and still maintain the rich MPLS services they
and their customers have grown to like.

Mark.

Re: Mikrotik RPKI Testing

[Job Snijders]

Dear all,

> I noticed that Mikrotik has added RPKI into their very much beta v7
> branch. I would like to ask those of you that know RPKI well to check
> it out and offer Mikrotik feedback on what they've done
> right\wrong\broken. 

Our hero Massimiliano Stucchi in Switzerland started doing the legwork.
He is is sharing the test results here:

http://as58280.net/en/articles/RPKI-on-Mikrotik

Enjoy!

Kind regards,

Job

Re: Mikrotik RPKI Testing

[Mike Hammett]

Thanks! 


It's nice to see something mostly work on the first try. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Job Snijders"  
To: nanog@nanog.org 
Sent: Wednesday, June 17, 2020 12:19:21 PM 
Subject: Re: Mikrotik RPKI Testing 

Dear all, 

> I noticed that Mikrotik has added RPKI into their very much beta v7 
> branch. I would like to ask those of you that know RPKI well to check 
> it out and offer Mikrotik feedback on what they've done 
> right\wrong\broken. 

Our hero Massimiliano Stucchi in Switzerland started doing the legwork. 
He is is sharing the test results here: 

http://as58280.net/en/articles/RPKI-on-Mikrotik 

Enjoy! 

Kind regards, 

Job 

Re: Devil's Advocate - Segment Routing, Why?

[Saku Ytti]

Hey,

> Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?

I don't like this, SR-MPLS and SRv6 are just utterly different things
to me, and no answer meaningfully applies to both.

I would ask, why do we need LDP, why not use IGP to carry labels?

Less state, protocols, SLOC, cost, bug surface

And we get more features to boot, with LDP if you want LFA, you need
to form tLDP to every Q-space node, on top of your normal LDP, because
you don't know label view from anyone else but yourself. With SR by
nature you know the label view for everyone, thus you have full LFA
coverage for free, by-design.
Also by-design IGP/LDP Sync.

So no need to justify it by any magic new things, it's just a lot
simpler than LDP, you don't need to need new things to justify
SR-MPLS, you need to want to do existing things while reducing
complexity and state.

-- 
  ++ytti

Re: Mystery CDN

[Filip Hruska]

Using Shodan, we can find other nodes belonging to the same CDN by 
searching for "FP6.1.1866.55", which is conveniently present in the 
"Server" HTTP header.


Skimming through the results, it would appear most of the nodes are on 
the Level 3 network. Picking one non-Level3 node at random 
(192.67.191.173) and doing an rDNS lookup reveals the following:


173.191.67.192.in-addr.arpa. 3600 IN    PTR 
LEVEL3-CDN-192-67-191-173.de.kpn-eurorings.net.


There's your answer. "Level 3 CDN".

Kind Regards,
Filip Hruska

On 6/17/20 6:09 PM, Justin Oeder wrote:

Former Level3 operates a CDN.  Might be worth looking into.

On Wed, Jun 17, 2020, 11:43 AM Stephen Satchell > wrote:


On 6/17/20 8:29 AM, Clinton Work wrote:
> I'm struggling to determine which CDN owns the servers in
CenturyLink prefix 8.240.0.0/12 .   During
the Call of Duty Season 4 update on June 11th from 06:00 UTC until
08:30 UTC, we had 240 Gbps of traffic steaming into our network
from CenturyLink prefix 8.240.0.0/12 .   We
originally thought it was Akamai, but they swear up and down that
the servers don't belong to them.
>
> Here are some of the HTTP/HTTPS servers in 8.240.0.0/12
:
> 8.253.151.248
> 8.251.135.126
> 8.240.167.126
> 8.240.228.126
> 8.240.168.126
> 8.240.126.254
> 8.240.191.254

You might ask Level3.

Re: Mikrotik RPKI Testing

[Massimiliano Stucchi]

On 17/06/2020 19:38, Mike Hammett wrote:
> Thanks!
> 
> It's nice to see something mostly work on the first try.

Mostly.

I'm only living without IPv6 for the moment, which is painful... :)

Ciao!
-- 
Massimiliano Stucchi
MS16801-RIPE
Twitter/Telegram: @stucchimax



signature.asc
Description: OpenPGP digital signature

Re: Mikrotik RPKI Testing

[Sander Steffann]

> Mostly.
> 
> I'm only living without IPv6 for the moment, which is painful... :)

OMG!!! Max, I'm so sorry to hear that :'(



signature.asc
Description: Message signed with OpenPGP

Re: Mikrotik RPKI Testing

[Bryan Fields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 6/17/20 2:06 PM, Massimiliano Stucchi wrote:
> I'm only living without IPv6 for the moment, which is painful...
Fyi, your signature is bad on that email.

How is IPv6 coming on Mikrotik?  It's a no-go at least for my deployment on
6.4 code.  Not sure I want to run beta in a quasi-production network.

Thanks,
- -- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl7qYXkACgkQYTmgYVLG
kUA5Lg/+OZnB5Kbo6rthl1xxTLfIwP+A3hAHGJgT5v+W4kbCqXpZzZM0nDL/v7gE
XaR/PXxRC25g5TlN7hSnt+qpgAnl03poO6CO/qMW9umrniuOueuDBFsSebk63elH
SS8G9Rv4qRfmMQ/3bzB+A3jITP/SLndXK4BK+CGTiZqCUfKHFdiLggmUSH2UZRxG
/qmrM5RKeLf0RP32Vn8Oz9Q2RYfTrBACMDffi9K8xfifgTB3WJmStDWVUcl+hjvB
zeQQ6Oi6Phvx5+V1JOjEdCr0EmOIUlqiMatCGfG0LObLXyQacQ7YDhoaAxFw2isN
DOCc1vO/Cn1t6EOh3RfPAxvPpR/QJnNKHUoE9OuakdrYSjC6YAvQecBU68w3/yoz
1T+o1fXVvmBCgHrH8M40NrB9hhfZi2ou1MnhVH30oO8nxdF9xIUKUwlYo6K7Hv37
Co1LUAeGlIbCxB4Dfy1ySU/+RmBCkWPnaQSiHbCsGLlwGs+nWIrUbrf5SMDB2ylu
C/VQ4hnSNl94a0jFFs6F5+n4TIPBO0DFXEqC6L3BJTQ75/YKXfeDc1f0GdJSYGeQ
xAvSIMA4AJAjjy9idpD3gkmRTnO938bByqtgPx0v4AD9OzeUkKo8UrnFN46rEi/+
wfNc9rMbs4zas2Kbjb3djKjzHK4YiEl6aG/SqtMEIf0k7qms52w=
=hzdI
-END PGP SIGNATURE-

Re: Devil's Advocate - Segment Routing, Why?

[Dave Bell]

On Wed, 17 Jun 2020 at 18:42, Saku Ytti  wrote:

> Hey,
>
> > Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?
>
> I don't like this, SR-MPLS and SRv6 are just utterly different things
> to me, and no answer meaningfully applies to both.
>

I don't understand the point of SRv6. What equipment can support IPv6
routing, but can't support MPLS label switching?

I'm a big fan of SR-MPLS however.




> And we get more features to boot, with LDP if you want LFA, you need
> to form tLDP to every Q-space node, on top of your normal LDP, because
> you don't know label view from anyone else but yourself. With SR by
> nature you know the label view for everyone, thus you have full LFA
> coverage for free, by-design.


Not just this, but the LFA path is always the post-convergence path. You
don't get microloops.

You can implement TE on top if that is your thing. No need to run RSVP.
Another protocol you don't need to run.

You don't need to throw out all your old kit, and replace with new in one
go. You can incrementally roll it out, and leave islands of LDP where
needed. LDP-SR interworking is pretty simple.

We are currently introducing it into our core. It will probably be a while
before we fully phase out LDP, but its definitely on the roadmap.

Regards,
Dave

RE: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table

[Tim Warnock]

> On 17/Jun/20 16:25, Jon Lewis wrote:
> > The flip side of this though is that every time an IP space owner
> > publishes an ROA for an aggregate IP block and overlooks the fact that
> > they have customers BGP originating a subnet of the aggregate with an
> > ASN not permitted by an ROA, HE has "less than a full table".  :(
> 
> This is a known business use-case and it's incumbent upon the address
> and AS holders to co-ordinate this.
> 
> We dropped some prefixes due to this in October of last year. Once we
> raised the issue with the remote network, it was fixed in 30 minutes.
>
> Mark.

How did you know? Is there some monitoring system available to let you know or 
do you have your own?
-Tim

Network card with relay in case of power failure

[Dovid Bender]

Hi,

I am sorry if this is off topic.I was once demoed a network device that had
two interfaces. The traffic would go through the device. If there was a
power cut or some other malfunction there would be a relay that would
physically bridge the two network interfaces so the traffic would flow as
if it was just a network cable. Is anyone aware of such a network card or
device?

TIA.

Re: Network card with relay in case of power failure

[Roel Parijs]

Hello,

I've seen something similar with Corero. Have a look at their SmartWall
NETWORK BYPASS APPLIANCE.

Roel

On Wed, Jun 17, 2020 at 10:16 PM Dovid Bender  wrote:

> Hi,
>
> I am sorry if this is off topic.I was once demoed a network device that
> had two interfaces. The traffic would go through the device. If there was a
> power cut or some other malfunction there would be a relay that would
> physically bridge the two network interfaces so the traffic would flow as
> if it was just a network cable. Is anyone aware of such a network card or
> device?
>
> TIA.
>
>
>

Re: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table

[Job Snijders]

Dear Jon, group,

On Wed, Jun 17, 2020 at 10:25:14AM -0400, Jon Lewis wrote:
> On Mon, 15 Jun 2020, Mike Leber via NANOG wrote:
> 
> > I'm pleased to announce Hurricane Electric has completed our RPKI
> > INVALID filtering project and we now have 0 RPKI INVALIDs in our routing
> > table.
> > 
> > Hurricane Electric has 29021 BGP sessions with 22109 prefix filters with
> > 7191 networks directly and 8239 networks including Internet exchanges.
> 
> The flip side of this though is that every time an IP space owner publishes
> an ROA for an aggregate IP block and overlooks the fact that they have
> customers BGP originating a subnet of the aggregate with an ASN not
> permitted by an ROA, HE has "less than a full table".  :(

Do you remember the old BSD paradigm? ... "less is more" 

I think it applies here. We are now in a time where a *smaller* routing
table entry list count is preferable to a 'full' table, because the
fullest table is likely to also include problematic BGP routing
information.

It is important to recognise that RPKI ROA creation is an *OPTIONAL*
protection mechanism. If you create ROAs, you indeed can harm your
network, but at the same time, if you create the ROAs correctly, you
will gain massive benefits.

RPKI ROA creation is a big hammer. Everyone needs to think carefully
about each ROA they create and if it will positively or negatively
impact their network. NTT spend *months* creating ROAs for all the
prefixes, researching for each BGP announcement if the ROA would be good
or bad. We now got virtually all our space covered by ROAs, it'snice.

> i.e. I'm questioning whether the system is mature enough and properly used
> widely enough for dropping RPKI invalids to be a good idea?

Yes. "We made an impossible bird, and it was able to fly". :-)

The global deployment of RPKI ROV in the BGP Default-Free Zone already
is a fact, we made it work! All carriers that keep the Internet
connected together, and care about preventing routing incidents - are
committed to this effort. Thousands of people are now involved at this
point. 

What now remains.. is polishing away some of the sharp edges
[1][2][3][4], and bikeshedding about some of the colors :-)

The below links are like an 'ala carte menu', anyone can engage in
discussions about RPKI at any level they feel comfortable with. Many
people are looking for feedback and input through different forums on
what and how to build it. Pick a platform you enjoy engaging on and
participate (and stick around on this mailing list, all good)! :)

Kind regards,

Job

[1]: https://www.youtube.com/watch?v=oBwAQep7Q7o
[2]: https://mailarchive.ietf.org/arch/msg/sidrops/ayCQbKvJZmE5TGq9IxL9qUM-zQ4/
[3]: https://github.com/RIPE-NCC/rpki-validator-3/issues/158
[4]: https://twitter.com/routinator3000/status/1255439035553779713

Quality of the internet

[Dovid Bender]

Hi,

My 9-5 is working for a VoIP provider. When we started in 2006 we had a lot
of issues with the quality of the internet in eastern europe and central
Asia. It was not rare for us to have to play around with routing to get the
quality that we needed. In a review of tickets for the last two years it
seems as if we barely do any of that these days. Rarely do we get a quality
complaint that comes back to an issue where a carrier or ISP dropping or
mangling packets. Has anyone else observed this as well?

Re: Quality of the internet

[Izzy Goldstein - TeleGo]

now you mentioned it, verizon fios is having issues in NY ?

On Wed, Jun 17, 2020 at 4:50 PM Dovid Bender  wrote:

> Hi,
>
> My 9-5 is working for a VoIP provider. When we started in 2006 we had a
> lot of issues with the quality of the internet in eastern europe and
> central Asia. It was not rare for us to have to play around with routing to
> get the quality that we needed. In a review of tickets for the last two
> years it seems as if we barely do any of that these days. Rarely do we get
> a quality complaint that comes back to an issue where a carrier or ISP
> dropping or mangling packets. Has anyone else observed this as well?
>
>
>

-- 

Izzy Goldstein

Chief Technology Officer

Main: (212) 477-1000 x 2085 <(212)%20477-1000>

Direct: (929) 477-2085

Website: www.telego.com 





Confidentiality Notice: This e-mail may contain confidential and/or
privileged information. If you are not the intended recipient or have
received this e-mail in error please notify us immediately by email reply
and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden. Any
views or opinions presented in this email are solely those of the author
and do not necessarily represent those of TeleGo (T). Employees of TeleGo
are expressly required not to make defamatory statements and not to
infringe or authorize any infringement of copyright or any other legal
right by email communications. Any such communication is contrary to TeleGo
policy and outside the scope of the employment of the individual concerned.
TeleGo will not accept any liability in respect of such communication, and
the employee responsible will be personally liable for any damages or other
liability arising.


TeleGo Hosted PBX 

Re: Network card with relay in case of power failure

[TJ Trout]

check with lannerinc, they sell x86 devices with this bypass function

On Wed, Jun 17, 2020 at 1:15 PM Dovid Bender  wrote:

> Hi,
>
> I am sorry if this is off topic.I was once demoed a network device that
> had two interfaces. The traffic would go through the device. If there was a
> power cut or some other malfunction there would be a relay that would
> physically bridge the two network interfaces so the traffic would flow as
> if it was just a network cable. Is anyone aware of such a network card or
> device?
>
> TIA.
>
>
>

RE: Devil's Advocate - Segment Routing, Why?

[adamv0025]

> From: NANOG  On Behalf Of Mark Tinka
> Sent: Wednesday, June 17, 2020 6:07 PM
> 
> 
> I've heard a lot about "network programmability", e.t.c., 
First of all the "SR = network programmability" is BS, SR = MPLS, any 
programmability we've had for MPLS since ever works the same way for SR. 

> but can anyone
> point me toward a solution that actually does this in the way that it has been
> touted for years? A true flow that shows the implementation of "network
> programming" over any incarnation of SR? Perhaps one a customer can go to
> the shop and grab off the shelf?
> 
Yes anything that works for RSVP-TE (i.e. PCEP), if you want to play there's 
this free app on top of ODL(acting as PCEP+BGP-LS) to program LSPs (can't 
recall the name).
  

> I've heard about "end-to-end service chaining" as a use-case for SR. 
"service chaining" = traffic-engineering, you can do that with or without SR 
just fine.

> To
> service-chain what? 
To service-chain DC or as hipsters call it "cloud" stuff. To TE path from VM to 
FW to ...whatever, or to TE mice flows around elephant flows. 

> Classic telco's don't offer complex over-the-top services
They do via telco cloud. 

> What problems are 90% of the
> operators running MPLS having that SR will truly fix,
> 
None,  
The same point I was trying to get across in our LDPv6 (or any v6 in 
control-plane or management plane for that matter) discussion, there's no 
problem to solve. 
Personally I'll be doing SR only in brand new greenfield deployments or if I 
start running out of RSVP-TE scale on existing deployments.   


adam

Re: Quality of the internet

[Dovid Bender]

Yes. We have gotten a lot fo complaints today. Can't seem to nail it down.
Random PL.


On Wed, Jun 17, 2020 at 4:52 PM Izzy Goldstein - TeleGo <
igoldst...@telego.net> wrote:

> now you mentioned it, verizon fios is having issues in NY ?
>
> On Wed, Jun 17, 2020 at 4:50 PM Dovid Bender  wrote:
>
>> Hi,
>>
>> My 9-5 is working for a VoIP provider. When we started in 2006 we had a
>> lot of issues with the quality of the internet in eastern europe and
>> central Asia. It was not rare for us to have to play around with routing to
>> get the quality that we needed. In a review of tickets for the last two
>> years it seems as if we barely do any of that these days. Rarely do we get
>> a quality complaint that comes back to an issue where a carrier or ISP
>> dropping or mangling packets. Has anyone else observed this as well?
>>
>>
>>
>
> --
>
> Izzy Goldstein
>
> Chief Technology Officer
>
> Main: (212) 477-1000 x 2085 <(212)%20477-1000>
>
> Direct: (929) 477-2085
>
> Website: www.telego.com 
>
>
> 
>
>
> Confidentiality Notice: This e-mail may contain confidential and/or
> privileged information. If you are not the intended recipient or have
> received this e-mail in error please notify us immediately by email reply
> and destroy this e-mail. Any unauthorized copying, disclosure or
> distribution of the material in this e-mail is strictly forbidden. Any
> views or opinions presented in this email are solely those of the author
> and do not necessarily represent those of TeleGo (T). Employees of TeleGo
> are expressly required not to make defamatory statements and not to
> infringe or authorize any infringement of copyright or any other legal
> right by email communications. Any such communication is contrary to TeleGo
> policy and outside the scope of the employment of the individual concerned.
> TeleGo will not accept any liability in respect of such communication, and
> the employee responsible will be personally liable for any damages or other
> liability arising.
>
>
> TeleGo Hosted PBX 
>

Re: Network card with relay in case of power failure

[Yang Yu]

something like 
https://www.chelsio.com/wp-content/uploads/2012/02/B420-021412.pdf
?

On Wed, Jun 17, 2020 at 1:16 PM Dovid Bender  wrote:
>
> Hi,
>
> I am sorry if this is off topic.I was once demoed a network device that had 
> two interfaces. The traffic would go through the device. If there was a power 
> cut or some other malfunction there would be a relay that would physically 
> bridge the two network interfaces so the traffic would flow as if it was just 
> a network cable. Is anyone aware of such a network card or device?
>
> TIA.
>
>

Re: Network card with relay in case of power failure

[Dovid Bender]

Yes TY.


On Wed, Jun 17, 2020 at 5:15 PM Yang Yu  wrote:

> something like
> https://www.chelsio.com/wp-content/uploads/2012/02/B420-021412.pdf
> ?
>
> On Wed, Jun 17, 2020 at 1:16 PM Dovid Bender  wrote:
> >
> > Hi,
> >
> > I am sorry if this is off topic.I was once demoed a network device that
> had two interfaces. The traffic would go through the device. If there was a
> power cut or some other malfunction there would be a relay that would
> physically bridge the two network interfaces so the traffic would flow as
> if it was just a network cable. Is anyone aware of such a network card or
> device?
> >
> > TIA.
> >
> >
>

Re: Network card with relay in case of power failure

[Joel Jaeggli]

> On Jun 17, 2020, at 13:14, Dovid Bender  wrote:
> 
> Hi,
> 
> I am sorry if this is off topic.I was once demoed a network device that had 
> two interfaces. The traffic would go through the device. If there was a power 
> cut or some other malfunction there would be a relay that would physically 
> bridge the two network interfaces so the traffic would flow as if it was just 
> a network cable. Is anyone aware of such a network card or device?

that kind of device is an ethernet bypass tap.  the device is relay driven and 
closes when it loses power bypassing the in-band device.

there are others which require that they remain powered, but use a heatbeat of 
some flavor to detect failures and switch the path accordingly.

copper tap infrastructure has kind of fallen out of favor as ports have gotten 
faster (vs just spanning on a switch or router or passive optical taps) but it 
still exists.

gigamon / niagra and a number of white-box  tap manufactures make device that 
would be referred to as active bypass taps.

> 
> TIA.
> 
> 

Re: Network card with relay in case of power failure

[TJ Trout]

'network bypass adapter' seems to yield results on eBay.

On Wed, Jun 17, 2020 at 2:15 PM Yang Yu  wrote:

> something like
> https://www.chelsio.com/wp-content/uploads/2012/02/B420-021412.pdf
> ?
>
> On Wed, Jun 17, 2020 at 1:16 PM Dovid Bender  wrote:
> >
> > Hi,
> >
> > I am sorry if this is off topic.I was once demoed a network device that
> had two interfaces. The traffic would go through the device. If there was a
> power cut or some other malfunction there would be a relay that would
> physically bridge the two network interfaces so the traffic would flow as
> if it was just a network cable. Is anyone aware of such a network card or
> device?
> >
> > TIA.
> >
> >
>

Yahoo Email NOC

[Fawcett, Nick via NANOG]

Could someone from Yahoo email NOC contact me offline.  We have been getting 
complains from our users trying to send to yahoo.com addresses. Email is 
getting deliverd, but randomly going into the Yahoo users spam folder.  Thanks.

~Nick

-- 
Checked by SOPHOS http://www.sophos.com

Re: Devil's Advocate - Segment Routing, Why?

[Tom Hill]

On 17/06/2020 18:38, Saku Ytti wrote:
>> Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?
> I don't like this, SR-MPLS and SRv6 are just utterly different things
> to me, and no answer meaningfully applies to both.
> 
> I would ask, why do we need LDP, why not use IGP to carry labels?
> 
> Less state, protocols, SLOC, cost, bug surface
> 
> And we get more features to boot, with LDP if you want LFA, you need
> to form tLDP to every Q-space node, on top of your normal LDP, because
> you don't know label view from anyone else but yourself. With SR by
> nature you know the label view for everyone, thus you have full LFA
> coverage for free, by-design.
> Also by-design IGP/LDP Sync.
> 
> So no need to justify it by any magic new things, it's just a lot
> simpler than LDP, you don't need to need new things to justify
> SR-MPLS, you need to want to do existing things while reducing
> complexity and state.


Unsurprisingly, there would be no way on Earth that I could have said
that better, so you shall find only loud cheering from over here.

-- 
Tom

Re: Devil's Advocate - Segment Routing, Why?

[Mark Tinka]

On 17/Jun/20 19:38, Saku Ytti wrote:

> I don't like this, SR-MPLS and SRv6 are just utterly different things
> to me, and no answer meaningfully applies to both.

I know they are different, but that was on purpose, because even with
SR-MPLS, there are a couple of things to consider:

  * IOS XR does not appear to support SR-OSPFv3.
  * IOS XE does not appear to support SR-ISISv6.
  * IOS XE does not appear to support SR-OSPFv3.
  * Junos does not appear to support SR-OSPFv3.
  * MPLS/VPN service signaling in IPv6-only networks also has gaps in SR.

So for networks that run OSPF and don't run Juniper, they'd need to move
to IS-IS in order to have SR forward IPv6 traffic in an MPLS
encapsulation. Seems like a bit of an ask. Yes, code needs to be
written, which is fine by me, as it also does for LDPv6.


> I would ask, why do we need LDP, why not use IGP to carry labels?
>
> Less state, protocols, SLOC, cost, bug surface

I'd be curious to understand what bugs you've suffered with LDP in the
last 10 or so years, that likely still have open tickets.

Yes, we all love less state, I won't argue that. But it's the same
question that is being asked less and less with each passing year - what
scales better in 2020, OSPF or IS-IS. That is becoming less relevant as
control planes keep getting faster and cheaper.

I'm not saying that if you are dealing with 100,000 T-LDP sessions you
should not consider SR, but if you're not, and SR still requires a bit
more development (never mind deployment experience), what's wrong with
having LDPv6? If it makes near-as-no-difference to your control plane in
2020 or 2030 as to whether your 10,000-node network is running LDP or
SR, why not have the choice?


>
> And we get more features to boot, with LDP if you want LFA, you need
> to form tLDP to every Q-space node, on top of your normal LDP, because
> you don't know label view from anyone else but yourself. With SR by
> nature you know the label view for everyone, thus you have full LFA
> coverage for free, by-design.
> Also by-design IGP/LDP Sync.
>
> So no need to justify it by any magic new things, it's just a lot
> simpler than LDP, you don't need to need new things to justify
> SR-MPLS, you need to want to do existing things while reducing
> complexity and state.

Again, it's a question of scale and requirements. Some large networks
don't run any RSVP, while some small networks do.

I'm not saying let's not do SR; but for those who want something mature,
and for those who want something new, I don't see a reason why the
choice can't be left up to the operator.

Routers, in 2020, still ship with RIPv2. If anyone wants to use it (as I
am sure there are some that do), who are we to stand in their way, if it
makes sense for them?

Mark.

Re: Devil's Advocate - Segment Routing, Why?

[Mark Tinka]

On 17/Jun/20 20:40, Dave Bell wrote:


> I don't understand the point of SRv6. What equipment can support IPv6
> routing, but can't support MPLS label switching?

Indeed.

Anything that can support LDPv4 today can support LDPv6, in hardware.

SRv6 and SRv6+ is a whole other issue, not to mention the amount of work
needed to write code for it.


> Not just this, but the LFA path is always the post-convergence path.
> You don't get microloops.
>
> You can implement TE on top if that is your thing. No need to run
> RSVP. Another protocol you don't need to run.
>
> You don't need to throw out all your old kit, and replace with new in
> one go. You can incrementally roll it out, and leave islands of LDP
> where needed. LDP-SR interworking is pretty simple.
>
> We are currently introducing it into our core. It will probably be a
> while before we fully phase out LDP, but its definitely on the roadmap.

Happy to hear, and I have nothing against your choice if you are happy
with it.

But for a network that may not see the need in spending cycles doing
yet-another roll out, it tastes funny when you are forced down a new path.

Mark.

Re: Devil's Advocate - Segment Routing, Why?

[Mark Tinka]

On 17/Jun/20 23:07, adamv0...@netconsultings.com wrote:

> First of all the "SR = network programmability" is BS, SR = MPLS, any
> programmability we've had for MPLS since ever works the same way for SR. 

I see it the same way.


> Yes anything that works for RSVP-TE (i.e. PCEP), if you want to play there's 
> this free app on top of ODL(acting as PCEP+BGP-LS) to program LSPs (can't 
> recall the name).

In short, more working and not the panacea it was made out to be. No
problem with that, if you're one to roll your sleeves up.


> "service chaining" = traffic-engineering, you can do that with or without SR 
> just fine.

I don't make the terms up... best-of-breed and all that :-).


> To service-chain DC or as hipsters call it "cloud" stuff. To TE path from VM 
> to FW to ...whatever, or to TE mice flows around elephant flows. 

And how many classic telco's are doing this at scale in a way that only
SR can solve?


> They do via telco cloud. 

What's that :-)?


> None,  
> The same point I was trying to get across in our LDPv6 (or any v6 in 
> control-plane or management plane for that matter) discussion, there's no 
> problem to solve. 
> Personally I'll be doing SR only in brand new greenfield deployments or if I 
> start running out of RSVP-TE scale on existing deployments.   

If I want to remove BGP state in the core (which is a good thing, given
how heavy BGP code and FIB requirements are), LDPv4 and LDPv6 are useful
for native dual-stack networks that do not share fate between either IP
protocol.

But, YMMV on that one :-).

Mark.

Re: Devil's Advocate - Segment Routing, Why?

[Mark Tinka]

On 17/Jun/20 23:46, Tom Hill wrote:

> Unsurprisingly, there would be no way on Earth that I could have said
> that better, so you shall find only loud cheering from over here.

Out of pure curiousity, have you deployed (or are you deploying)?

Mark.

Re: Network card with relay in case of power failure

[Billy Crook]

I have significant experience with these.  Chelsio was the brand we used
for an IPS/IDS device.

They cost a fortune and they caused just as much pain as they saved.
Unless you really think you're likely to go days without power and for some
reason the things on the other end of those copper 300 ft max ethernet
cables will have power but you won't, I do not recommend it.

If you're close enough to use copper ethernet you're close enough to run
another circuit from the UPS.

A major headache is for example, the relays click a couple different times
during boot.  They might also click when you reload the networking stack,
say, to change an IP address on another nic.  Every time, the ethernet
carrier signal is lost and takes a few seconds to come back.  If you're
using stp if could be upwards of 30-40 seconds outage for each flip.  Then
think about all the ways that the software on the server could stop
forwarding packets and the relays wouldn't save you because power is still
on.

The problem with these cards is they are sought on the premise that someone
knows what ethernet is, and they know what a relay does, and ethernet uses
wires, and relays switch wires, so relays can switch ethernet  It's
just more nuanced than that.

Instead, use VLANs:
Get cheap gig nics for the server, any off the shelf managed switch, and a
monitoring node with ssh access to conf the switch.
Designate vlan 100 as the left side vlan, and 101 as the right side vlan.
(for example)
put ports 1 and 2 in vlan 100; 3 and 4 in vlan 101.
Connect the server to ports 2 and 3, and connect the two things you're
wanting to bridge through the server to ports 1 and 4.
The monitoring node should run an arp ping or icmp ping through the server
every 10ms or 1ms or whatever interval you like.
If that ping fails twice in a row, then it immediately connects to the
switch and issues 'switchport access vlan 100 to port 4, and then shutdown
to port 3

Congrats you just created a make-before-break transfer switch for ethernet.
For extra credit, send an alert when this triggers.
You can also put port 3 in vlan 102 instead of shutting it down, and use a
second host in vlan 102 to test that it's really bridging again before you
switch port 4 back to vlan 101.

Because the switching is done with vlans, there is no STP delay, and
because nothing's futzing with the electrical signals, no ethernet carrier
signal loss/re-establishment either.

Remember ethernet takes time to detect if its got gigabit on both sides, or
10/half or 100/full.  Frankly that was a huge problem we had with these
relay cards.

Our servers were normally set to auto auto (and negotiated to gig) but some
ISP CPE would be hard coded to 100/full so we configured to match that.
Then the ISP upgrades their gear and the customer is told to just upgrade
their router.  They ignore our server because these magic relays just push
all traffic through right?  Well when they're bypassing it works fine, then
switch in the server, and after the outage, it works like crap because it
can't go full duplex when the isp cpe isn't negotiating.

And yet another problem, 568a or 568b my friend. which way are each of the
ports and relays configured.  Typically switches are one way and servers
are the opposite right?  So when you bypass, the server and switch are
fine.  But when you takeit out of bypass the switchto your intermediary
server are fine, but the cable between your server and the other host
should use a crossover ethernet cable, or crossover adapter

I hear you.  Yeah, things usually autonegotiate and figure it out.  It
takes longer though.  And it doesn't always work at all. I've been down
this road and it took me a year of pain to come to this conclusion.

Don't do it.

Use VLANs.



On Wed, Jun 17, 2020 at 3:15 PM Dovid Bender  wrote:

> Hi,
>
> I am sorry if this is off topic.I was once demoed a network device that
> had two interfaces. The traffic would go through the device. If there was a
> power cut or some other malfunction there would be a relay that would
> physically bridge the two network interfaces so the traffic would flow as
> if it was just a network cable. Is anyone aware of such a network card or
> device?
>
> TIA.
>
>
>

Re: Router Suggestions

[Warren Kumari]

On Tue, Jun 16, 2020 at 5:28 PM Owen DeLong  wrote:

>
>
> > On Jun 16, 2020, at 1:51 PM, Mark Tinka  wrote:
> >
> >
> >
> > On 16/Jun/20 22:43, Owen DeLong wrote:
> >
> >> Covering them all under vendor contract doesn’t necessarily guarantee
> that
> >> the vendor does, either. In general, if you can cover 10% of your
> hardware
> >> failing in the same 3-day period, you’re probably not going to do much
> better
> >> with vendor support.
> >
> > In my experience, our vendors have been able to abide by their
> > obligations when we've had successive failures in a short period of
> > time, as long as our subscription is up-to-date.
> >
> > I am yet to be disappointed.
> >
>
> Count your blessings… I once faced a situation where a vendor had shipped
> a batch of defective power supplies (10s of thousands of them). It wasn’t
> just my network facing successive failures
> in this case, but widespread across their entire customer base… By day 2,
> all of their depots were depleted and day 3 involved mapping out “how
> non-redundant can we make the power in our
> routers to cover the outages that we’re seeing without causing more
> outages than we solve?”
>
> It was a genuine nightmare.


Huh, was this in the early to mid 1990’s?

I had an incident in NYC area where one of the large (at the time)
datacenter/IXPs had a power outage, and their transfer switch failed to
switch over. Customers were annoyed, so they promised another test, which
also failed, dropping power to the facility again... now customers were
hopping mad...

The next test was *just* of the generator, but with all of the work they
had done they had (somehow) gotten the transfer switch *really* confused /
hardwired into an odd state. This resulted in the facility being powered by
both the street power and the generator (at least for a few seconds until
the generator went “Nope!”)

 These were of course not synchronized, and so 120V equipment saw 0V, then
240V, then some weird harmonic, then other surprising values. .. most
supplies kind of dealt with this OK, but one of the really common models of
router, from the largest vendor upped and died. This resulted in a few
hundred dead routers and way exceeded the vendors spares strategies.

A number of customers (myself included) had 4 hour replacement contracts,
which the vendor really could not meet - so we agreed to take a new, much
larger/better model as a replacement.

W


>
> I’ve had other situations involving early failures of just released line
> cards and such as well.
>
> As I said, YMMV, but I’m betting your vendor doesn’t stock a second copy
> of every piece of covered equipment in the local depot. They’re playing the
> statistical probabilities just
> like anyone else stocking their own spares pool. The biggest difference is
> that they’re
> spreading the risk across a (potentially) much wider sample size which may
> better normalize
> the numbers.
>
> Owen
>
> --
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

Re: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table

[Randy Bush]

> Do you remember the old BSD paradigm? ... "less is more"

s/bsd/mies/   credit where due.  

> We are now in a time where a *smaller* routing table entry list count
> is preferable to a 'full' table, because the fullest table is likely
> to also include problematic BGP routing information.

do you have measurement of that?  i would be *really* interested.

randy

Re: Router Suggestions

[Shawn L via NANOG]

We _always_ have at least one spare, or something that could be (relatively) 
easily pressed into service as one. 
 
Even in the Midwest, we've had times where 'guaranteed next day replacement' is 
more like 2nd or third day due to weather conditions, the carrier routing it 
weird, or just plain the plane didn't come today issues.  We generally laugh 
when they try to offer us 4 hour contracts -- we know there's 0 chance they can 
meet them, and they never want to refund you when you need it and they can't.
 


-Original Message-
From: "Warren Kumari" 
Sent: Wednesday, June 17, 2020 6:50pm
To: "Owen DeLong" 
Cc: nanog@nanog.org
Subject: Re: Router Suggestions






On Tue, Jun 16, 2020 at 5:28 PM Owen DeLong <[ o...@delong.com ]( 
mailto:o...@delong.com )> wrote:

 > On Jun 16, 2020, at 1:51 PM, Mark Tinka <[ mark.ti...@seacom.mu ]( 
 > mailto:mark.ti...@seacom.mu )> wrote:
 > 
 > 
 > 
 > On 16/Jun/20 22:43, Owen DeLong wrote:
 > 
 >> Covering them all under vendor contract doesn’t necessarily guarantee that
 >> the vendor does, either. In general, if you can cover 10% of your hardware
 >> failing in the same 3-day period, you’re probably not going to do much 
 >> better
 >> with vendor support.
 > 
 > In my experience, our vendors have been able to abide by their
 > obligations when we've had successive failures in a short period of
 > time, as long as our subscription is up-to-date.
 > 
 > I am yet to be disappointed.
 > 

 Count your blessings… I once faced a situation where a vendor had shipped a 
batch of defective power supplies (10s of thousands of them). It wasn’t just my 
network facing successive failures
 in this case, but widespread across their entire customer base… By day 2, all 
of their depots were depleted and day 3 involved mapping out “how non-redundant 
can we make the power in our
 routers to cover the outages that we’re seeing without causing more outages 
than we solve?”

 It was a genuine nightmare.
Huh, was this in the early to mid 1990’s?
I had an incident in NYC area where one of the large (at the time) 
datacenter/IXPs had a power outage, and their transfer switch failed to switch 
over. Customers were annoyed, so they promised another test, which also failed, 
dropping power to the facility again... now customers were hopping mad...
The next test was *just* of the generator, but with all of the work they had 
done they had (somehow) gotten the transfer switch *really* confused / 
hardwired into an odd state. This resulted in the facility being powered by 
both the street power and the generator (at least for a few seconds until the 
generator went “Nope!”)
 These were of course not synchronized, and so 120V equipment saw 0V, then 
240V, then some weird harmonic, then other surprising values. .. most supplies 
kind of dealt with this OK, but one of the really common models of router, from 
the largest vendor upped and died. This resulted in a few hundred dead routers 
and way exceeded the vendors spares strategies.
A number of customers (myself included) had 4 hour replacement contracts, which 
the vendor really could not meet - so we agreed to take a new, much 
larger/better model as a replacement.
W

 I’ve had other situations involving early failures of just released line cards 
and such as well.

 As I said, YMMV, but I’m betting your vendor doesn’t stock a second copy of 
every piece of covered equipment in the local depot. They’re playing the 
statistical probabilities just
 like anyone else stocking their own spares pool. The biggest difference is 
that they’re
 spreading the risk across a (potentially) much wider sample size which may 
better normalize
 the numbers.

 Owen

-- 

I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
   ---maf

Re: Quality of the internet

[Jared Geiger]

I think all the eyeball networks moving to work with CDNs a bit better
helped alleviate the congestion on the transit / peering links. DOCSIS 3.1
helped tremendously with jitter issues as well as fiber xPON being deployed
by the telcos.

Transit costs have dropped significantly. So it doesn't seem like the
eyeball networks are running links as hot as they were before. We do still
ask our transit account reps or NOCs where they see chronic congestion and
usually get a straight forward response.

We have seen blips with customers on smaller rural ISPs in both the US and
Canada every now and then but it usually clears up in a day or so which
probably means it was backhaul transport issue.


On Wed, Jun 17, 2020 at 2:11 PM Dovid Bender  wrote:

> Yes. We have gotten a lot fo complaints today. Can't seem to nail it down.
> Random PL.
>
>
> On Wed, Jun 17, 2020 at 4:52 PM Izzy Goldstein - TeleGo <
> igoldst...@telego.net> wrote:
>
>> now you mentioned it, verizon fios is having issues in NY ?
>>
>> On Wed, Jun 17, 2020 at 4:50 PM Dovid Bender  wrote:
>>
>>> Hi,
>>>
>>> My 9-5 is working for a VoIP provider. When we started in 2006 we had a
>>> lot of issues with the quality of the internet in eastern europe and
>>> central Asia. It was not rare for us to have to play around with routing to
>>> get the quality that we needed. In a review of tickets for the last two
>>> years it seems as if we barely do any of that these days. Rarely do we get
>>> a quality complaint that comes back to an issue where a carrier or ISP
>>> dropping or mangling packets. Has anyone else observed this as well?
>>>
>>>
>>>
>>
>> --
>>
>> Izzy Goldstein
>>
>> Chief Technology Officer
>>
>> Main: (212) 477-1000 x 2085 <(212)%20477-1000>
>>
>> Direct: (929) 477-2085
>>
>> Website: www.telego.com 
>>
>>
>> 
>>
>>
>> Confidentiality Notice: This e-mail may contain confidential and/or
>> privileged information. If you are not the intended recipient or have
>> received this e-mail in error please notify us immediately by email reply
>> and destroy this e-mail. Any unauthorized copying, disclosure or
>> distribution of the material in this e-mail is strictly forbidden. Any
>> views or opinions presented in this email are solely those of the author
>> and do not necessarily represent those of TeleGo (T). Employees of TeleGo
>> are expressly required not to make defamatory statements and not to
>> infringe or authorize any infringement of copyright or any other legal
>> right by email communications. Any such communication is contrary to TeleGo
>> policy and outside the scope of the employment of the individual concerned.
>> TeleGo will not accept any liability in respect of such communication, and
>> the employee responsible will be personally liable for any damages or other
>> liability arising.
>>
>>
>> TeleGo Hosted PBX 
>>
>

Re: Yahoo Email NOC

[Tom Beecher]

https://help.yahoo.com/kb/postmaster

On Wed, Jun 17, 2020 at 5:39 PM Fawcett, Nick via NANOG 
wrote:

> Could someone from Yahoo email NOC contact me offline.  We have been
> getting complains from our users trying to send to yahoo.com addresses.
> Email is getting deliverd, but randomly going into the Yahoo users spam
> folder.  Thanks.
>
>
>
> ~Nick
>
> --
> Checked by SOPHOS http://www.sophos.com
>
>

Re: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table

[Randy Bush]

>> Do you remember the old BSD paradigm? ... "less is more"
> s/bsd/mies/   credit where due.

recant.  it was well before mies.  i was just raised by and architect,
and had uni roomies who were in the architecture school mies founded.
so my own narrow vision.  sorry.

randy

Re: Router Suggestions

[Owen DeLong]

> On Jun 17, 2020, at 12:50 AM, Mark Tinka  wrote:
> 
> 
> 
> On 16/Jun/20 23:26, Owen DeLong wrote:
> 
>> Count your blessings…
> 
> I know that we are lucky that in the markets we operate, local depots
> are available. There are other markets in Africa that may not be so
> lucky. If we ever built into those markets, we'd certainly cold spare as
> much as possible, as we used to in the current markets that the vendors
> didn't have local depots for 10 or so years ago.
> 
> 
>> As I said, YMMV, but I’m betting your vendor doesn’t stock a second copy of 
>> every piece of covered equipment in the local depot. They’re playing the 
>> statistical probabilities just
>> like anyone else stocking their own spares pool. The biggest difference is 
>> that they’re
>> spreading the risk across a (potentially) much wider sample size which may 
>> better normalize
>> the numbers.
> 
> Yes, it's just like a bank - they hope not all customers come to
> withdraw all their cash on the same morning.

Yep… FWIW, my experiences were in locations in the US with NFL teams and 
multiple depots proximate to each location. That didn’t help in these cases.

> We run a CRS 4-port 100Gbps line card that I know is not very popular
> among other operators in the markets where we have them. We had one fail
> in a smaller city a few weeks ago. We pay for NBD, not 24/7. A new line
> card arrived promptly, the morning after. I did hold my breath, but they
> managed.

Yeah, that’s far less likely to be a problem than a popular line card or other 
component that turns out to have a bad batch. Generally, they’ll keep at least 
one of everything any customer has in at least one nearby depot. OTOH, I bet if 
you’d had two of those cards fail, you might
have been SOL on the second one for a couple of days.

Owen

Re: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table

[Jon Lewis]

On Wed, 17 Jun 2020, Richa wrote:


Job,



RPKI ROA creation is a big hammer. Everyone needs to think carefully
about each ROA they create and if it will positively or negatively
impact their network.


Could you please shed some more light on the above?

How would ROA negatively impact if ROA(s) is created such that the entire 
prefix set is covered?


Just like I said, if you create an ROA for an aggregate, forgetting that 
you have customers using subnets of that aggregate (or didn't create ROAs 
for customer subnets with the right origin ASNs), you're literally telling 
those using RPKI to verify routes "don't accept our customers' routes." 
That might not be bad for "your network", but it's probably bad for 
someone's.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Mikrotik RPKI Testing

[Bryan Fields]

On 6/17/20 10:38 PM, Musa Stephen Honlue wrote:
> Did you face any issues with IPv6 on 6.4, I personally have participated in 
> deployment projects on Mikrotik for many large networks.
> 
> And it worked well in the end.

The problem I ran into was having it support SLAAC for assignment of IP
addresses for management to a management vlan.  We have a number of them setup
as bridges, and use ipv4 for management now, but can't seem to make them
configure IPv6.

I've run into several issues with them doing bridging as well.  Perhaps the
worst is there's still no way to associate a MAC with a bridge MAC.  This
means we can isolate problem MAC's on an AP level, but then have to dig into
the FDB of each individual node on that AP.

These aren't ideal, but at the price point, we put up with the issues.  :)

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: Client-side information gathering tool

[J. Hellenthal via NANOG]

On Tue, Jun 16, 2020 at 11:30:23AM -0500, Matt Harris wrote:
>Hey folks,
>I was hoping maybe someone could point me in a useful direction here. I'm
>looking into software tools (ideally, they'd support Windows, Mac, and
>Linux, though Windows is perhaps the only critical one) that can be sent
>over to random users with varying (mostly very little) knowledge of how
>the internet works to gather a bunch of data that they can then provide to
>us to help identify connectivity issues between the client and a chosen
>endpoint. IPv4 and IPv6 support are requirements. I've got a lot of
>clients with VPN connections of varying sorts running on internet
>connections of often very low quality, and sometimes even in places where
>reasonable quality doesn't seem to even exist. 
>Right now, when these users complain, this often means my support folks
>get to walk them through downloading winmtr and running that as well as
>other command line tools to gather a bunch of other information about
>their computer, its connection to their LAN, their LAN configuration as
>best as we can tell, and their connection to the greater internet. This is
>somewhat cumbersome of a process though. If we could send them something
>they could click on and then copy/paste out of or otherwise direct the
>data to us, that would save a fair bit of time and also be a lot less
>patience-grating on the part of our clients. 
>Any links to potentially useful tools (commercial or free are both fine)
>would be appreciated. The main goal is getting lots of relevant
>information to us without having to walk an end-user through lots of steps
>to do so. The more relevant data, the better. 
>Thanks,
>Matt
> 
> Matt Harris​ | Infrastructure Lead Engineer 
> 816‑256‑5446 | Direct   
>Looking for something?   
>Helpdesk Portal | Email Support | Billing Portal 
> We build and deliver end‑to‑end IT solutions.   

Since noone else has replied here.

Good to hear from you and thank you for posting something that may be
useful to some others that lurk in the future.

Personally to answer on only my behalf and a few others (mainly corss),
scriptinng your solutions and distributing thhose baseics through
whatever meanns to each provisioned host can go a long way.

e.g.Winderz: \.Bin or \.Support [hidden depending on how much you.
macOS: somewhere suitable to where you want to store them.
Linux: ... (same)

Write the output to a file and open it with the appropriate editor ask
user to hit Ctrl+A & Ctrl+C or the equivelant on other OS's and paste
the contents to you. Form a script to automatically submit it to a
ticket system ?


Ofcourse you could go ansible/salt/etc... and make every user/client cooperate .


If you look for specifics then take advantage of your ability to
provision or package.


-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Devil's Advocate - Segment Routing, Why?

[Robert Raszuk]

>
> Anything that can support LDPv4 today can support LDPv6, in hardware.
>

While I am trying to stay out of this interesting discussion the above
statement is not fully correct.

Yes in the MPLS2MPLS path you are correct,

But ingress and egress switching vectors are very different for LDPv6 as
you need to match on IPv6 vs LDPv4 ingress where you match on IPv4 to map
it to correct label stack rewrite.

Example: If your hardware ASICs do not support IPv6 while support IPv4 -
LDPv4 will work just fine while LDPv6 will have a rather a bit of hard time
:)

Cheers,
R.

Re: Mikrotik RPKI Testing

[Musa Stephen Honlue]

> On 17 Jun 2020, at 22:31, Bryan Fields  wrote:
> 
> How is IPv6 coming on Mikrotik?  It's a no-go at least for my deployment on
> 6.4 code.  Not sure I want to run beta in a quasi-production network.

Did you face any issues with IPv6 on 6.4, I personally have participated in 
deployment projects on Mikrotik for many large networks.

And it worked well in the end.

-- 
Best Regards
-- 
Musa Stephen HONLUE
- Trainer & IPv6 certification Registrar, AFRINIC Ltd. 
- ISOC Online Moderator
= 
Quiet introvert | The One Thing | GTD | Deep Work | Start with why | 4DX | Die 
Empty | Essentialism | 5 AM Club | No Fs|Habits
=
t: +230 57 44 40 41
 | tt: @mhonlue | 
w: 
www.honluemusa.africa
___

Re: Devil's Advocate - Segment Routing, Why?

[Saku Ytti]

On Thu, 18 Jun 2020 at 01:17, Mark Tinka  wrote:

> IOS XR does not appear to support SR-OSPFv3.
> IOS XE does not appear to support SR-ISISv6.
> IOS XE does not appear to support SR-OSPFv3.
> Junos does not appear to support SR-OSPFv3.

The IGP mess we are in is horrible, but I can't blame SR for it. It's
really unacceptable we spend NRE hours developing 3 identical IGP
(OSPFv2, OSPFv3, ISIS). We all pay a 300-400% premium for a single
IGP.

In a sane world, we'd retire all of them except OSPFv3 and put all NRE
focus on there or move some of the NRE dollars to some other problems
we have, perhaps we would have room to support some different
non-djikstra IGP.

In a half sane world, IGP code, 90% of your code would be identical,
then you'd have adapter/ospfv2 adapter/ospfv3 adapter/isis which
translates internal struct to wire and wire to internal struct. So any
features you code, come for free to all of them. But no one is doing
this, it's 300% effort, and we all pay a premium for that.

In a quarter sane world we'd have some CIC, common-igp-container RFC
and then new features like SR would be specified as CIC-format,
instead of OSPFv2, OSPFv3, ISIS and BGP. Then each OSPFv2, OSPFv3,
ISIS and BGP would have CIC-to-x RFC. So people introducing new IGP
features do not need to write 4 drafts, one is enough.

I would include IPv4+IPv6 my-igp-of-choice SR in my RFP. Luckily ISIS
is supported on platforms I care about for IPV4+IPV6, so I'm already
there.

> MPLS/VPN service signaling in IPv6-only networks also has gaps in SR.

I don't understand this.


> So for networks that run OSPF and don't run Juniper, they'd need to move to 
> IS-IS in order to have SR forward IPv6 traffic in an MPLS encapsulation. 
> Seems like a bit of an ask. Yes, code needs to be written, which is fine by 
> me, as it also does for LDPv6.

And it's really just adding TLV, if it already does IPv4 all the infra
should be in place, only  thing missing is transporting the
information. Adding TLV to IGP is a lot less work than LDPv6.

> I'd be curious to understand what bugs you've suffered with LDP in the last 
> 10 or so years, that likely still have open tickets.

3 within a year.
- PR1436119
- PR1428081
- PR1416032

I don't have IOS-XR LDP bugs within a year, but we had a bunch back
when going from 4 to 5. And none of these are cosmetic, these are
blackholing.

I'm not saying LDP is bad, it's just, of course more code lines you
exercise more bugs you see.

But yes, LDP has a lot of bug surface compared to SR, but in _your
network_ lot of that bug surface and complexity is amortised
complexity. So status quo bias is strong to keep running LDP, it is
simpler _NOW_ as a lot of the tax has been paid and moving to an
objectively simpler solution carries risk, as its complexity is not
amortised yet.


> Yes, we all love less state, I won't argue that. But it's the same question 
> that is being asked less and less with each passing year - what scales better 
> in 2020, OSPF or IS-IS. That is becoming less relevant as control planes keep 
> getting faster and cheaper.

I don't think it ever was relevant.

> I'm not saying that if you are dealing with 100,000 T-LDP sessions you should 
> not consider SR, but if you're not, and SR still requires a bit more 
> development (never mind deployment experience), what's wrong with having 
> LDPv6? If it makes near-as-no-difference to your control plane in 2020 or 
> 2030 as to whether your 10,000-node network is running LDP or SR, why not 
> have the choice?

I can't add anything to the upside of going from LDP to SR that I've
not already said. You get more by spending less, it's win:win. Only
reason to stay in LDP is status quo bias which makes short term sense.

> Routers, in 2020, still ship with RIPv2. If anyone wants to use it (as I am 
> sure there are some that do), who are we to stand in their way, if it makes 
> sense for them?

RIP might make sense in some deployments, because it's essentially
stateless (routes age out, no real 'session') so if you have 100k VM
per router that you need to support and you want dynamic routing, RIP
might be the least resistance solution with the highest scale. Timing
wheels should help it scale and maintain great number of timers.

--
  ++ytti

Re: Devil's Advocate - Segment Routing, Why?

[Mark Tinka]

On 18/Jun/20 00:29, Robert Raszuk wrote:

>
> Example: If your hardware ASICs do not support IPv6 while support IPv4
> - LDPv4 will work just fine while LDPv6 will have a rather a bit of
> hard time :)

Well, safe to say that if your box doesn't support IPv6, MPLSv6 is
probably the least of your worries :-).

Mark.

Re: [c-nsp] Devil's Advocate - Segment Routing, Why?

[Mark Tinka]

On 18/Jun/20 02:32, Phil Bedard wrote:
> I look at the basic SR via IGP extensions like VPLS vs. EVPN.   If we had a 
> way to go back in history I'm not sure anyone would have said VPLS was a good 
> idea vs. EVPN.  
>
> There were reasons back in the day why something like SR wasn't done.  The 
> thought of global MPLS labels scared people and source routing was also evil. 
>  So LDP was created to distribute labels hop by hop, while still relying 100% 
> on the IGP to do so.  It kind of defies common sense when you look at it now, 
> but there were supposedly good reasons for it back then.  
>
> SR-MPLS on an existing device supporting MPLS forwarding is a control-plane 
> change, meaning almost any device could support SR-MPLS.  
>
> SR is meant to be data plane agnostic, the SID is just an identifier.  Most 
> support MPLS, some support IPv6.  

Fair enough.

There's still a whole IGP mess to sort out though, not to mention many
years of field experience to bake in.

Mark.