Re: Why doesn't "Cloudflare 1.1.1.1" compress root answers?

[Bjørn Mork]

Anurag Bhatia  writes:

> Never realised of such compression on answered. Is this is something well
> documented? Curious.

https://tools.ietf.org/html/rfc1035#section-4.1.4


Bjørn

Re: Why doesn't "Cloudflare 1.1.1.1" compress root answers?

[Jared Mauch]

Yes.. Check 4.1.4 of https://www.ietf.org/rfc/rfc1035.txt


> On Apr 5, 2018, at 4:22 PM, Anurag Bhatia  wrote:
> 
> Hi Bjørn
> 
> 
> Never realised of such compression on answered. Is this is something well
> documented? Curious.
> 
> 

RE: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state

[Naslund, Steve]

Got it.  Do any of those trunks add a new VLAN to the switch that was not 
active before?  If so, that would cause a BPDU over all trunks that allow that 
VLAN.  Even if the port is not up yet, by adding the VLAN to ANY trunk you are 
implying that it should be active on ALL trunks that are not VLAN limited.

Steve

>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joseph Jenkins
>Sent: Thursday, April 05, 2018 4:34 PM
>To: nanog@nanog.org
>Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into 
>err-disable state
>
>Steve let me clarify the config I am applying has nothing to do with an LACP 
>trunk or any of my existing LACP trunks. It is a completely different 
>>configuration on a completely different interface, the only similarity is 
>that I am trying to configure a trunk interface on the Juniper side for 
>>multiple vlans. There is no LACP configuration involved.

Re: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state

[Joseph Jenkins]

This are also no new vlans being used at all. They are all already existing
on the switches involved and nothing is being added. In fact what makes
this even weirder is that I already have that exact same port configuration
running on port 1/0/67 of the Juniper and it doesn't cause me any issues
nor did it cause any issues when the config was applied. This existing port
1/0/67 has gone down/up as the firewall has been rebooted and doesn't cause
any issues or hiccups on the network. For reference the attached firewall
is an ASA which doesn't do spanning tree anyways.

set interfaces ge-1/0/67 description "Firewall Port-2"
set interfaces ge-1/0/67 unit 0 family ethernet-switching interface-mode
trunk
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 9-10
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 29
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 31-32
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 43
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 50-51
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 56
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 58
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 66
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 68
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 90
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 143
set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 170

On Thu, Apr 5, 2018 at 2:34 PM, Joseph Jenkins 
wrote:

> Steve let me clarify the config I am applying has nothing to do with an
> LACP trunk or any of my existing LACP trunks. It is a completely different
> configuration on a completely different interface, the only similarity is
> that I am trying to configure a trunk interface on the Juniper side for
> multiple vlans. There is no LACP configuration involved.
>
> On Thu, Apr 5, 2018 at 2:26 PM, Naslund, Steve 
> wrote:
>
>> It really does not resolve anything it just allows a bad configuration to
>> work.  The guard is there so that if one side is configured as a channel
>> and the other side is not, the channel gets shut down.  Allowing it to
>> remain up can cause a BPDU loop.  Your spanning tree is trying to tell you
>> something, you should listen or you could get really hard to isolate issues.
>>
>> Steven Naslund
>> Chicago IL
>>
>> >-Original Message-
>> >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joseph Jenkins
>> >Sent: Thursday, April 05, 2018 4:16 PM
>> >To: Robert Webb
>> >Cc: nanog@nanog.org
>> >Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into
>> err-disable state
>> >
>> >No there isn't, but from what I am getting responses both onlist and off
>> list is to just run this on the Cisco switches:
>> >
>> >no spanning-tree etherchannel guard misconfig
>> >
>> >and that should resolve the issue.
>> >
>> >Thanks Everyone.
>>
>>
>

Re: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state

[Joseph Jenkins]

Steve let me clarify the config I am applying has nothing to do with an
LACP trunk or any of my existing LACP trunks. It is a completely different
configuration on a completely different interface, the only similarity is
that I am trying to configure a trunk interface on the Juniper side for
multiple vlans. There is no LACP configuration involved.

On Thu, Apr 5, 2018 at 2:26 PM, Naslund, Steve  wrote:

> It really does not resolve anything it just allows a bad configuration to
> work.  The guard is there so that if one side is configured as a channel
> and the other side is not, the channel gets shut down.  Allowing it to
> remain up can cause a BPDU loop.  Your spanning tree is trying to tell you
> something, you should listen or you could get really hard to isolate issues.
>
> Steven Naslund
> Chicago IL
>
> >-Original Message-
> >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joseph Jenkins
> >Sent: Thursday, April 05, 2018 4:16 PM
> >To: Robert Webb
> >Cc: nanog@nanog.org
> >Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into
> err-disable state
> >
> >No there isn't, but from what I am getting responses both onlist and off
> list is to just run this on the Cisco switches:
> >
> >no spanning-tree etherchannel guard misconfig
> >
> >and that should resolve the issue.
> >
> >Thanks Everyone.
>
>

RE: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state

[Naslund, Steve]

It really does not resolve anything it just allows a bad configuration to work. 
 The guard is there so that if one side is configured as a channel and the 
other side is not, the channel gets shut down.  Allowing it to remain up can 
cause a BPDU loop.  Your spanning tree is trying to tell you something, you 
should listen or you could get really hard to isolate issues.

Steven Naslund
Chicago IL  

>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joseph Jenkins
>Sent: Thursday, April 05, 2018 4:16 PM
>To: Robert Webb
>Cc: nanog@nanog.org
>Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into 
>err-disable state
>
>No there isn't, but from what I am getting responses both onlist and off list 
>is to just run this on the Cisco switches:
>
>no spanning-tree etherchannel guard misconfig
>
>and that should resolve the issue.
>
>Thanks Everyone.

RE: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state

[Naslund, Steve]

I am kind of confused by your configuration.  If the Cisco side is configured 
as LACP trunk, then the Juniper side also needs to be configured as LACP 
trunks.  Spanning-tree would be getting confused because the Cisco is treating 
the LACP trunk as a single interface for purposes of spanning-tree (which 
should be configured at the port-channel level),  Juniper is considering them 
to all be individual ports and would be sending BPDUs over each individual 
interface.  The Cisco is correctly error disabling the port because it detects 
individual port BPDUs and determines that the channel is misconfigured.  Or am 
I missing something in your config completely?

If you are configuring ports other than the connected ports as trunks then your 
case makes sense.  One thing that might cause you issue is the VLAN access of 
the LACP trunk.  If one side has an vlan access list and the other side does 
not, you might get a spanning tree error when you configure a port on a new 
VLAN.  Essentially you have a "trunk all" on one side and a new VLAN is showing 
up on a trunk that is not allowed on the other side.  It would also help to see 
your spanning tree configuration (i.e. are both side running the same spanning 
tree mode?).  The clue here is that the event triggers even though the port is 
not up yet.  If you configure a new port on a VLAN that is not currently up, 
the VLAN will come up on all trunks that are allowed to have all VLANs 
immediately.

Steven Naslund
Chicago IL

>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joseph Jenkins
>Sent: Thursday, April 05, 2018 3:58 PM
>To: nanog@nanog.org
>ubject: Juniper Config Commit causes Cisco Etherchannels to go into 
>err-disable state
>
>I have cases open with both Cisco and Juniper on this, but wanted to see if 
>anyone else had seen an issue like this because support has no idea.
>
>I have a Juniper QFX 5100 Core running in Virtual Chassis mode with 4 
>switches. I have 4 separate stacks of Cisco 3750 switches with 2x1GB uplinks 
>>bound into 4 different LACP trunks. I have had it happen twice now where I 
>apply a trunk port config(not an LACP trunk) to a port that isn't a part of 
>>any of the LACP trunks and it causes all 4 of the Etherchannels on the Cisco 
>stacked switches to go into an err-disable state with these
>messages:
>
>Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
>Gi1/0/48, putting Gi1/0/48 in err-disable state
>
>Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
>Po17, putting Gi1/0/48 in err-disable state
>
>Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
>Po17, putting Po17 in err-disable state
>
>Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
>GigabitEthernet1/0/48, changed state to down
>
>Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
>Gi2/0/48, putting Gi2/0/48 in err-disable state (CA-TOR-1-7-2)
>
>Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
>GigabitEthernet2/0/48, changed state to down
>
>Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
>Port-channel17, changed state to down
>
>Here is the config I am applying to the port that has caused this issue to 
>happen twice now:
>
>set interfaces ge-0/0/67 description "Firewall Port"
>set interfaces ge-0/0/67 unit 0 family ethernet-switching interface-mode trunk 
>set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members >9-10 
>set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 29 set 
>interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members >31-32 set 
>interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 43 set 
>interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members >50-51 set 
>interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 56 set 
>interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members >58 set 
>interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 66 set 
>interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 68 >set 
>interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 90 set 
>interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 143 >set 
>interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 170
>
>The issue happens within a couple of minutes of committing the config on the 
>Juniper side, there are no cables plugged into port 0/0/67 so technically 
>>there shouldn't be any BPDU's sent out since there isn't a port change.
>
>Juniper Support wants me to turn on trace option and then run though a bunch 
>of scenarios, the issue is that testing this takes down my network.
>
>Just wanted to put it out there to see if anyone else had run into a situation 
>similar to this.
>
>TIA
>
>Joe

Re: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state

[Joseph Jenkins]

No there isn't, but from what I am getting responses both onlist and off
list is to just run this on the Cisco switches:

no spanning-tree etherchannel guard misconfig

and that should resolve the issue.

Thanks Everyone.

On Thu, Apr 5, 2018 at 2:10 PM, Robert Webb  wrote:

> I don't see any issue with the snippet of the config you provided for the
> "Firewall Port". Is there a chance that the port ge-0/0/67 is referenced
> somewhere else in the Juniper config that when applying your trunk setup is
> causing issues?
>
> Just throw that out off the top of my head and not really thinking it
> through.
>
> Robert
>
> -Original Message-
> From: NANOG  On Behalf Of Joseph Jenkins
> Sent: Thursday, April 5, 2018 4:58 PM
> To: nanog@nanog.org
> Subject: Juniper Config Commit causes Cisco Etherchannels to go into
> err-disable state
>
> I have cases open with both Cisco and Juniper on this, but wanted to see
> if anyone else had seen an issue like this because support has no idea.
>
> I have a Juniper QFX 5100 Core running in Virtual Chassis mode with 4
> switches. I have 4 separate stacks of Cisco 3750 switches with 2x1GB
> uplinks bound into 4 different LACP trunks. I have had it happen twice now
> where I apply a trunk port config(not an LACP trunk) to a port that isn't a
> part of any of the LACP trunks and it causes all 4 of the Etherchannels on
> the Cisco stacked switches to go into an err-disable state with these
> messages:
>
> Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected
> on Gi1/0/48, putting Gi1/0/48 in err-disable state
>
> Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected
> on Po17, putting Gi1/0/48 in err-disable state
>
> Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected
> on Po17, putting Po17 in err-disable state
>
> Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> GigabitEthernet1/0/48, changed state to down
>
> Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected
> on Gi2/0/48, putting Gi2/0/48 in err-disable state (CA-TOR-1-7-2)
>
> Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> GigabitEthernet2/0/48, changed state to down
>
> Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> Port-channel17, changed state to down
>
> Here is the config I am applying to the port that has caused this issue to
> happen twice now:
>
> set interfaces ge-0/0/67 description "Firewall Port"
> set interfaces ge-0/0/67 unit 0 family ethernet-switching interface-mode
> trunk set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan
> members 9-10 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan
> members 29 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan
> members 31-32 set interfaces ge-0/0/67 unit 0 family ethernet-switching
> vlan members 43 set interfaces ge-0/0/67 unit 0 family ethernet-switching
> vlan members 50-51 set interfaces ge-0/0/67 unit 0 family
> ethernet-switching vlan members 56 set interfaces ge-0/0/67 unit 0 family
> ethernet-switching vlan members 58 set interfaces ge-0/0/67 unit 0 family
> ethernet-switching vlan members 66 set interfaces ge-0/0/67 unit 0 family
> ethernet-switching vlan members 68 set interfaces ge-0/0/67 unit 0 family
> ethernet-switching vlan members 90 set interfaces ge-0/0/67 unit 0 family
> ethernet-switching vlan members 143 set interfaces ge-0/0/67 unit 0 family
> ethernet-switching vlan members 170
>
> The issue happens within a couple of minutes of committing the config on
> the Juniper side, there are no cables plugged into port 0/0/67 so
> technically there shouldn't be any BPDU's sent out since there isn't a port
> change.
>
> Juniper Support wants me to turn on trace option and then run though a
> bunch of scenarios, the issue is that testing this takes down my network.
>
> Just wanted to put it out there to see if anyone else had run into a
> situation similar to this.
>
> TIA
>
> Joe
>

Re: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state

[Hunter Fuller]

On Thu, Apr 5, 2018 at 3:58 PM Joseph Jenkins 
wrote:

> Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected
> on Po17, putting Po17 in err-disable state
>

We have to do this on all of our Cisco Port-channels that lead to Brocade
ICX switches:
no spanning-tree etherchannel guard misconfig

If we don't do it, after a couple of days, the Cisco will err-disable the
Port-channel just as you describe. I guess the misconfig detection is
incompatible with the Brocade OS.
We have seen no ill effects from this, as we are using "mode active" on all
our Port-channels. So if there is a misconfiguration, the LAG does not come
up for that port on either end, and we're good.

Hope that helps.



-- 

--
Hunter Fuller
Network Engineer
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Systems and Infrastructure

RE: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state

[Robert Webb]

I don't see any issue with the snippet of the config you provided for the 
"Firewall Port". Is there a chance that the port ge-0/0/67 is referenced 
somewhere else in the Juniper config that when applying your trunk setup is 
causing issues?

Just throw that out off the top of my head and not really thinking it through.

Robert

-Original Message-
From: NANOG  On Behalf Of Joseph Jenkins
Sent: Thursday, April 5, 2018 4:58 PM
To: nanog@nanog.org
Subject: Juniper Config Commit causes Cisco Etherchannels to go into 
err-disable state

I have cases open with both Cisco and Juniper on this, but wanted to see if 
anyone else had seen an issue like this because support has no idea.

I have a Juniper QFX 5100 Core running in Virtual Chassis mode with 4 switches. 
I have 4 separate stacks of Cisco 3750 switches with 2x1GB uplinks bound into 4 
different LACP trunks. I have had it happen twice now where I apply a trunk 
port config(not an LACP trunk) to a port that isn't a part of any of the LACP 
trunks and it causes all 4 of the Etherchannels on the Cisco stacked switches 
to go into an err-disable state with these
messages:

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
Gi1/0/48, putting Gi1/0/48 in err-disable state

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
Po17, putting Gi1/0/48 in err-disable state

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
Po17, putting Po17 in err-disable state

Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet1/0/48, changed state to down

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
Gi2/0/48, putting Gi2/0/48 in err-disable state (CA-TOR-1-7-2)

Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet2/0/48, changed state to down

Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
Port-channel17, changed state to down

Here is the config I am applying to the port that has caused this issue to 
happen twice now:

set interfaces ge-0/0/67 description "Firewall Port"
set interfaces ge-0/0/67 unit 0 family ethernet-switching interface-mode trunk 
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 9-10 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 29 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 31-32 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 43 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 50-51 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 56 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 58 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 66 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 68 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 90 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 143 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 170

The issue happens within a couple of minutes of committing the config on the 
Juniper side, there are no cables plugged into port 0/0/67 so technically there 
shouldn't be any BPDU's sent out since there isn't a port change.

Juniper Support wants me to turn on trace option and then run though a bunch of 
scenarios, the issue is that testing this takes down my network.

Just wanted to put it out there to see if anyone else had run into a situation 
similar to this.

TIA

Joe

Juniper Config Commit causes Cisco Etherchannels to go into err-disable state

[Joseph Jenkins]

I have cases open with both Cisco and Juniper on this, but wanted to see if
anyone else had seen an issue like this because support has no idea.

I have a Juniper QFX 5100 Core running in Virtual Chassis mode with 4
switches. I have 4 separate stacks of Cisco 3750 switches with 2x1GB
uplinks bound into 4 different LACP trunks. I have had it happen twice now
where I apply a trunk port config(not an LACP trunk) to a port that isn't a
part of any of the LACP trunks and it causes all 4 of the Etherchannels on
the Cisco stacked switches to go into an err-disable state with these
messages:

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected
on Gi1/0/48, putting Gi1/0/48 in err-disable state

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected
on Po17, putting Gi1/0/48 in err-disable state

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected
on Po17, putting Po17 in err-disable state

Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet1/0/48, changed state to down

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected
on Gi2/0/48, putting Gi2/0/48 in err-disable state (CA-TOR-1-7-2)

Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet2/0/48, changed state to down

Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Port-channel17, changed state to down

Here is the config I am applying to the port that has caused this issue to
happen twice now:

set interfaces ge-0/0/67 description "Firewall Port"
set interfaces ge-0/0/67 unit 0 family ethernet-switching interface-mode
trunk
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 9-10
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 29
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 31-32
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 43
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 50-51
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 56
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 58
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 66
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 68
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 90
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 143
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 170

The issue happens within a couple of minutes of committing the config on
the Juniper side, there are no cables plugged into port 0/0/67 so
technically there shouldn't be any BPDU's sent out since there isn't a port
change.

Juniper Support wants me to turn on trace option and then run though a
bunch of scenarios, the issue is that testing this takes down my network.

Just wanted to put it out there to see if anyone else had run into a
situation similar to this.

TIA

Joe

Re: Why doesn't "Cloudflare 1.1.1.1" compress root answers?

[Anurag Bhatia]

Hi Bjørn


Never realised of such compression on answered. Is this is something well
documented? Curious.



Thanks for sharing.

On Wed, Apr 4, 2018 at 1:30 AM, Bjørn Mork  wrote:

> At first I thought they had disabled compression:
>
>  bjorn@miraculix:~$ dig . ns @1.1.1.1|grep SIZE
>  ;; MSG SIZE  rcvd: 431
>  bjorn@miraculix:~$ dig . ns @8.8.8.8|grep SIZE
>  ;; MSG SIZE  rcvd: 239
>  bjorn@miraculix:~$ dig . ns @9.9.9.9|grep SIZE
>  ;; MSG SIZE  rcvd: 239
>
>
> But then I noticed that they *do* compress other names:
>
>  bjorn@miraculix:~$ dig net ns @1.1.1.1|grep SIZE
>  ;; MSG SIZE  rcvd: 253
>  bjorn@miraculix:~$ dig net ns @8.8.8.8|grep SIZE
>  ;; MSG SIZE  rcvd: 253
>  bjorn@miraculix:~$ dig net ns @9.9.9.9|grep SIZE
>  ;; MSG SIZE  rcvd: 253
>
>
> Which just makes it even more confusing.  What's so special about root?
> Except for the obvious :-)
>
>
>
> Bjørn
>
>


-- 


Anurag Bhatia
anuragbhatia.com

Re: Are any of you starting to get AI robocalls?

[HAL]

 I've worked at a telco for 15 years and I can say this problem is not
going away anytime soon. The issue is the SS7 network that carriers use
inherently trusts calls from long distance trunks without verification...
I've analyzed incoming spoofed calls from our STP and they all come from
foreign point codes on the SS7 network somewhere else in the world.  One
potential solution was to block incoming calls from an LD trunk with a
local NXX, but since number portability came into play this would also
block legitimate calls and couldn't be implemented without also having a
whitelist of ported numbers to let through. While you could in theory
customize your SS7 STP to do this, the manufactures of that equipment are
not very interested in that development work without being paid to do it,
and since the FCC/CRTC and other regulatory bodies haven't forced it yet...
nobody is voluntarily going to cough up the $$$.

This is very similar, in a way, to how email used to be in the 90s.. with
open SMTP relays all over the place and anyone could spoof email.. all you
need to do to access it is have some sort of digital interface (like a PRI
for example) to be able to connect directly and specify (ie spoof) your ANI
when placing a call).

*--*


On Thu, Apr 5, 2018 at 1:44 PM, Dovid Bender  wrote:

> On Thu, Apr 5, 2018 at 11:12 AM, Brian  wrote:
>
> > On Thu, 2018-04-05 at 07:55 -0700, Brian Kantor wrote:
> >
> > > So the logical conclusion is that caller ID is useless as an
> > > anti-vspam measure and the situation is hopeless, so the only
> > > solution is to not personally answer the phone at all -- let voice
> > > mail take a message.
> >
> > Pretty much. We've received calls here with the CID displaying as our
> > own info, and others coming up as a neighbor's number. Some even appear
> > as law enforcement when they're scammers looking for donations to
> > charities that don't exist. I suppose if you're going to commit one
> > crime, go for broke.
> >
> > > This is what I have adopted on my personal landline.  With the
> > > ringers disconnected.  Although I get probably a half-dozen incoming
> > > calls a day, perhaps one a week will leave a message.  Most of those
> > > messages are recorded announcements that started playing even before
> > > the voicemail greeting finished.
> >
> > I've been enjoying quiet on a VoIP line with asterisk. Those who I
> > know/expect/desire calls from I can route them directly to my extension,
> > those others get the IVR. It works parallel to IP routing. I can go a
> > few days without hearing my phone ring yet my logs are filled with
> > spammers/telemarketing calls. Robo-dialers have no clue which extension
> > a human may be at, and I've been doing this for over 15 years with great
> > success. With a digium wildcard, this can work for POTS lines as well.
> >
> >
> >
>
> A simple "Thank you for calling the line of $NAME. To prove you are not a
> robot press 1". That seems to weed out most of them.
>

-- 


This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the 
system manager. This message contains confidential information and is 
intended only for the individual named. If you are not the named addressee 
you should not disseminate, distribute or copy this email. Please notify 
the sender immediately by e-mail if you have received this email by mistake 
and delete this e-mail from your system. If you are not the intended 
recipient you are notified that disclosing, copying, distributing or taking 
any action in reliance on the contents of this information is strictly 
prohibited.

Re: NG Firewalls & IPv6

[Keith Stokes]

I’ve been using PfSense @ home dual-stack on Cox for a year or two. As far as I 
can tell any IPv6 problems are Cox issues.


On Apr 5, 2018, at 12:12 PM, Blake Hudson 
> wrote:

I've used pfSense (BSD firewall) in a dual stack setup. Not all features
are at parity with v4 (the captive portal doesn't support v6, for
example), but the core features of stateful firewall, DHCPv6, etc seemed
to work without any fuss.

Joe Klein wrote on 4/2/2018 5:58 PM:
All,

At security and network tradeshows over the last 15 years, I have asked
companies if their products supported "IPv6". They all claimed they did,
but were unable to verify any successful installations. Later they told me
it was on their "Roadmap" but were unable to provide an estimated year,
because it was a trade secret.

Starting this last year at BlackHat US, I again visited every product
booth, asking if their products supported dual-stack or IPv6 only
operations. Receiving only the same unsupported answers, I decided to focus
on one product category.

To the gurus of the NANOG community, What are your experiences with
installing and managing Next Generations firewalls? Do they support IPv6
only environments? Details? Stories?

If you prefer not to disparage those poor product companies, please contact
me off the list.

Thanks,

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8



---

Keith Stokes

RE: NG Firewalls & IPv6

[Robert Webb]

Really?? I was looking to install and use as a vm to test with and everything I 
was reading said it was not implemented and was not on the horizon.

Only version I found from Sophos that was capable was the old Astaro version. I 
may have to take a second look.

Do you have any links to the configuration from their site you could send off 
list? Or on list if anyone else is interested.

Thanks,
Robert

-Original Message-
From: NANOG  On Behalf Of Adam Kennedy via NANOG
Sent: Thursday, April 5, 2018 11:46 AM
To: NANOG list 
Subject: Re: NG Firewalls & IPv6

We've been using DHCP-PD with Sophos SG/XG on a couple Comcast connections and 
it works fine. It will even go through all your firewall objects and 
automatically change the IPv6 prefix from the old to new if the prefix from PD 
changes.

--

Adam Kennedy, Network & Systems Engineer

adamkenn...@watchcomm.net

*Watch Communications*

(866) 586-1518





On Wed, Apr 4, 2018 at 2:41 PM, Chuck Anderson  wrote:

> Also, IPv6 BGP support was only introduced in PanOS 8.  But everything 
> works fine here too.
>
> On Wed, Apr 04, 2018 at 10:47:45AM +, Dan Kitchen wrote:
> > We run PaloAlto dual stack with no problems at all, that’s full 
> > dynamic
> routing with OSPF and BGP, web filtering, IPS, VPN access using 
> GlobalProtect, etc.
> >
> > I must admit GlobalProtect IPv6 support was only introduced in PanOS 
> > 8
> which was a little late in my opinion – but it was delivered and works.
> >
> >
> >
> >
> > Dan Kitchen
> > Managing Director
> > razorblue | IT Solutions for Business
> >
> > ddi:0330 122 7143 |  t: 0333 344 6 344 | e: dkitc...@razorblue.com
>  | w: razorblue.com
> >
> > Legal and address information for all Razorblue Group companies can 
> > be
> found
> > at www.razorblue.com/contact.
> >
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joe Klein
> > Sent: 02 April 2018 23:58
> > To: NANOG list 
> > Subject: NG Firewalls & IPv6
> >
> > WARNING: This e-mail originated from outside the Razorblue Group
> corporate network
> >
> > All,
> >
> > At security and network tradeshows over the last 15 years, I have 
> > asked companies if their products supported "IPv6". They all claimed 
> > they did, but were unable to verify any successful installations. 
> > Later they told
> me
> > it was on their "Roadmap" but were unable to provide an estimated 
> > year, because it was a trade secret.
> >
> > Starting this last year at BlackHat US, I again visited every 
> > product booth, asking if their products supported dual-stack or IPv6 
> > only operations. Receiving only the same unsupported answers, I 
> > decided to
> focus
> > on one product category.
> >
> > To the gurus of the NANOG community, What are your experiences with 
> > installing and managing Next Generations firewalls? Do they support 
> > IPv6 only environments? Details? Stories?
> >
> > If you prefer not to disparage those poor product companies, please
> contact
> > me off the list.
> >
> > Thanks,
> >
> > Joe Klein
>

Re: Are any of you starting to get AI robocalls?

[Dovid Bender]

On Thu, Apr 5, 2018 at 11:12 AM, Brian  wrote:

> On Thu, 2018-04-05 at 07:55 -0700, Brian Kantor wrote:
>
> > So the logical conclusion is that caller ID is useless as an
> > anti-vspam measure and the situation is hopeless, so the only
> > solution is to not personally answer the phone at all -- let voice
> > mail take a message.
>
> Pretty much. We've received calls here with the CID displaying as our
> own info, and others coming up as a neighbor's number. Some even appear
> as law enforcement when they're scammers looking for donations to
> charities that don't exist. I suppose if you're going to commit one
> crime, go for broke.
>
> > This is what I have adopted on my personal landline.  With the
> > ringers disconnected.  Although I get probably a half-dozen incoming
> > calls a day, perhaps one a week will leave a message.  Most of those
> > messages are recorded announcements that started playing even before
> > the voicemail greeting finished.
>
> I've been enjoying quiet on a VoIP line with asterisk. Those who I
> know/expect/desire calls from I can route them directly to my extension,
> those others get the IVR. It works parallel to IP routing. I can go a
> few days without hearing my phone ring yet my logs are filled with
> spammers/telemarketing calls. Robo-dialers have no clue which extension
> a human may be at, and I've been doing this for over 15 years with great
> success. With a digium wildcard, this can work for POTS lines as well.
>
>
>

A simple "Thank you for calling the line of $NAME. To prove you are not a
robot press 1". That seems to weed out most of them.

RE: Are any of you starting to get AI robocalls?

[Naslund, Steve]

There are plenty of ways to handle that.

There are P-asserted identities that can be passed with the call in addition to 
the CLID.  In SIP, there is also call history data that can give you all of the 
PBX hops identified.

If a customer with a PBX wants to forward calls back into the PSTN then the 
carrier can have an option to allow them to do that but they better also have a 
way of tracking those calls since they are open to abuse and they are obscuring 
the routing of the call.  I am OK with that as long as the carrier is 
responsible for tracking back any abuse complaints.

I do think every PBX in the call path should be identified.  We have had 
instances where some stupid PBX is forwarding calls to the wrong number 
generating abuse complaints that track back to the wrong place because the PBX 
forwarded the original caller-id.  So you call that person back and they 
correctly claim that they never called you.

Steven Naslund
Chicago IL

>-Original Message-
>From: Dovid Bender [mailto:do...@telecurve.com] 
>Sent: Thursday, April 05, 2018 9:07 AM
>To: Naslund, Steve; NANOG list
>Subject: Re: Are any of you starting to get AI robocalls?
>
>Steve,
>
>Any customer with a PBX has a valid reason to pass CLI that isn't theirs if 
>they are passing through a call.  
>
>
>Regards,
>
>Dovid

Re: validating reachability via an ISP

[Andy Litzinger]

Hi Andy,
  The root cause was they regional ISP was failing to advertise my prefix
due to a mistake in their export policy.  While I'm glad we were able to
figure out the issue I'm generally more interested in figuring out a way
that I can programmatically monitor that my ISPs are providing me with good
reachability, even when their route isn't necessarily the best/installed
route to me.

I do have route objects defined in an IRR for this prefix. Perhaps you
wouldn't mind explaining to me how route-server or ISP operators generally
validate route-objects before accepting routes?  Especially in the case
where I'm not peering with your route server but my ISP is.  Do you query
the IRR DB to recurse from the ISP AS to my AS and validate route objects
there?

thanks!
-andy



On Thu, Apr 5, 2018 at 12:49 AM, Andy Davidson  wrote:

>
>
>
>
>
> On 29/03/2018, 00:22, Andy Litzinger 
> wrote:
> >
> >> The root cause is that the our prefix is not being adequately
> >> re-distributed globally by the regional ISP.  This is unexpected and we
> are
> >> working through this with them now.
>
> Hi, Andy —
>
> Are you failing to advertise it, or are they filtering it on ingress, or
> are they failing to send it to their other peers?
>
> One configuration mishap which is starting to come along more and more
> partial or poor reachability caused by route objects which are not
> correctly published in the IRRDB. It is going to be essential to make sure
> that you have properly recorded IRR route objects in, for instance, RADB.
> More BGP speakers properly filter their peers using information that is
> published there.  Avoid future reachability problems by checking this today!
>
> Yours,
> A friendly route-server operator with strict filtering
>
> -a
>
>
>
> --
> Andy DavidsonAsteroid International BV
> https://www.asteroidhq.com@asteroidhq   @andyd
> --
> Local interconnection.  Where you need it.
>
>

Re: NG Firewalls & IPv6

[Blake Hudson]

I've used pfSense (BSD firewall) in a dual stack setup. Not all features
are at parity with v4 (the captive portal doesn't support v6, for
example), but the core features of stateful firewall, DHCPv6, etc seemed
to work without any fuss.

Joe Klein wrote on 4/2/2018 5:58 PM:
> All,
>
> At security and network tradeshows over the last 15 years, I have asked
> companies if their products supported "IPv6". They all claimed they did,
> but were unable to verify any successful installations. Later they told me
> it was on their "Roadmap" but were unable to provide an estimated year,
> because it was a trade secret.
>
> Starting this last year at BlackHat US, I again visited every product
> booth, asking if their products supported dual-stack or IPv6 only
> operations. Receiving only the same unsupported answers, I decided to focus
> on one product category.
>
> To the gurus of the NANOG community, What are your experiences with
> installing and managing Next Generations firewalls? Do they support IPv6
> only environments? Details? Stories?
>
> If you prefer not to disparage those poor product companies, please contact
> me off the list.
>
> Thanks,
>
> Joe Klein
>
> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
> PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8

Re: NG Firewalls & IPv6

[Adam Kennedy via NANOG]

We've been using DHCP-PD with Sophos SG/XG on a couple Comcast connections
and it works fine. It will even go through all your firewall objects and
automatically change the IPv6 prefix from the old to new if the prefix from
PD changes.

--

Adam Kennedy, Network & Systems Engineer

adamkenn...@watchcomm.net

*Watch Communications*

(866) 586-1518





On Wed, Apr 4, 2018 at 2:41 PM, Chuck Anderson  wrote:

> Also, IPv6 BGP support was only introduced in PanOS 8.  But everything
> works fine here too.
>
> On Wed, Apr 04, 2018 at 10:47:45AM +, Dan Kitchen wrote:
> > We run PaloAlto dual stack with no problems at all, that’s full dynamic
> routing with OSPF and BGP, web filtering, IPS, VPN access using
> GlobalProtect, etc.
> >
> > I must admit GlobalProtect IPv6 support was only introduced in PanOS 8
> which was a little late in my opinion – but it was delivered and works.
> >
> >
> >
> >
> > Dan Kitchen
> > Managing Director
> > razorblue | IT Solutions for Business
> >
> > ddi:0330 122 7143 |  t: 0333 344 6 344 | e: dkitc...@razorblue.com
>  | w: razorblue.com
> >
> > Legal and address information for all Razorblue Group companies can be
> found
> > at www.razorblue.com/contact.
> >
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joe Klein
> > Sent: 02 April 2018 23:58
> > To: NANOG list 
> > Subject: NG Firewalls & IPv6
> >
> > WARNING: This e-mail originated from outside the Razorblue Group
> corporate network
> >
> > All,
> >
> > At security and network tradeshows over the last 15 years, I have asked
> > companies if their products supported "IPv6". They all claimed they did,
> > but were unable to verify any successful installations. Later they told
> me
> > it was on their "Roadmap" but were unable to provide an estimated year,
> > because it was a trade secret.
> >
> > Starting this last year at BlackHat US, I again visited every product
> > booth, asking if their products supported dual-stack or IPv6 only
> > operations. Receiving only the same unsupported answers, I decided to
> focus
> > on one product category.
> >
> > To the gurus of the NANOG community, What are your experiences with
> > installing and managing Next Generations firewalls? Do they support IPv6
> > only environments? Details? Stories?
> >
> > If you prefer not to disparage those poor product companies, please
> contact
> > me off the list.
> >
> > Thanks,
> >
> > Joe Klein
>

Re: Are any of you starting to get AI robocalls?

[Brian]

On Thu, 2018-04-05 at 07:55 -0700, Brian Kantor wrote:

> So the logical conclusion is that caller ID is useless as an
> anti-vspam measure and the situation is hopeless, so the only
> solution is to not personally answer the phone at all -- let voice
> mail take a message.

Pretty much. We've received calls here with the CID displaying as our
own info, and others coming up as a neighbor's number. Some even appear
as law enforcement when they're scammers looking for donations to
charities that don't exist. I suppose if you're going to commit one
crime, go for broke.

> This is what I have adopted on my personal landline.  With the
> ringers disconnected.  Although I get probably a half-dozen incoming
> calls a day, perhaps one a week will leave a message.  Most of those
> messages are recorded announcements that started playing even before
> the voicemail greeting finished.

I've been enjoying quiet on a VoIP line with asterisk. Those who I
know/expect/desire calls from I can route them directly to my extension,
those others get the IVR. It works parallel to IP routing. I can go a
few days without hearing my phone ring yet my logs are filled with
spammers/telemarketing calls. Robo-dialers have no clue which extension
a human may be at, and I've been doing this for over 15 years with great
success. With a digium wildcard, this can work for POTS lines as well.

Re: Are any of you starting to get AI robocalls?

[Brian Kantor]

On Thu, Apr 05, 2018 at 10:20:29AM -0400, William Herrin wrote:
> For example, Vonage implementing Simultaneous Ring, you want to see
> the original caller id on your cell phone, not your vonage number even
> though Vonage is bridging the call to your cell phone.
> 
> More, the PBX may have trunks from multiple vendors and may use a
> different outbound vendor than the call arrives on, so you can't even
> reliably implement a rule that the outbound caller ID is rejected
> unless there's an active inbound call with the same caller id.
> 
> Regards,
> Bill Herrin

So the logical conclusion is that caller ID is useless as an
anti-vspam measure and the situation is hopeless, so the only
solution is to not personally answer the phone at all -- let voice
mail take a message.

This is what I have adopted on my personal landline.  With the
ringers disconnected.  Although I get probably a half-dozen incoming
calls a day, perhaps one a week will leave a message.  Most of those
messages are recorded announcements that started playing even before
the voicemail greeting finished.
- Brian

Re: Are any of you starting to get AI robocalls?

[William Herrin]

On Thu, Apr 5, 2018 at 10:06 AM, Dovid Bender  wrote:
> Any customer with a PBX has a valid reason to pass CLI that isn't theirs if 
> they are passing through a call.

Hi Dovid,

For example, Vonage implementing Simultaneous Ring, you want to see
the original caller id on your cell phone, not your vonage number even
though Vonage is bridging the call to your cell phone.

More, the PBX may have trunks from multiple vendors and may use a
different outbound vendor than the call arrives on, so you can't even
reliably implement a rule that the outbound caller ID is rejected
unless there's an active inbound call with the same caller id.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Are any of you starting to get AI robocalls?

[Dovid Bender]

Steve,

Any customer with a PBX has a valid reason to pass CLI that isn't theirs if 
they are passing through a call.  


Regards,

Dovid


  Original Message  
From: snasl...@medline.com
Sent: April 5, 2018 10:03
To: nanog@nanog.org
Subject: RE: Are any of you starting to get AI robocalls?

If the scam caller is spoofing the numbers then I am not quite sure how 
T-Mobile can implement the block without blocking the legit owner of the 
number.  The way to correct this as an industry is for them to inspect the 
caller-id coming in from their customer and if that customer does not own the 
number or toll free DN they are presenting, the call gets blocked.  I know they 
can do this because our SIP carrier AT will not accept outbound calls from us 
unless we present a number assigned to our account so they can bill back for 
the call.  Truthfully, the carriers do not have a real incentive to stop this 
because someone is paying to make all of those calls.  I don't believe for a 
minute that they could not stop this immediately.  A simple rule that you 
cannot make a commercial call without presenting a valid callback number would 
fix this.  There is also the FTC problem.  They do almost nothing to stop the 
violations of the Do Not Call list and you get nothing out of reporting the 
violations.  If the enforcement was anywhere near the requirements of the DCMA 
regulations, this would be reduced drastically.  First step would be to make 
the carriers liable for providing service to these scammers, then they might 
actually care.


Steven Naslund
Chicago IL





-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ca By
Sent: Thursday, April 05, 2018 7:43 AM
To: Shawn L
Cc: nanog@nanog.org
Subject: Re: Are any of you starting to get AI robocalls?

On Wed, Apr 4, 2018 at 4:19 PM Shawn L via NANOG  wrote:

>
> Honestly, most carriers I've talked to are fed up as well, and just 
> want to find a way to make it stop.  As some one said, it's exactly 
> like BCP38
> ---  the carriers that care keep their clients from spoofing caller 
> id, etc.  The ones that don't make everyone else look bad.
>

Some carriers have a free scam call block feature

https://newsroom.t-mobile.com/news-and-blogs/scam-block.htm

RE: Are any of you starting to get AI robocalls?

[Naslund, Steve]

If the scam caller is spoofing the numbers then I am not quite sure how 
T-Mobile can implement the block without blocking the legit owner of the 
number.  The way to correct this as an industry is for them to inspect the 
caller-id coming in from their customer and if that customer does not own the 
number or toll free DN they are presenting, the call gets blocked.  I know they 
can do this because our SIP carrier AT will not accept outbound calls from us 
unless we present a number assigned to our account so they can bill back for 
the call.  Truthfully, the carriers do not have a real incentive to stop this 
because someone is paying to make all of those calls.  I don't believe for a 
minute that they could not stop this immediately.  A simple rule that you 
cannot make a commercial call without presenting a valid callback number would 
fix this.  There is also the FTC problem.  They do almost nothing to stop the 
violations of the Do Not Call list and you get nothing out of reporting the 
violations.  If the enforcement was anywhere near the requirements of the DCMA 
regulations, this would be reduced drastically.  First step would be to make 
the carriers liable for providing service to these scammers, then they might 
actually care.


Steven Naslund
Chicago IL





-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ca By
Sent: Thursday, April 05, 2018 7:43 AM
To: Shawn L
Cc: nanog@nanog.org
Subject: Re: Are any of you starting to get AI robocalls?

On Wed, Apr 4, 2018 at 4:19 PM Shawn L via NANOG  wrote:

>
> Honestly, most carriers I've talked to are fed up as well, and just 
> want to find a way to make it stop.  As some one said, it's exactly 
> like BCP38
> ---  the carriers that care keep their clients from spoofing caller 
> id, etc.  The ones that don't make everyone else look bad.
>

Some carriers have a free scam call block feature

https://newsroom.t-mobile.com/news-and-blogs/scam-block.htm

Re: Are any of you starting to get AI robocalls?

[Ca By]

On Wed, Apr 4, 2018 at 4:19 PM Shawn L via NANOG  wrote:

>
> Honestly, most carriers I've talked to are fed up as well, and just want
> to find a way to make it stop.  As some one said, it's exactly like BCP38
> ---  the carriers that care keep their clients from spoofing caller id,
> etc.  The ones that don't make everyone else look bad.
>

Some carriers have a free scam call block feature

https://newsroom.t-mobile.com/news-and-blogs/scam-block.htm




> -Original Message-
> From: "Keith Medcalf" 
> Sent: Wednesday, April 4, 2018 7:04pm
> To: "nanog@nanog.org" 
> Subject: RE: Are any of you starting to get AI robocalls?
>
>
>
> Why would the carriers want to do anything? They are making money from
> call termination fees.
>
>
> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
> >-Original Message-
> >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Sean
> >Pedersen
> >Sent: Wednesday, 4 April, 2018 08:45
> >To: nanog@nanog.org
> >Subject: RE: Are any of you starting to get AI robocalls?
> >
> >Yep. Add it to the list of IRS scams, fake arrest warrants, credit
> >repair, free vacations, etc. The rate of calls has increased
> >dramatically in the past year, especially with the "neighborhood
> >scam" where they spoof their CLID to a local area code and prefix +
> > through  and blast you with calls, trying to trick you into
> >thinking it's someone local and thus important or legitimate.
> >
> >I have a second phone I use for work and on-call, so that goes on DND
> >from 6PM to 6AM with a VIP list of people/numbers that can ring
> >through. No problems there, and somehow that number isn't (yet) on
> >anyone's list, so I don't get many calls.
> >
> >On my personal cell, I started to use an app called Hiya that has
> >been pretty successful. It's available for both iPhone and Android.
> >It powers a lot of the carrier-specific apps like AT Call Protect,
> >but unlike them, it doesn't suck. It's a giant database of reports
> >that rate calling numbers and classify them as fraud, scam,
> >neighborhood spoofing, etc. and you can flag them or route them right
> >to voicemail. The only time it doesn’t work is when it hasn't updated
> >its list in a little while and a few sneak through. They just
> >realized a premium version that added some features. I haven't
> >explored it yet.
> >
> >Went from about 20 calls a week to almost nothing.
> >
> >Carriers seem to be either uncapable or unwilling to address the
> >issue other than the occasional lip-service reply about "taking
> >customer's $variable seriously."
> >
> >-Original Message-
> >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William
> >Herrin
> >Sent: Tuesday, April 3, 2018 3:32 PM
> >To: nanog@nanog.org
> >Subject: Are any of you starting to get AI robocalls?
> >
> >Howdy.
> >
> >Have any of you started to get AI robocalls? I've had a couple of
> >calls recently where I get the connect silence of a predictive dialer
> >followed by a woman speaking with call center background noise. She
> >gives her name and asks how I'm doing. The first time it happened it
> >seemed off for reasons I can't quite articulate, so I asked: "Are you
> >a robot or a person?" She responded "yes" and then launched in to a
> >sales pitch. The next time I asked, "where can I direct your call?"
> >She responded "that's good" and launched in to her pitch.
> >
> >Regards,
> >Bill Herrin
> >
> >
> >--
> >William Herrin  her...@dirtside.com b...@herrin.us
> >Dirtside Systems . Web: 
>
>
>
>
>
>

Re: Are any of you starting to get AI robocalls?

[Merve Sahin]

There is also Lenny :
https://www.youtube.com/playlist?list=PLduL71_GKzHHk4hLga0nOGWrXlhl-i_3g

And here is our paper on using chatbots against voice spam:
https://www.usenix.org/conference/soups2017/technical-sessions/presentation/sahin

It seems the future of voice spam will be the chatbots talking to each
other!

Merve

On 04/04/2018 17:08, Jim Shankland wrote:
> On 4/4/18 7:44 AM, Sean Pedersen wrote:
>> Yep. Add it to the list of IRS scams, fake arrest warrants, credit
>> repair, free vacations, etc. The rate of calls has increased
>> dramatically in the past year, especially with the "neighborhood scam"
>> where they spoof their CLID to a local area code and prefix + 
>> through  and blast you with calls, trying to trick you into
>> thinking it's someone local and thus important or legitimate.
>>
> Let me also put in a good word for the Jolly Roger Telephone Co.
> (http://www.jollyrogertelco.com). Don't just defend, fight back.
> 
> Jim
> 

Re: validating reachability via an ISP

[Ben Bartsch]

+1 for Route Explorer

On Thu, Apr 5, 2018 at 2:49 AM, Andy Davidson  wrote:

>
>
>
>
>
> On 29/03/2018, 00:22, Andy Litzinger 
> wrote:
> >
> >> The root cause is that the our prefix is not being adequately
> >> re-distributed globally by the regional ISP.  This is unexpected and we
> are
> >> working through this with them now.
>
> Hi, Andy —
>
> Are you failing to advertise it, or are they filtering it on ingress, or
> are they failing to send it to their other peers?
>
> One configuration mishap which is starting to come along more and more
> partial or poor reachability caused by route objects which are not
> correctly published in the IRRDB. It is going to be essential to make sure
> that you have properly recorded IRR route objects in, for instance, RADB.
> More BGP speakers properly filter their peers using information that is
> published there.  Avoid future reachability problems by checking this today!
>
> Yours,
> A friendly route-server operator with strict filtering
>
> -a
>
>
>
> --
> Andy DavidsonAsteroid International BV
> https://www.asteroidhq.com@asteroidhq   @andyd
> --
> Local interconnection.  Where you need it.
>
>

Re: validating reachability via an ISP

[Andy Davidson]

On 29/03/2018, 00:22, Andy Litzinger  wrote:
>
>> The root cause is that the our prefix is not being adequately
>> re-distributed globally by the regional ISP.  This is unexpected and we are
>> working through this with them now.

Hi, Andy —

Are you failing to advertise it, or are they filtering it on ingress, or are 
they failing to send it to their other peers?

One configuration mishap which is starting to come along more and more partial 
or poor reachability caused by route objects which are not correctly published 
in the IRRDB. It is going to be essential to make sure that you have properly 
recorded IRR route objects in, for instance, RADB.  More BGP speakers properly 
filter their peers using information that is published there.  Avoid future 
reachability problems by checking this today!

Yours,
A friendly route-server operator with strict filtering

-a



-- 
Andy DavidsonAsteroid International BV
https://www.asteroidhq.com@asteroidhq   @andyd
--
Local interconnection.  Where you need it.