RE: CloudFlare Issues?
https://www.cloudflarestatus.com/ From: NANOG On Behalf Of Chris Grundemann Sent: Friday, July 17, 2020 4:39 PM To: NANOG list Subject: CloudFlare Issues? *External Email: Use Caution* Looks like there may be something big up (read: down) at CloudFlare, but their status page is not reporting anything yet. Am I crazy? Or just time to give up on the internet for this week? -- @ChrisGrundemann https://link.edgepilot.com/s/f7346db5/qDrwfqlG4ESjtP0RY1EKXQ?u=http://chrisgrundemann.com/ Links contained in this email have been replaced. If you click on a link in the email above, the link will be analyzed for known threats. If a known threat is found, you will not be able to proceed to the destination. If suspicious content is detected, you will see a warning.
RE: AS16509 (Amazon) peering contact
No private information was shared. See for yourself: https://www.peeringdb.com/net/1418 -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Stephen Fulton Sent: Thursday, June 27, 2019 5:22 PM To: nanog@nanog.org Subject: Re: AS16509 (Amazon) peering contact Hi Kody, Please don't share a person's e-mail account on a mailing list. Role accounts are one thing, but not this. If you want to, send it privately. Cheers, Stephen On 2019-06-27 17:47, Kody Vicknair wrote: > I've always worked with Tim Bates. They were exceptionally quick with > standing up my session. like same day quick... > > x...@amazon.com > > > > > > Kody Vicknair > Network Engineer > > Tel:985.536.1214 > Fax:985.536.0300 > Email: kvickn...@reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > __ > ___ > > Disclaimer: > The information transmitted, including attachments, is intended only for the > person(s) or entity to which it is addressed and may contain confidential > and/or privileged material which should not disseminate, distribute or be > copied. Please notify Kody Vicknair immediately by e-mail if you have > received this e-mail by mistake and delete this e-mail from your system. > E-mail transmission cannot be guaranteed to be secure or error-free as > information could be intercepted, corrupted, lost, destroyed, arrive late or > incomplete, or contain viruses. Kody Vicknair therefore does not accept > liability for any errors or omissions in the contents of this message, which > arise as a result of e-mail transmission. . > > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Hansen, > Christoffer > Sent: Thursday, June 27, 2019 2:45 PM > To: nanog@nanog.org > Subject: Re: AS16509 (Amazon) peering contact > > > On 27/06/2019 20:55, Andras Toth wrote: >> Including at least an ASN in the peering request usually helps to >> expedite the process :) > & keeping your peeringdb entry up-to-date is usually helpful, too. > Depending on who you want to peer with(!) > > Some networks require you to have up-to-date peeringdb information for your > network. Including which facilities and/or internet exchanges you are either > connected to and/or present on/in. > This will often be the case if $peering_partner have either partial or fully > automated peering configuration management. > > /Christoffer
RE: AS16509 (Amazon) peering contact
I've always worked with Tim Bates. They were exceptionally quick with standing up my session. like same day quick... t...@amazon.com Kody Vicknair Network Engineer Tel:985.536.1214 Fax:985.536.0300 Email: kvickn...@reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Hansen, Christoffer Sent: Thursday, June 27, 2019 2:45 PM To: nanog@nanog.org Subject: Re: AS16509 (Amazon) peering contact On 27/06/2019 20:55, Andras Toth wrote: > Including at least an ASN in the peering request usually helps to > expedite the process :) & keeping your peeringdb entry up-to-date is usually helpful, too. Depending on who you want to peer with(!) Some networks require you to have up-to-date peeringdb information for your network. Including which facilities and/or internet exchanges you are either connected to and/or present on/in. This will often be the case if $peering_partner have either partial or fully automated peering configuration management. /Christoffer
RE: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released
I'm curious, If the highjacked prefix is a /24 (subset of your much larger /22) and you can only tie the highjacked prefix, at that point how effective is the mitigation outside of a default bgp route selection process? -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Vasileios Kotronis Sent: Thursday, December 20, 2018 11:23 AM To: nanog@nanog.org Subject: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released Dear operators, FORTH's INSPIRE group and CAIDA are delighted to announce the public release of the ARTEMIS BGP prefix hijacking detection tool, available as open-source software at https://github.com/FORTH-ICS-INSPIRE/artemis ARTEMIS is designed to be operated by an AS in order to monitor BGP for potential hijacking attempts against its own prefixes. The system detects such attacks within seconds, enabling immediate mitigation. The current release has been tested at a major greek ISP, a dual-homed edge academic network, and a major US R&E backbone network. We would be happy if you'd give it a try and provide feedback. Feel free to make pull requests on GitHub and help us make this a true community project. ARTEMIS is funded by European Research Council (ERC) grant agreement no. 338402 (NetVolution Project), the RIPE NCC Community Projects 2017, the Comcast Innovation Fund, US NSF grants OAC-1848641 and CNS-1423659 and US DHS S&T contract HHSP233201600012C. Best regards, Vasileios -- === Vasileios Kotronis Postdoctoral Researcher, member of the INSPIRE Group INSPIRE = INternet Security, Privacy, and Intelligence REsearch Telecommunications and Networks Lab (TNL) Foundation for Research and Technology - Hellas (FORTH) Leoforos Plastira 100, Heraklion 70013, Greece e-mail : vkotro...@ics.forth.gr url: http://inspire.edu.gr ===
RE: IPv6 Loopback/Point-to-Point address allocation
Apologies, Wrong link: https://www.sinog.si/docs/draft-IPv6pd-BCOP-v7.pdf Kody Vicknair Network Engineer [cid:image764c5e.JPG@bb882327.44b4b1d7] <http://www.rtconline.com> Tel:985.536.1214 Fax:985.536.0300 Email: kvickn...@reservetele.com Web:www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From: Kody Vicknair Sent: Saturday, September 09, 2017 11:06 AM To: nanog@nanog.org Subject: IPv6 Loopback/Point-to-Point address allocation All, I’ve been doing some reading in preparation of IPv6 deployment and figuring out how we will break up our /32. I think I’m on the right track in thinking that each customer will be allocated a /48 to do whatever they wish with it. I’ve read recent BCOP drafts that have been approved by the IETF: https://www.ripe.net/publications/docs/ripe-554 It looks like the smallest subnet that should ever be assigned is a /64 on a particular link. Some questions that come to mind with IPv6: In regards to Point to point links my thinking is this: Assign a unique /64 to each point to point link with these addresses being Globally routable. This seems to be what our IX providers do when assigning us an IPv6 address. Am I correct in this train of thought? Why/Why not? In regards to core loopback addressing my initial thoughts are as follows: Assign a single /64 encompassing all /128’s planned for loopback addressing schemes. Should I be using Unique Local addressing for loopbacks instead of going with a Globally routeable addressing scheme? Should each interface IP configuration have a /64 or a /128? Also when talking about CPE mgmt addresses what do you think is a practical way of going about assigning “Private” addressing schemes for cpe management purposes. I’m sure some of these questions will be answered when I dive deeper into how OSPFv6 works as well as BGP in regards to IPv6. Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road?
IPv6 Loopback/Point-to-Point address allocation
All, I’ve been doing some reading in preparation of IPv6 deployment and figuring out how we will break up our /32. I think I’m on the right track in thinking that each customer will be allocated a /48 to do whatever they wish with it. I’ve read recent BCOP drafts that have been approved by the IETF: https://www.ripe.net/publications/docs/ripe-554 It looks like the smallest subnet that should ever be assigned is a /64 on a particular link. Some questions that come to mind with IPv6: In regards to Point to point links my thinking is this: Assign a unique /64 to each point to point link with these addresses being Globally routable. This seems to be what our IX providers do when assigning us an IPv6 address. Am I correct in this train of thought? Why/Why not? In regards to core loopback addressing my initial thoughts are as follows: Assign a single /64 encompassing all /128’s planned for loopback addressing schemes. Should I be using Unique Local addressing for loopbacks instead of going with a Globally routeable addressing scheme? Should each interface IP configuration have a /64 or a /128? Also when talking about CPE mgmt addresses what do you think is a practical way of going about assigning “Private” addressing schemes for cpe management purposes. I’m sure some of these questions will be answered when I dive deeper into how OSPFv6 works as well as BGP in regards to IPv6. Are any of you currently running IPv6 and wished you had done something differently during the planning phase that may have prevented headaches down the road? Kody Vicknair Network Engineer [cid:imagebf3343.JPG@c9d2fbd2.4db10e0d] <http://www.rtconline.com> Tel:985.536.1214 Fax:985.536.0300 Email: kvickn...@reservetele.com Web:www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
RE: Management softwares
Nisc.coop If you can, request that it be hosted in-house as they tend to have an outage at least once a month. O.o Kody Vicknair Network Engineer Tel:985.536.1214 Fax:985.536.0300 Email: kvickn...@reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of K MEKKAOUI Sent: Friday, September 01, 2017 1:56 AM To: nanog@nanog.org Subject: Management softwares Hi We are a medium ISP. We are looking for Management software solutions. We are interested in finding a solution for billing, invoicing, scheduling, ticketing, provisioning and monitoring, Any suggestions or recommendations will be appreciated? We have been using multiple systems which do not communicate. Our objective is to use a single system or at least reduce the number of systems. Thank you KARIM M.
RE: XO SIP in Chicago
Quoted: > Having issues starting at 8:31AM CST with call quality on XO SIP. Inbound calls goes from the number is not available message, to calls completing but very choppy voice quality. Outbound calls seems to work but voice quality is poor. Opened a ticket with XO no call back or engineer picked up the ticket. Anyone else having issues with XO SIP? Judah Sameth | Director of Information Technology judah.sam...@xsportfitness.com p: 630.318.3470 Kody Vicknair Network Engineer Tel:985.536.1214 Fax:985.536.0300 Email: kvickn...@reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Nick Bakker Sent: Thursday, June 01, 2017 10:00 AM To: nanog@nanog.org Subject: XO SIP in Chicago Is anyone else having issues with XO SIP service in the Chicago area? We’re seeing poor audio quality on outbound calls and inbound calls may or may not work. Thanks!
RE: BCP38/84 and DDoS ACLs
When I was doing some research in regards to the same subject I ran across this doc. I've found it to be very helpful. http://nabcop.org/index.php/DDoS-DoS-attack-BCOP Kody Vicknair Network Engineer Tel:985.536.1214 Fax:985.536.0300 Email: kvickn...@reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -Original Message- From: NANOG [mailto:nanog-bounces+kvicknair=reservetele@nanog.org] On Behalf Of Roland Dobbins Sent: Friday, May 26, 2017 12:20 PM To: nanog@nanog.org Subject: Re: BCP38/84 and DDoS ACLs On 26 May 2017, at 22:39, Graham Johnston wrote: > I am looking for information regarding standard ACLs that operators > may be using at the internet edge of their network, on peering and > transit connections, These .pdf presos may be of interest: <https://app.box.com/s/ko8lk4vlh1835p36na3u> <https://app.box.com/s/xznjloitly2apixr5xge> They talk about iACL and tACL design philosophy. What traffic you should permit/deny on your network is, of course, situationally-specific. Depends on what kind of network it is, what servers/services/applications/users you have, et. al. You may need one set of ACLs at the peering/transit edge, and other, more specific ACLs, at the IDC distribution gateway, customer aggregation gateway, et. al. --- Roland Dobbins
RE: 10G MetroE 1-2U Switch
Have you taken a look at the Juniper QFX series? I use these for video multicast and I'm not 100% sure they have support for all the features you've requested, BUT I do know of a competitor that uses them for cheap 10G VPLS deployment. It might be worth looking into. If you need a Juniper engineer to bounce your questions off of, I know a guy... I'd start here: http://www.juniper.net/us/en/products-services/switching/qfx-series/qfx5100/ Kody Vicknair Network Engineer Tel:985.536.1214 Fax:985.536.0300 Email: kvickn...@reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -Original Message- From: NANOG [mailto:nanog-bounces+kvicknair=reservetele@nanog.org] On Behalf Of Erik Sundberg Sent: Thursday, April 13, 2017 4:37 PM To: nanog@nanog.org Subject: 10G MetroE 1-2U Switch Hey Nanog, Looking for a new metroE Edge switch that has more that 10x 10G ports. I am having a hard time finding anything worthwhile without buying a full blown ASR9K Chassis or another vendor's chassis. Requirements MEF compliant 1-2U small foot print 10G Ports will be used for ENNI's and UNI Ports Prefer MPLS support for L2VPN's (EoMPLS and VPLS) QOS per Sub interface\vlan on a ENNI Cost effect 10G Ports 100G Not required Looking at the ASR920's - Great box for 1G but not enough 10G Ports Only 4 NCS5001/NCS5501 - New\unproven\probably buggy, Lacking some features & QOS issues :/ ASR900 - Looks good, but was hoping for a smaller foot print. If I remember right the 8x10G Cards can't go in every slot. Any other platforms I should be looking at? Ciena, Brocade, Juniper? Thanks in advance! -Erik 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.
Re: Juniper QFX port VLAN statistics via SNMP - is it possible?
I haven't tried to do anything like this on ours. Getting a copy of the juniper qfx mib would be a good start. Kody Vicknair Network Engineer [cid:image9d67f5.JPG@a30b92f4.4698f933] <http://www.rtconline.com> Tel:985.536.1214 Fax:985.536.0300 Email: kvickn...@reservetele.com Web:www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Kody Vicknair immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. On Feb 22, 2017 3:34 AM, Stanislaw wrote: Hi everybody, Is it possible to obtain switched traffic statistics in a port+vlan aspect via SNMP on Juniper QFX switches? For example, Extreme switches have a 'vlan monitor' feature: configure ports all monitor vlan then its counters are available by OID .1.3.6.1.4.1.1916.1.2.8.2.1.8 and .1.3.6.1.4.1.1916.1.2.8.2.1.7 Does anyone know if Juniper has a similar feature?
