It is a common design to have an internet Edge router connected to two different internet service providers to protect against the failure of an ISP bringing the office down. The topology may look something like this:
The two ISPs are used in an active/standby fashion using static routes. This is normally implemented by using two default routes where one of the routes is a floating static route. It will look something like this:
ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY ip route 0.0.0.0 0.0.0.0 203.0.113.9 200 name SECONDARY
With this configuration, if the interface to ISP1 goes down, the floating static route which has an administrative distance (AD) of 200 will be installed and traffic will flow via ISP2. The drawback to this configuration is that it only works if the physical interface goes down. What happens if ISP1’s CPE has the interface towards the customer up but the interface towards the ISP Core goes down? What happens if there is a failure in another part of the ISP’s network? What if all interfaces are up but Continue reading
Hello my friend,
Recently we’ve been working on an interesting (at least for me) project, which is an MVP of the highly available infrastructure for web services. There are multiple approaches existing to create such a solution including “simply” putting everything in Kubernetes. However, in our case we are building a solution for a telco cloud, which is traditionally not the best candidate for a cloud native world. Moreover, putting it to Kubernetes will require to build a Kubernetes cluster first, which is completely separate magnitude of the problem. Originally we were planning to write this blogpost the last weekend, but it took us a little bit longer to put everything together properly. Let’s see, what we are to share with you.
1
2
3
4
5 No part of this blogpost could be reproduced, stored in a
retrieval system, or transmitted in any form or by any
means, electronic, mechanical or photocopying, recording,
or otherwise, for commercial purposes without the
prior permission of the author.
Yes, today’s blogpost is dedicated to the network technologies (to a huge mix of different network and infrastructure technologies, to be honest). That’s why there Continue reading
Thus far, I’ve concluded that IP addresses and other information network operators handle is personally identifiable (PII) and covered under privacy and security regulations. I’ve also looked at the data lifecycle and user rights related to private data. What are some best practices network operators can follow to reduce their risk? The simplest way to […]
The post Privacy and Networking Part 6: Essential Questions For Privacy Best Practices appeared first on Packet Pushers.
If you’ve worked at an ISP or even just closely with them you’ve probably hearing the term peering quite a bit. Peering is essentially a reciprocal agreement to provide access to networks between two providers. Provider A agrees to allow Provider B to send traffic over and through their network in exchange for the same access in the other direction. Sounds easy, right? On a technical level it is pretty easy. You simply set up a BGP session with the partner provider and make sure all the settings match and you’ve got things rolling.
The technical part isn’t usually where peering gets complicated. Instead it’s almost always related to the business side of things. The policy and negations that have to happen for a good peering agreement take way more time that hammering out some BGP configuration stanzas. The amount of traffic to be sent, the latency requirements, and even the cost of the agreement are all things that have to be figured out before the first hello packet can be exchanged. This agreement is always up for negotiation too, since the traffic patterns can change before you realize it and put you at a disadvantage.
What does privacy have to do with running a network? Is protecting the privacy of users, customers, and the organization one of the responsibilities of the networking team? If so, what kind of information has to be kept private and how? Should privacy efforts focus on compliance, or on risk reduction? How are those different? On today’s Heavy Networking podcast we welcome Russ White to tackle these perplexing privacy questions.
The post Heavy Networking 643: Privacy Responsibilities Of Running A Network appeared first on Packet Pushers.
Learning Kubernetes isn't easy. In fact, there are so many places to start that people literally don’t know where to begin. Do they learn Kubernetes security? Networking? Infrastructure? Development? Michael Levan catches up with Kevin Evans and Robin Smorenburg to talk about their journeys into Kubernetes, how each of them started, links to learning resources, and where they’re at now.
The post Kubernetes Unpacked 007: Kubernetes From Beginner To Advanced appeared first on Packet Pushers.