Blogpost Friday! Networking |
- Blogpost Friday!
- Our ISPs never believe our SD-WAN
- What kind of bag do you carry?
- Eve-ng showing VT-x/AMD-V as disabled(greyed out) in virtual box but other VMs its usable. Anyone had the same problem?
- How dangerous exactly is 100Gbase-LR4?
- IPv6 Mid SizeEnterprise - Give Me a Reason
- SD-WAN guys/gals: which vendor do you prefer?
- Some help with routing through site2site ipsec tunnel to aws
- QoS / CoS on a L2 switch
- Breakout solutions for QSFP-40G-SR4: 40G to 4*10G OM4 Fiber
- Is anyone using NHRP or OpenNHRP w Linux? If so where/how did you install it?
- Anglesey single point of failure
- Asset tracking
- nDPI CSV Export - Help understanding outputs
| Posted: 28 Nov 2019 04:04 PM PST It's Read-only Friday! It is time to put your feet up, pour a nice dram and look through some of our member's new and shiny blog posts Feel free to submit your blog post and as well a nice description to this thread. [link] [comments]  |
| Our ISPs never believe our SD-WAN Posted: 29 Nov 2019 02:28 PM PST One of the coolest parts of SD-WAN is that it constantly monitors the health of our point-to-point tunnels including loss, latency, jitter, out of order packet percent, and MOS. This is awesome because at the click of a button we can see a branch office is experiencing 30% packet loss outbound or having unacceptable jitter, etc. And it's displayed in cool graphs and charts that are also easy for management to digest. The problem is none of our ISPs ever believe a shred of it. It gets almost comically bad at times because like clock work as soon as we mentioned the SD-WAN they immediately get argumentative. One example, our SD-WAN starts showing consistent packet loss in excess of 30% between a single branch office and our data center, in only one direction. Both locations have DIA Fiber from the same provider, in the same city. Pretty clear indication that something is wrong right? We're asked to provide some evidence of the problem we're experiencing and we put a picture of the little graph in our SD-WAN orchestrator showing consistent one way packet loss between these two sites. Immediately: "nuh uh that's wrong. That doesn't mean anything." It's like as soon as SD-WAN is even mentioned they immediately shut down and get unhelpful. At one point we were even told "we're an ISP we don't drop packets." And they try to tell us the circuit passed a test so that proves the problem isn't them. We tell them no, that circuit is talking to 100 other sites with under 1% loss, the problem is only when these two sites talk directly to each other. We even run trace routes and reverse lookups and tell them "Look at Router AGG-RTR-XXX01." They assure us "No, that's impossible the problem is on your end and that's that. Please open a ticket with your SD-WAN vendor." Fast forward like a month later and the loss magically disappears and the ticket gets stealth closed with no updates. Yeah sure they definitely didn't find something on their end and fix it. rollseyes In other case a bigger problem showed many down tunnels and huge loss all over the place and after investigation it looks like every problem is when a specific ISP A is trying to talk to a specific ISP B. We take our findings to the provider and same old story "you might want to call your SD-WAN vendor, because we don't have anything like that going on." Fast forward multiple escalation later and magically our ticket was linked to another Master Ticket and they're bouncing ports and cleaning fiber at some NNI, and all the sudden everything goes back to normal after they resolve the Master Ticket. I wonder why it is met with so much skepticism despite being battle tested?? I mean a lot of these ISPs are offering their own SD-WAN solutions too as a managed service, so they must believe in them? Anyway my advice to anyone on here doing SD-WAN that has to bring up a ticket with a provider: Don't mention SD-WAN as soon as you do they will stop taking you seriously. If you can, re-create the issue with other traditional tools and present that to them instead. Ok I'm done ranting for now! [link] [comments]  |
| What kind of bag do you carry? Posted: 29 Nov 2019 06:34 AM PST Network engineers, technicians, cable installers and all other workers who build, manage and troubleshoot large network infrastructures, what kind of bag and tools do you carry with you into the field? I'm looking to put together a new toolkit along with a way to conveniently carry most of this equipment from site to site. I'm interested in hearing how most of you make the tools you need into more of a convenience and less of a hassle. Some of the equipment I find necessary to have on hand most of the time.
It would be nice if there were some convenient to carry bag for all of this. What do you do in this situation? [link] [comments]  |
| Posted: 29 Nov 2019 01:16 PM PST |
| How dangerous exactly is 100Gbase-LR4? Posted: 28 Nov 2019 10:42 PM PST We're moving from 10Gbase-LR to 100Gbase-LR4 at my work. I know that looking down fibres is never a good idea (and it's outside visible spectrum anyhow) However, the consensus around 10Gbase-LR is that in general you should be ok, even if you accidentally glance briefly at it, as the power levels are quite low. (Although still a bad habit to have) What about 100Gbase-LR4? Is this the sort of where I should be wearing safety glasses around it? (Just concerned somebody on my team new to fiber might try it, or decide to monkey around) [link] [comments]  |
| IPv6 Mid SizeEnterprise - Give Me a Reason Posted: 28 Nov 2019 07:36 PM PST Hi all- I'd like someone to give me a legitimate (reasons to executives) reason why I should start moving my middle sized enterprise towards IPv6. I've read about/listened to all the podcasts saying we need to start making this move. In the real world though no middle sized company appears to actually be doing this. The only real benefit I've heard so far for a middle sized enterprise is security related -- ie. remote users being forced to tunnel through corporate security functions. I'm really interested in the topic but I still at this point do not see the reason why an organization not running out of RFC1918 would even try to implement IPv6. Please give me reasons, I'm very interested. [link] [comments]  |
| SD-WAN guys/gals: which vendor do you prefer? Posted: 29 Nov 2019 03:28 PM PST I only started working with SD-WAN about 2 years ago. I did a PoC with Talari Networks (recently acquired by oracle), Silver Peak, and Meraki (Meraki is NOT SD-WAN.). I ended up going with talari because it was not a subscription-based model, so the price was right. Only Down fall was that the config editor was clearly just a fancy way to display a .xml file (literally the way it expands you can tell where in the xml file the setting will sit... So maybe that's a pro depending on perspective.) Anyway, for those of you who have some legit experience with multiple vendors, who do you like best, and why? *My irrelevant passion regarding "SD-WAN": Why do we call this technology Software-Defined WAN? The WAN has always been Software-Defined. Routing is software. "SD-WAN" is just another Routing Protocol that, like BGP, runs at L4 with health-checks built-in. But hey, "SD-WAN" sounds cool, right? [link] [comments]  |
| Some help with routing through site2site ipsec tunnel to aws Posted: 29 Nov 2019 06:12 AM PST Hi, I'm pretty new to juniper devices, but somehow i've managed to set up the tunnels to aws with 2 srx firewalls. But I now have a problem with routing through the tunnels and accessing the virtual machines on the aws end. This is the show route output. As you can see the network 10.255.255.0/24 is accessible via the 2 tunnel interfaces, but for some reason I can not ping 10.255.255.10 which is a vm that has no firewall. Also I've setup policies that ALLOW all traffic between the 2 zones that i have - trusted and untrusted. Just to be sure that it's not the firewall blocking the packets. Any ideas ?
[link] [comments]  |
| Posted: 29 Nov 2019 12:52 AM PST We have a L2 switch in front of our ISP demarcation point. The service is for VoIP, so at layer 3, that's the ISP's issue. Once we mark our RTP traffic as "EF", it is kept as "EF" and everything else is remarked accordingly by the ISP (most just gets re-marked to AF21 and AF41). What I want to know is, is there anything we need to do with our switch with regards to CoS? We have policy and class maps on the switch to keep the DSCP markings that are received from the ISP, and to mark our RTP traffic as "EF". But is this the correct thing to do, or do I need to do more on the switch? [link] [comments]  |
| Breakout solutions for QSFP-40G-SR4: 40G to 4*10G OM4 Fiber Posted: 29 Nov 2019 12:33 AM PST I was looking for a new network setup (Nexus 93108TC-FX) and found the below solution. (Almost all servers are 10GBase-T, but I need some 10GB-SFP+ for some appliances as well. hence this. Would like to stick with Cisco Nexus) More reasoning in a previous post. http://www.panduit.com/heiler/TechnicalReferences/D-FBTR123--WW-ENG-40GTO10GSOLUTION.pdf In short this is a patchpanel solution with MPO cassettes to LC to make the patching with a standard LC fibre cable very easy and clean. These MPO cassettes are directly connected with a 'special' cable to the QSFP-40G-SR4 This seems really nice and clean. Has someone some experience with this? Some remarks? Are you happy or dissatisfied or did it simply not work or ... [link] [comments]  |
| Is anyone using NHRP or OpenNHRP w Linux? If so where/how did you install it? Posted: 29 Nov 2019 06:49 AM PST I've been doing quite a bit of searching and NHRP (or OpenNHRP) doesn't seem to exist in any debian or ubuntu repository unless I am missing something. I do see it is available in applications like Quagga or FRR but does anyone know how to just install it on its own? Or where to get the latest version of the code? thanks [link] [comments]  |
| Anglesey single point of failure Posted: 29 Nov 2019 06:24 AM PST Hi. I've been told by a business i'm doing some work for that the Isle of Anglesey has a single connectivity cable to mainland UK via the Britannia bridge so if something happens there, fire etc. the entire island would lose internet connectivity and therefore they wanted suggestions for resilience as they are becoming more reliant on it. Looking at the submarine cable map I can see that there are actually two fibre lines connecting Holyhead to Ireland. Would the business just need to engage with an Irish ISP to take advantage of this route? None of the UK providers would use this route (i don't think) as Ireland is a foreign country. The management companies of the lines offer dark fibre etc. but the business has no presence in Ireland and therefore nothing to connect to at the other end. This isn't my area of expertise so not entirely sure what the business would need to do to get Internet over these lines or if it's even possible? Any suggestions? Thanks [link] [comments]  |
| Posted: 29 Nov 2019 01:08 AM PST Hi Guys, We are a team which provide IT support to a large warehouse. One of the devices we support are barcode scanners and Operations are losing them at a rate of 1 per day. As these scanners are costly to replace we are asked to find a solution to stop the scanners leaving the warehouse. We see that on our system the lost scanners are last seen near dock doors which brings us to the conclusion that workers are leaving the scanners on pallets when loading on truck trailers which are leaving docks. Our idea is to have some RFID stickers on the scanners and have some sensor in front of Dock doors which would light up in realtime to let us know that the scanner has passed through them. It will should give us the details of the scanner and time when it was passed through the sensor Is there already some system that can be implemented that we can utilise or give us ideas how to develop one ? [link] [comments]  |
| nDPI CSV Export - Help understanding outputs Posted: 28 Nov 2019 05:22 PM PST HI all Looking at the exports I can see alot of useful information like source and destination IP and port, and protocol used, But im trying to understand why it has source to destination bytes as well as destination to source bytes I would have assumed that traffic only flows from the source to the destination, I dont see why there should be a destination to source traffic. or is nDPI being clever and bundling stuff together? Hopefully someone can help answer my question. [link] [comments]  |
| You are subscribed to email updates from Enterprise Networking news, blogs and discussion.. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |
No comments:
Post a Comment