TimeWarner (Spectrum) Voice contact
Anyone have a contact at TimeWarner (aka Spectrum) Voice services that you could pass along to me? MUCH appreciated! Andy Ringsmuth a...@newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397(402) 304-0083 cellular
[NANOG-announce] NANOG 72 agenda update and Hackathon
This message has been wrapped due to the DMARC policy setting to prevent NANOG subscribers from being unsubscribed due to bounces. --- Begin Message --- NANOG Community, The program committee has updated the NANOG 72 agenda, which is available at: https://www.cvent.com/d/1tqlzk/16K In addition to the previously announced programming, we will have a keynote by Scott Bradner on the history of the internet, John Curran will speak on ARIN's IRR Roadmap, and we'll have a panel of IETF Area Directors discussing their ongoing efforts. Over 500 attendees have registered to date. Registration is available at: https://www.cvent.com/d/1tqlzk Seats are still available for the Hackathon on Sunday; separate registration is required at: https://www.cvent.com/d/1tqlzk/4K Regards, Ryan Woolley NANOG Program Committee --- End Message --- ___ NANOG-announce mailing list nanog-annou...@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce
Reminer: FCC seeks comments on 2017 hurricane season respons
Just a reminder, the Federal Communications Committee is still collecting comments on the 2017 hurricane season. https://apps.fcc.gov/edocs_public/attachmatch/DA-17-1180A1.pdf PUBLIC SAFETY AND HOMELAND SECURITY BUREAU SEEKS COMMENT ON RESPONSE EFFORTS UNDERTAKEN DURING 2017 HURRICANE SEASON PS Docket No. 17-344 Comments Due: January 22, 2018 Reply Comments Due: February 21, 2018 The Public Safety and Homeland Security Bureau (PSHSB or Bureau) of the Federal Communications Commission (FCC or Commission) seeks comment on the resiliency of the communications infrastructure, the effectiveness of emergency communications, and government and industry responses to the 2017 hurricane season. [...]
evil ipv6 bit?
Hello After some apparently unrelated changes, one of my routers stopped routing traffic to a few IPv6 destinations. After a lot of experimentation, including rebooting (did not help), I found this: archive.ubuntu.com: 2001:67c:1360:8001::17 "ping6 vrf internet 2001:67c:1360:8001::17" from the router shell works. ping6/traceroute from a customer connection has the packet dropped by the router. Traceroute gets nothing back at all. 2001:67c:1360:7fff:: is ok. Does not reply to ping because I just made up that address. But I get a valid traceroute all the way to the destination. Anything between 2001:67c:1360:8000:: and 2001:67c:1360::::: is dropped. My route table looks like this: albertslund-edge1#show ipv6 forwarding route vrf internet 2001:67c:1360:8001::17 IPv6 Routing Table: Headers: Dest: Destination, Gw: Gateway, Pri: Priority; Codes : K: kernel, I1: isis-l1, SFN: sf-nat64, R: ripng, AF: aftr, B: bgp, D: direct, I2: isis-l2, SLN: sl-nat64, O: ospfv3, D6: dhcp, P: ppp, S: static, N: nd, V: vrrp, A: address, M: multicast, UI: user-ipaddr, GW-FWD: PS-BUSI,GW-UE: PS-USER,LDP-A: LDP-AREA, UN: user-network, US: user-special; Dest OwnerMetric Interface Pri Gw 2001:67c:1360::/48B 0 xgei-0/0/0/6200 :::185.24.168.254 ::/0 B 0 xgei-0/0/0/6200 :::185.24.168.254 Notice how this is a /48 route and one bit at the /49 level changes how it is routed. That is not right. I tried adding a /128 static route but that does not do anything. The packet is still dropped. I just now discovered this: google.com: 2a00:1450:400e:807::200e That address works fine. But then I changed that one bit in the address: 2a00:1450:400e:8807::200e and voila, the router drops the packet. Now I am stumbled. What could the 49th bit in the destination IPv6 address field in a packet mean to the router, that would make it drop the packet? Some extra information about the network: We are using MPLS with l3vpn (vrf) and l2vpn (vpls). The traffic is qinq tagged before being transported in a l2vpn towards the router in question. The l2vpn does not transport the outer vlan tag. The l2vpn is then terminated on a loopback cable. On the other end of that loopback cable we receive the traffic as ordinary qinq tagged without MPLS tagging. It is on this interface the router apparently drops the packet. It might conceivably also drop the packet on the way out of the l2vpn. I have a similar setup, but instead of a loopback cable, the l2vpn is terminated on another MPLS switch, which then connects to a router of the same model. This setup does not have the problem. The change I introduced was changing from an internal interface called "bvi" to the loopback cable. The bvi interface is a simulated loopback cable construct. We are dropping the bvi interface because it is very buggy. We did not have this problem with the bvi interface however. The hardware is ZTE M6000-S V3.00.20(3.40.1). Thanks, Baldur
improving signal to noise ratio from centralized network syslogs
Hey All, Centralized logging is a good thing. However, what happens is that every repetitive, annoying but not (usually) important thing fills up the log with reams of what you are not looking for. Networks are a noisy place and silencing every logged condition is impractical and sometimes undesirable. What I am interested in is an automated zoom-in zoom-out tool to mask the repetition of "normal" events and allow the unusual to stand out. Add to that an ability to identify gaps in the background noise. (The dog that didnt bark) What I am not interested in are solutions based upon preconfigured filters and definitions and built in analysis for supported (prepopulated definitions) platforms, this is all about pattern mining/masking and should be self discoverable. Ideally a command tool to generate static versions of the analysis coupled with a web platform (with zoom +- buttons) for realtime. I made a crude run of it with SLCT, using its generated patterns to grep -v, and that in and of itself was useful, but needs a bit of work. Also, its not quite real time. Any ideas would be greatly appreciated. Joe
Re: improving signal to noise ratio from centralized network syslogs
On Thu, Jan 25, 2018 at 8:11 PM Joe Maimon wrote: > Hey All, > > Centralized logging is a good thing. However, what happens is that every > repetitive, annoying but not (usually) important thing fills up the log > with reams of what you are not looking for. > > Networks are a noisy place and silencing every logged condition is > impractical and sometimes undesirable. > > What I am interested in is an automated zoom-in zoom-out tool to mask > the repetition of "normal" events and allow the unusual to stand out. > > Add to that an ability to identify gaps in the background noise. (The > dog that didnt bark) > > What I am not interested in are solutions based upon preconfigured > filters and definitions and built in analysis for supported > (prepopulated definitions) platforms, this is all about pattern > mining/masking and should be self discoverable. Ideally a command tool > to generate static versions of the analysis coupled with a web platform > (with zoom +- buttons) for realtime. > > I made a crude run of it with SLCT, using its generated patterns to grep > -v, and that in and of itself was useful, but needs a bit of work. Also, > its not quite real time. > > Any ideas would be greatly appreciated. Not cheap, but Splunk comes to mind. > > > Joe > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler
