Re: Layer 2 based anycast - Kind like GLBP - Research

[Masataka Ohta]

Douglas Fischer wrote:


I'm looking for solutions do deploy some type of selective high
availability and load balance based on the glue between Layer 2 and Layer 3
(ARP or ND).


If you are looking for L2 anycast, it was purposelessly
invented as a functionality of ND, though it does not
satisfy your requirements. See rfcs 2461 and 4861.

Glad to know it is totally ignored by most, if not all.

Masataka Ohta

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[Andreas Ott]

On Thu, Jul 1, 2021 at 12:56 PM Keith Medcalf  wrote:

> ... and the end carrier is making money for terminating them.


Survey (of n=1) says: nothing has changed, aka the new technology is not
working. I just received the same kind of recorded message call of
"something something renew auto warranty" on my AT u-Verse line. This
time when I called back the displayed caller ID number it was
ring-no-answer, versus the previous "you have reached a number that is no
longer in service". By terminating the call the carrier made probably more
money than it would cost them to enforce the new rules.

Other than the donotcall.gov portal, is there a new way to report the
obvious failure of STIR/SHAKEN?

-andreas

ISP NOC contact at Spectrum and RR.com

[Ray Orsini]

Can anyone at Spectrum and RR.com contact me off list? We've been seeing a ton 
of packet loss in the NE US over the past week affecting voice quality. Thank 
you.

Ray Orsini
Chief Executive Officer
OIT, LLC
 305.967.6756 x1009 |  305.571.6272
 r...@oit.co |  www.oit.co
 oit.co/ray
How are we doing? We'd love to hear your feedback. https://go.oit.co/review

Re: SITR/SHAKEN implementation in effect today (June 30 2021)

[Paul Timmins]

On 7/1/21 3:53 PM, Keith Medcalf wrote:

And this is why this problem will not be solved.  The "open relay" is making money from processing 
the calls, and the end carrier is making money for terminating them.  Until fine(s) -- hopefully millions of 
them, one for each improperly terminated call, together with jail time for the CEO of the company for 
"conspiracy to commit fraud" --  and EACH of the fines is EQUAL OR GREATER than the total yearly 
worldwide REVENUE of that end carrier, they will not have any impetus to "fix" the problem.


How about 47 CFR 64.1200(k)(4)?

(4) A provider may block voice calls or cease to accept traffic from an 
originating or intermediate provider 
 
without liability under the Communications Act or the Commission's rules 
where the originating or intermediate provider 
, 
when notified by the Commission, fails to effectively mitigate illegal 
traffic within 48 hours or fails to implement effective measures to 
prevent new and renewing customers 
 
from using its network to originate illegal calls. Prior to initiating 
blocking, the provider shall provide the Commission with notice and a 
brief summary of the basis for its determination that the originating or 
intermediate provider 
 
meets one or more of these two conditions for blocking.


ie: "You're not really a phone company anymore, says the rest of the PSTN"

https://www.law.cornell.edu/cfr/text/47/64.1200

RE: SITR/SHAKEN implementation in effect today (June 30 2021)

[Keith Medcalf]

>On Wednesday, 30 June, 2021 13:53, Michael Thomas  wrote:

>From an automated standpoint, I really don't care about whether a phone
>number is authentic, I care about the domain that onramped it so I can
>theoretically punish it. It's the people who are allowing the spoofing
>that is the real problem which directly analogous to email open relays.

And this is why this problem will not be solved.  The "open relay" is making 
money from processing the calls, and the end carrier is making money for 
terminating them.  Until fine(s) -- hopefully millions of them, one for each 
improperly terminated call, together with jail time for the CEO of the company 
for "conspiracy to commit fraud" --  and EACH of the fines is EQUAL OR GREATER 
than the total yearly worldwide REVENUE of that end carrier, they will not have 
any impetus to "fix" the problem.

If a law were passed that imposed a $1 million penalty payable by the 
terminating carrier to each subscriber for each such call a subscriber received 
together with a term of 1 year imprisonment at hard labour for the CEO of the 
terminating carrier, the whole issue would be fixed before lunch-time.

THe motivated self-interest however, is to do nothing.  Eventually someone will 
bring a racketeering claim against the terminating carriers and they will then 
be properly "motivated" to stop profiteering off criminal activity.

--
Be decisive.  Make a decision, right or wrong.  The road of life is paved with 
flat squirrels who could not make a decision.

Re: Layer 2 based anycast - Kind like GLBP - Research

[Baldur Norddahl]

tor. 1. jul. 2021 21.06 skrev William Herrin :

>
>
> From what I understand of EVPN, it's about creating something
> equivalent to VLANs across a distributed virtual server
> infrastructure. Basically like what Amazon does under the hood for its
> virtual private cloud. Since you're trying to get the machines to
> appear on the same subnet, not separate them to different subnets, I
> don't think it's what you're looking for.
>


EVPN creates a virtual layer 2 domain, aka a vlan, that can span the
internet or be used on a plain old layer 2 switch. It uses vxlan or mpls
tunnels and BGP to coordinate. EVPN has support for multiple active/active
exits, something almost like lacp. There can be load balancing using layer
3 headers as key, which might be exactly what OP is looking for.

EVPN elimates layer 2 flooding by keeping a database of MAC addresses in
BGP. Otherwise it behaves exactly like a vlan with extra features.

>

Re: Layer 2 based anycast - Kind like GLBP - Research

[William Herrin]

On Thu, Jul 1, 2021 at 11:05 AM Douglas Fischer
 wrote:
> I'm looking for solutions do deploy some type of selective high availability 
> and load balance based on the glue between Layer 2 and Layer 3 (ARP or ND).

Hi Douglas,

Anycast is where you send to one network address and the "nearest"
single server with that address receives the packet.

By definition, every piece of equipment in an L2 broadcast domain is
exactly one hop from every other -- no equipment is "nearer." So
conceptually, there is no anycast.

However, L2 domains aren't built with hubs any more; they're built
with switches. There actually are variable distances between
equipment, they're just not expressed in the protocols. So, in theory
you could build an SDN controller for your switches which sets up
different FIB entries in each switch to select which port receives the
traffic for the designated "anycast" mac address. But you may face
limitations where the hardware can't reasonably be programmed to give
each port its own FIB allowing fine-grained control of which client
reaches which server.

Realistically... that approach would tend to be both expensive to
build and very brittle. There's almost certainly a better way to
accomplish your goal than trying to invent L2 anycast.

If you're load balancing IP traffic, another approach might be a
custom ARP controller which responds to ARP requests with different
MAC addresses depending on the request source. There's no guaranteed
timeout for ARP bindings but if you shared around a pool of MAC
addresses guaranteeing that every MAC address in the pool gets
assigned to a currently-working server it could work. You just have to
keep in mind that gratuitous arp absolutely would not work in this
sort of scenario so you have to have a plan for switching loads
between servers without it.

I don't think anybody has built that sort of arp controller (at least
I haven't heard of one) so you'd have to invent it yourself.

>From what I understand of EVPN, it's about creating something
equivalent to VLANs across a distributed virtual server
infrastructure. Basically like what Amazon does under the hood for its
virtual private cloud. Since you're trying to get the machines to
appear on the same subnet, not separate them to different subnets, I
don't think it's what you're looking for.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Layer 2 based anycast - Kind like GLBP - Research

[Baldur Norddahl]

On Thu, Jul 1, 2021 at 8:04 PM Douglas Fischer 
wrote:

> I friend Suggested that EVPN could help-me, but I must confess that is a
> hard topic to me.
> Unless it can be used depending exclusively on software (no special
> hardware required), it won't fit.
>
>
Linux has EVPN support. Or you could use network switches with EVPN support.

EVPN will let each server or direct connected switch be a hidden layer 3
gateway. The application will not know about it and it will appear to be
layer 2 but routable like layer 3. Which means you can do anycast at layer
3. Physically the packets are moved in tunnels so you can use any layer 2
or layer 3 hardware at your choice.

Regards,

Baldur

Re: Layer 2 based anycast - Kind like GLBP - Research

[colin johnston]

Bigip with each host having two nics on public and private via inter switch 
shared vlan.
Should not cause issue so long as you know service comes via bigip to debug 
usage of kit via private ip side


Sent from my iPod

> On 1 Jul 2021, at 19:04, Douglas Fischer  wrote:
> 
> 
> I'm looking for solutions do deploy some type of selective high availability 
> and load balance based on the glue between Layer 2 and Layer 3 (ARP or ND).
> 
> And I'm coming here to ask help to avoid reinventing the wheel.
> 
> I know VRRP / Heartbeat, and their downside is the Active/Passive 
> characteristic.
>  -> But this project demands something that allows-me to have Active/Active 
> deployments.
> I know GLBP, and it almost fits on the needed requirements.
>  -> Except by his load-balancing methods that do not allow-me define priority 
> and affinity between server nodes and clients.
> 
> The basic ideia is something like Cisco GLBP with steroids:
>  - Multiple server nodes of same service running on a common bus and 
> answering the "L2 anycast requests" of the clients that are on the same bus 
> and same subnet.
>  - Some type of signaling between the multiple nodes making known the status 
> of the other nodes, their load. Maybe complementary information like "which 
> node is serving which client?"
>  - Resource Pools and Client Pools, and the crossing between then based on 
> priorities and affinities (Here is the Gotcha!).
> - I want to be able to say "Node X will priorly serve clients A, E, G, 
> and T. Node Y will serve priorly clients B, C D, F. And node Z will server 
> everyone else."
> 
> Answering suggestions in advance:
> (I discussed that with some friends and based on those talks I will try to 
> predict some suggestions that we already considered.)
> - No, unfortunately tradicional L3 anycast will not fit on the requirements. 
> Servers and clients to be at the same bus, on the same subnet. No L3 hops 
> between then.
> - No, the use of some type of connection broker in L2 does not satisfy one of 
> the requirements. Beyond the load balance, that this approach will address, 
> the high availability in case on L2 segregation is also needed.
> 
> 
> My v0 draft of idea was using GLBP, and L2 Firewall rules dynamically 
> adjusted, based on the Master-Status, to allow and block L2 communications 
> between each of those nodes and lists of client pools.
> (Actually, I'm coming back to this idea again... Since I still don't have any 
> other better idea until now.)
> 
> I friend Suggested that EVPN could help-me, but I must confess that is a hard 
> topic to me.
> Unless it can be used depending exclusively on software (no special hardware 
> required), it won't fit.
> 
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação

Layer 2 based anycast - Kind like GLBP - Research

[Douglas Fischer]

I'm looking for solutions do deploy some type of selective high
availability and load balance based on the glue between Layer 2 and Layer 3
(ARP or ND).

And I'm coming here to ask help to avoid reinventing the wheel.

I know VRRP / Heartbeat, and their downside is the Active/Passive
characteristic.
 -> But this project demands something that allows-me to have Active/Active
deployments.
I know GLBP, and it almost fits on the needed requirements.
 -> Except by his load-balancing methods that do not allow-me define
priority and affinity between server nodes and clients.

The basic ideia is something like Cisco GLBP with steroids:
 - Multiple server nodes of same service running on a common bus and
answering the "L2 anycast requests" of the clients that are on the same bus
and same subnet.
 - Some type of signaling between the multiple nodes making known the
status of the other nodes, their load. Maybe complementary information like
"which node is serving which client?"
 - Resource Pools and Client Pools, and the crossing between then based on
priorities and affinities (Here is the Gotcha!).
- I want to be able to say "Node X will priorly serve clients A, E, G,
and T. Node Y will serve priorly clients B, C D, F. And node Z will server
everyone else."

Answering suggestions in advance:
(I discussed that with some friends and based on those talks I will try to
predict some suggestions that we already considered.)
- No, unfortunately tradicional L3 anycast will not fit on the
requirements. Servers and clients to be at the same bus, on the same
subnet. No L3 hops between then.
- No, the use of some type of connection broker in L2 does not satisfy one
of the requirements. Beyond the load balance, that this approach will
address, the high availability in case on L2 segregation is also needed.


My v0 draft of idea was using GLBP, and L2 Firewall rules dynamically
adjusted, based on the Master-Status, to allow and block L2
communications between each of those nodes and lists of client pools.
(Actually, I'm coming back to this idea again... Since I still don't have
any other better idea until now.)

I friend Suggested that EVPN could help-me, but I must confess that is a
hard topic to me.
Unless it can be used depending exclusively on software (no special
hardware required), it won't fit.

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

UCEPROTECT-NETWORK

[Miguel Mata]

Someone from please contact me offlist.

Thanks.


-- 
Miguel Mata
El Salvador
Comunicaciones IBW El Salvador
tel.: ++(503) 2278-5068
fax: ++(503) 2207-1310
mm...@ibw.com

"La confianza es la mejor conexion"

Re: Google Geo Location Issues

[Hank Nussbacher]

On 30/06/2021 17:43, Jason Kuehl wrote:

Once you have access to isp.google.com your problems are far from over. 
 You would assume that they would use whois info to know which prefix 
belongs to your ASN.  That would be wrong.  If you have, for example, a 
multi-homed customer and you provided them with a smaller prefix (/27) 
from within your larger prefix (/19), and since they are multihomed some 
other ASN announces that smaller prefix (/27), Google will see that and 
invalidate any geo-location info you provide for your /19.  Google 
follows the BGP routing table as authoritative for ownership of prefixes.


Regards,
Hank

Caveat: The views expressed above are solely my own and do not express 
the views or opinions of my employer



This is want I'm working on setting up, here is hoping they approve my 
account.


On Wed, Jun 30, 2021 at 10:30 AM Benjamin Hatton > wrote:


If they are your subnets, and you have your own AS (and possibly
enough traffic to Google, I'm not sure what exactly their criteria
is but we were able to make an account with ~2Gbps peak and no
peering relationships) you can create an account with the Google ISP
Portal (isp.google.com ) which has a self
service tool to upload a csv that will update your prefixes in the
Google IP Geolocation database.  Took ~2 weeks after upload for it
to be reflected in live data.

*Ben Hatton*

*Network Engineer | Haefele Connect*
d:(607)589-8000 | b...@haefeleconnect.com 

**


On Wed, Jun 30, 2021 at 10:21 AM Nate Burke mailto:n...@blastcomm.com>> wrote:

Same here, YoutubeTV Geolocation problem, has one of my subnets
in Tulsa instead of Chicago.  Ticket open for 8 months.  Every
reply was that it was 'with engineering' and no ETA.  I just got
a notice from them last week that they're closing the ticket and
sent a survey to fill out to rate the support received.  I told
them that the issue was still not resolved and never heard back
from them.

On 6/30/2021 8:55 AM, Josh Luthman wrote:

Been months since I was told they'd get it fixed. To be fair
they did say they weren't sure on how long it would take.  I
feel like I've been forgotten about.

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Wed, Jun 30, 2021 at 9:18 AM Mike Hammett mailto:na...@ics-il.net>> wrote:

I've discovered that if you *CAN* get a Google ISP
account, you can manage it all there.

If you can't, well, you're up shit creek without a paddle.



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

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



*From: *"Jason Kuehl" mailto:jason.w.ku...@gmail.com>>
*To: *"NANOG" mailto:nanog@nanog.org>>
*Sent: *Tuesday, June 29, 2021 6:25:06 PM
*Subject: *Google Geo Location Issues

I'm looking for a contact, email, number, smoke signals
for someone at Google I can talk to on geolocation issue.
For some reason Google has labeled our IP ranges
as Belarus when we're located in the states. If anyone can
point me at any contact I would be really happy..

.

-- 
Sincerely,


Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com 





--
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com