Re: Comcast email contact

2019-01-27 Thread Mike Hammett
Please move this to the Mail Ops mailing list. 




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

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

- Original Message -

From: "Josh Smith"  
To: nanog@nanog.org 
Sent: Friday, January 25, 2019 4:41:51 PM 
Subject: Comcast email contact 



Can someone from comcast email please contact me off-list. You all appear to be 
black holing email received from $DAYJOBS domain. Your support from indicates 
we are not blocked. Our logs indicate the mail is accepted for delivery but 
they never make it to users inboxes, or junk/spam folders. 




Thanks, 

Josh Smith 




Re: BGP Experiment

2019-01-27 Thread Nick Hilliard

William Allen Simpson wrote on 27/01/2019 18:21:

OK, Randy, you peaked my interest: what is a naggumite?


http://naggum.no/worse-is-better.html

a.k.a. "perfect is the enemy of good enough".

Nick


Re: BGP Experiment

2019-01-27 Thread Randy Bush
> OK, Randy, you peaked my interest: what is a naggumite?

erik naggum, an early and strong proponent of being strict.  you've been
around long enough you should remember erik.

> Many of us disagreed with Jon Postel from time to time, but he usually
> understood the alternative points of view.

oh, i have been dealing with network cowboys (and yes, unsurprisingly
pretty universally boys) for enough decades to mostly understand.  but
the lack of prudence and level of irresponsibility occasionally surprise
me.

randy


Process for deploying new BGP attributes (experimentally or otherwise)

2019-01-27 Thread Amir Herzberg
Following our recent attempts to experiment with potential use of BGP
attributes,
I would like to understand better the desired process for using new BGP
attributes.
As mentioned earlier, we investigate currently one usage of BGP attributes
for improving BGP security - specifically, adoption of RPKI. I also have
some future ideas on other ways BGP attributes may be useful to improve BGP
security; and surely other applications, security or otherwise, may exist.
So I think we need an acceptable process to do it.

Indeed, while we aborted that experiment, I doubt that the right conclusion
is that one should simply never use a new BGP attribute... And I even hope
that the community would want us to complete our research, to see if the
particular approach we evaluate may indeed be beneficial. I think that
these sentiments were also expressed by many members of this community.

So:
- Is there some document discussing the desired (best practice) process?
[if not, maybe such document should be written?]
- We used unassigned attribute. Should one always assign an attribute
before using it? That's a possibility, but has some `costs' - and may yet
fail to prevent problems to some non-conforming networks.
- Is there an agreed-upon list of the forums and mailing lists on which one
should warn in advance about such planned announcements, and the details
that should be included?

Thanks, Amir
-- 
Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut

Homepage: https://sites.google.com/site/amirherzberg/home
Publications and projects:
https://www.researchgate.net/profile/Amir_Herzberg/contributions

Lecture notes in intro to cyber:
https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security


Re: Quick Script to check the uptime of ASR920's

2019-01-27 Thread Laurent Dumont
It's worth mentioning that's it's not limited to just the cosmetic issue of
interface counters/snmp counters.

- I've had multiple instances of 920 interfaces getting stuck in their
previous operational state. Unplugging-replugging/shut/no-shut doesn't
change anything.
- The 920 fails to process traffic towards very specific IPs. That one is a
pain to debug. You can reach the IP directly from the device but flows
through the device are just dropped (also saw the same behavior on 903 with
RSP3)
- ARP under a BDI show up and are re-learned after a clear but traffic
towards those IP do not work through or sourced from the 920.
- One 920 started to show the above described symptoms, was rebooted and
failed to back up. ISIS went up, cannot ping any of the P2P.

That said, uptime should definitely be monitored through your central
NMS-flavor system. ;)

On Fri, Jan 25, 2019 at 7:45 PM Erik Sundberg 
wrote:

> It was a script I created in regards to this thread below... Interface
> counters and some other things stop working after a Cisco ASR920 is up 889
> days Fun Fun
>
> https://puck.nether.net/pipermail/cisco-nsp/2019-January/106558.html
>
>
> -Original Message-
> From: Mel Beckman 
> Sent: Friday, January 25, 2019 6:39 PM
> To: Erik Sundberg 
> Cc: nanog@nanog.org
> Subject: Re: Quick Script to check the uptime of ASR920's
>
> Erik,
>
> That’s a nice little script. Thanks!
>
> So you want a warning if a router hasn’t been rebooted in a long time?
> Just out of curiosity, why? I’m kind of glad that my routers don’t reboot,
> pretty much ever. Usually I want to know if the uptime suddenly became less
> than the most recent uptime, indicting a possibly unplanned reboot.
>
>  -mel
>
> > On Jan 25, 2019, at 4:29 PM, Erik Sundberg 
> wrote:
> >
> > All,
> >
> > I just created a quick script to check the uptime of a ASR920 via SNMP
> > if you have a fairly long list of devices. It's a simple bash script
> > and snmpwalk version 2c. Figured I would share it with you. Happy
> > Friday
> >
> > Grab the code from GitHub:
> > https://github.com/esundberg/CiscoRouterUptime
> > It's a quick and dirty script and my first repo on github. Let me know
> if there any issues with it.
> >
> >
> > Output Format in CSV
> > DeviceName, IP, Uptime in Days, OK/Warning
> >
> > I set my warning to 800 Days, you can change this in the code
> >
> >
> > ASR920list.txt
> > -
> > ASR920-1.SEA1, 192.168.28.1, SuperSecretSNMPKey ASR920-2.SEA1,
> > 192.168.28.2, SuperSecretSNMPKey snip you get the idea
> >
> >
> > Output
> >
> > [user@Linux]$ ./CiscoRouterUptime.sh ASR920list.txt ASR920-1.SEA1,
> > 192.168.28.1, 827, WARNING ASR920-2.SEA1, 192.168.28.2, 827, WARNING
> > ASR920-2.ATL1, 192.168.23.2, 828, WARNING ASR920-1.ATL1, 192.168.23.1,
> > 813, WARNING ASR920-1.CHI1, 192.168.21.3, 828, WARNING ASR920-1.NYC1,
> > 192.168.25.1, 787, OK ASR920-2.CHI1, 192.168.21.4, 720, OK
> > ASR920-3.CHI1, 192.168.21.5, 720, OK ASR920-1.DAL1, 192.168.26.3, 488,
> > OK ASR920-4.CHI1, 192.168.21.6, 142, OK
> >
> >
> >
> > 
> >
> > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents,
> files or previous e-mail messages attached to it may contain confidential
> information that is legally privileged. If you are not the intended
> recipient, or a person responsible for delivering it to the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution or use of any of the information contained in or attached to
> this transmission is STRICTLY PROHIBITED. If you have received this
> transmission in error please notify the sender immediately by replying to
> this e-mail. You must destroy the original transmission and its attachments
> without reading or saving in any manner. Thank you.
>
>
> 
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files
> or previous e-mail messages attached to it may contain confidential
> information that is legally privileged. If you are not the intended
> recipient, or a person responsible for delivering it to the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution or use of any of the information contained in or attached to
> this transmission is STRICTLY PROHIBITED. If you have received this
> transmission in error please notify the sender immediately by replying to
> this e-mail. You must destroy the original transmission and its attachments
> without reading or saving in any manner. Thank you.
>


Comcast email contact

2019-01-27 Thread Josh Smith
Can someone from comcast  email please contact me off-list.  You all appear
to be black holing email received from $DAYJOBS domain.  Your support from
indicates we are not blocked.  Our logs indicate the mail is accepted for
delivery but they never make it to users inboxes, or junk/spam folders.


Thanks,
Josh Smith


[2019/01/27] Re: BGP Experiment

2019-01-27 Thread Hansen, Christoffer

On 27/01/2019 19:21, William Allen Simpson wrote:
> OK, Randy, you peaked my interest: what is a naggumite?

... (scouring the internet)

o
https://www.nanog.org/mailinglist/mailarchives/old_archive/2006-01/msg00250.html
o https://en.wikipedia.org/wiki/Erik_Naggum
o https://www.dictionary.com/browse/-ite

?



signature.asc
Description: OpenPGP digital signature


Re: BGP Experiment

2019-01-27 Thread William Allen Simpson

On 1/26/19 6:37 PM, Randy Bush wrote:

to nick's point.  as nick knows, i am a naggumite; one of my few
disagreements with dr postel.  but there is a difference between
writing protocol specs/code, and with sending packets on the global
internet.  rigor in the former, prudence in the latter.


OK, Randy, you peaked my interest: what is a naggumite?

Many of us disagreed with Jon Postel from time to time, but he
usually understood the alternative points of view.