November 21, 2017

Networking Now (Juniper Blog)

Effective Microsegmentation in VMware NSX deployments with Juniper SDSN

Data centers using Juniper Networks vSRX Virtual Firewall and Junos Space Security Director with Policy Enforcer in combination with VMware’s NSX platform can microsegment intra-data center traffic to effectively defend applications and systems against threat propagation in both north-south and east-west traffic.

by praviraj at November 21, 2017 04:24 PM

Effective Microsegmentation in VmWare NSX deployments with Juniper SDSN

Data centers using Juniper Networks vSRX Virtual Firewall and Junos Space Security Director with Policy Enforcer in combination with VMware’s NSX platform can microsegment intra-data center traffic to effectively defend applications and systems against threat propagation in both north-south and east-west traffic.

by praviraj at November 21, 2017 03:57 PM

My Etherealmind
ipSpace.net Blog (Ivan Pepelnjak)

Feedback: Ansible for Networking Engineers

Got this feedback on my Ansible for Networking Engineers webinar:

This webinar is very comprehensive compared to any other Ansible webinars available out there. Ivan does great job of mapping and using real life example which is directly related to daily tasks.

The Ansible online course is even better: it includes support, additional hands-on exercises, sample playbooks, case studies, and lab instructions.

However, Ansible is just a tool that shouldn’t be missing from your toolbox. If you need a bigger picture, consider the Building Network Automation Solutions online course (and register ASAP to save $700 with the Enthusiast ticket).

by Ivan Pepelnjak (noreply@blogger.com) at November 21, 2017 07:03 AM

November 20, 2017

Moving Packets

Unifi US-8 PoE Passthrough With The Cisco 3560CX

As part of my “everything should be on a UPS” strategy, I recently replaced a regular 8-port gigabit switch with a Ubiquiti Unifi US-8 Ethernet switch because the US-8 can be powered using POE (Power Over Ethernet) provided by a UPS-protected switch in my basement, so it should stay up in the event of a power outage. This also allowed me to indirectly provide UPS protection for the Ubiquiti wireless AP in that location because the US-8 has a PoE passthrough port with which I could power the AP. Clever, right?

Ubiquiti Unifi Us-8 with POE Passthrough

 

POE Passthrough

To clarify (because a picture is worth many thousands of my words), here’s how things were:

Before the Unifi US-8

And here’s how things are after installing the Ubiquiti Unifi US-8:

After the Unifi US-8 with POE Passthrough

The new setup worked well, but I noticed after a few days that the uptime for the Unifi US-8 kept on resetting; that is, it appeared to be rebooting. The Cisco 3560CX switch which is providing the POE can supply 30W per port, which is plenty enough for the US-8 and the wireless AP to be daisy-chained like this, yet when I looked at the logs on the 3560CX, I found an error:

Oct 23 18:23:12.124 UTC: %ILPOWER-3-CONTROLLER_PORT_ERR: Controller port error, Interface Gi0/1: Power Controller reports power Imax error detected

The error indicates that the attached device was trying to draw too much power, which resulted in the port being reset. I checked the inline power status and it seemed like things were ok:

3560CX#show power inline
Available:240.0(w) Used:46.2(w) Remaining:193.8(w)

Interface Admin  Oper       Power   Device              Class Max
                            (Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Gi0/1     auto   on         15.4    Ieee PD             0     30.0
Gi0/2     auto   on         15.4    Ieee PD             0     30.0
Gi0/3     auto   on         15.4    Ieee PD             0     30.0

Courtesy of quick internet search, I found a Cisco Support Forum post where a bug was mentioned with some switches including the 3560-X, though not specifically the 3560CX. Just in case this was the issue I upgraded the IOS, but unfortunately the same error continued to occur after the upgrade. Then I spotted that the forum post also mentioned a command which might have to be issued to address the problem:

Switch(config)# int x/y
Switch(config-if)# power inline port 2x-mode
Switch(config-if)# shut
Switch(config-if)# no shut

Sadly, that command does not exist on my 3560CX; but thankfully this one does:

3560CX(config)#interface Gi0/1
3560CX(config-if)#power inline port 2-event
3560CX(config-if)#shut
3560CX(config-if)#no shut

When the port came back up I checked the inline power status, and noted that Gi0/1 was now showing as a Class 4 device and had been allocated 30W rather than 15.4W:

3560CX#show power inline
Available:240.0(w)  Used:60.8(w)  Remaining:179.2(w)

Interface Admin  Oper       Power   Device              Class Max
                            (Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Gi0/1     auto   on         30.0    Ieee PD             4     30.0
Gi0/2     auto   on         15.4    Ieee PD             0     30.0
Gi0/3     auto   on         15.4    Ieee PD             0     30.0

I checked the inline power history for Gi0/1, and after booting up, the power drawn seemed well within the original 15.4w requested:

3560CX#show power inline gigabitEthernet 0/1 det | i Maximum
 Maximum Power drawn by the device since powered on: 11.4

After a few days I checked back in on the status of the US-8 and the port on the Cisco 3560CX. The US-8 had not rebooted since I made the change above, and checking the individual port I found this:

3560CX#sh power inline gigabitEthernet0/1 detail | include Maximum
 Maximum Power drawn by the device since powered on: 16.1

At some point the total current draw of the US-8 (and the AP via passthrough) had evidently exceeded 15.4W, which was why the port was complaining. Checking it previously had failed to show this error because the statistic is only valid since powered on, so every time the power maximum was exceeded, the port was reset, and as the US-8 powered up, the statistics reset. It does me think that it would help if the logs actually said Device used 16.1W, exceeding Imax or something, because otherwise that data point is lost.

My 2 Bits

Once the IOS was upgraded and the 2-event command added to the configuration, the POE passthrough worked perfectly. I now have a switch and an AP in a remote location which are effectively UPS-protected because they pull their power from a centrally-located Cisco 3560CX which is on a UPS. I’m happy!

If you liked this post, please do click through to the source at Unifi US-8 PoE Passthrough With The Cisco 3560CX and give me a share/like. Thank you!

by John Herbert at November 20, 2017 09:47 PM

My Etherealmind

Nutanix: We don’t need a traditional channel program | Channelnomics

Interesting piece on Nutanix and resellers: Nutanix’s senior director of EMEA channels Jan Ursi has defended against a claim the firm has no clear channel strategy, suggesting that the hyperconverged vendor does not rely on conventional methods, such as reward programs, in order to foster partner relationships. Some thoughts Building a reseller channel is expensive […]

by Greg Ferro at November 20, 2017 03:03 PM

ipSpace.net Blog (Ivan Pepelnjak)

Why Does It Take So Long to Upgrade Network Devices?

One of my readers sent me a question about his favorite annoyance:

During my long practice, I’ve never seen an Enterprise successfully managing the network device software upgrade/patching cycles. It seems like nothing changed in the last 20 years - despite technical progress, in still takes years (not months) to refresh software in your network.

There are two aspects to this:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 20, 2017 06:59 AM

XKCD Comics

November 19, 2017

IPEngineer.net

Network Automation Engineer Persona: Proof-of-concepts

If you’ve chosen to do a proof-of-concept (PoC), you should already know what the challenge or requirement is, what your satisfactory results look like and what the product or tool set is that will deliver on your commitment. A proof-of-concept is a recipe that should give you a well baked set of results.

Approaching a PoC

Approaching a PoC is a conscious decision to trial an idea that if successful, your business will put in to daily production to satisfy one or more business requirements.

So why aren’t the results more apparent in our day to day lives? Why do we not see these decision points more transparently?

Some people approach PoCs as a tyre kicking exercise, or a means to get a vendor to commit to them and then use as leverage against cost. If you’re just playing, you’re wasting time. If you’re tyre kicking then be prepared for lack of commitment or interest in the future from individuals or organisations. Genuine PoCs and evaluations are a normal and acceptable part of business, so the responses are different from those assisting with PoCs.

Approach a PoC with clear intent and understanding of the challenge that faces you. You must know the requirements laid out in the following section.

Business Challenge_PoC Requirements

a) The business requirement
b) Benefit to the business
c) Satisfactory results from the PoC
d) Budget
e) Skill requirement / additions
f) Business integration time
g) Support cost and commitments

If you’re doing a PoC based on a whim or “everyone else is, so let’s do the same!”, then good luck. You will probably fail or get accused of wasting time and money.

Culture

Danger danger! Culture is the C word of recent times. If your culture is based in a different century, then PoCs using more recent products and tools may cause you significant stress. You might run a totally acceptable PoC and have your manager turn around and say “This product or tool resembles a science experiment, I’m not going to support this”. Your response might be “How infuriating? Do you not know what this could do for us?”. Unless you can prove you know the business challenge information for this PoC, then you’re dead. It’s down to you to get these points across. People from all walks of life work in this industry and clear communication can be the deal maker or breaker. When someone disagrees and it’s apparent they do not understand, it does not mean they’re wrong, it might mean you need to help to get them up to speed on where we are as an industry. Click and point complicated UIs from the 90s are no longer the route to go when purchasing. If that’s the last time they touched ‘automation’, then have some patience and empathy for the rapid changes we’re seeing as an industry.

Device Programmability

If your devices do not offer a rich structured API then the responsibility to insert and retrieve data to and from those devices is now pushed to the automation platform or tool.

Good devices offer a REST, NETCONF and possibly even a gRPC interface. Look at this list put together by Ivan Pepelnjak and others here: network automation rfp requirements

More recently, Juniper announced the work they’ve been doing with Facebook on Open/R. This is another great example of device level programmability, software extensibility and problem solving with great results. Routing aficionados would probably disagree with the approach, but Facebook’s requirements are being satisfied, so who is right here?

Automation Product

Does the automation tool have the capability to drive network device APIs? Some tools are totally agnostic and offer zero support out of the box. Some tools are built for the job but may be less flexible when it comes to data handling and decision making in workflows.

More agnostic platforms offer huge rewards in terms of flexibility and integration opportunities, but you might have to do some coding to make them fit to your exact requirements. This coding may be in the form of an integration or extension work.

Specific platforms that talk the language of the network device may not offer rich workflow capabilities and you might rely entirely on the vendor to integrate against your other systems. Sometimes these are referred to as “point source” things.

Open Source platforms are influenced by a user community. It is possible to create pull requests and add/modify code and influence the community to add the features you need or seek advice on how to achieve one of your goals.

Vendor driven and closed source products, unless they have specific claims of extensibility (forget Open APIs, these are different things), then you’re at the vendor’s mercy when it comes to support, adding features and seeking ways to solve your challenges if they’re not immediately obvious.

With this space maturing, you can expect software service houses to offer support for Open Source products if you go down that route.

Some pointers on offer:

a) Consider the pros and cons of open source vs vendor offered
b) Does the automation platform offer network device integration out of the box? Or is the platform agnostic, requiring plugins and extensions?
c) What APIs does the automation platform have? REST, gRPC, GraphQL? The more integrated we become, the more connected things get. Not having GraphQL might not be an issue today, but it might be tomorrow. Know the road-map!
d) What is upgradability like? Is it hard? Will this become a pet? Again, Ivan covers this off with the upgrading virtual appliances blog and I cover it off with the upgrading an automation platform blog post.

Conclusion

Plan, think, empathize and understand your business requirements. Other people would have come before you and other people will come after you. You deal with historic problems and right now, you’re creating problems for the future team and future you. Every business has the issue of the current person taking care of the mess left behind by the last person and if you do things right, your mess will be more manageable for the next person. Good PoCs not only show how well the business problems are understood, but they can offer much needed oil and clear vision into the business. Automation continues to grow deeper and wider and as an automation person reading this post, your impact can be huge if you’re targeted and methodic.

Make your next PoC a great one.

The post Network Automation Engineer Persona: Proof-of-concepts appeared first on ipengineer.net.

by David Gee at November 19, 2017 11:30 AM

ipSpace.net Blog (Ivan Pepelnjak)

November 17, 2017

The Networking Nerd

Predictions As A Service

It’s getting close to the end of the year and it’s time once again for the yearly December flood of posts that will be predicting what’s coming in 2018. Long time readers of my blog know that I don’t do these kinds of posts. My New Year’s Day posts are almost always introspective in nature and forward looking from my own personal perspective. But I also get asked quite a bit to contribute to other posts about the future. And I wanted to tell you why I think the prediction business is a house of cards built on quicksand.

The Layups

It’s far too tempting in the prediction business to play it safe. Absent a ton of research, it’s just easier to play it safe with some not-so-bold predictions. For instance, here’s what I could say about 2018 right now:

  • Whitebox switching will grow in revenue.
  • Software will continue to transform networking.
  • Cisco is going to buy companies.

Those are 100% true. Even without having spent one day in 2018. They’re also things I didn’t need to tell you at all. You already knew them. They’re almost common sense at this point. If I needed to point out that Cisco is going to buy at least two companies next year, you are either very new to networking or you’ve been studying for your CCIE lab and haven’t seen the sun in eight months.

Safe predictions have a great success rate. But they say nothing. However, they are used quite a bit for the lovely marketing fodder we see everywhere. In three months, you could see presentation from an SD-WAN vendor that says, “Industry analyst Tom Hollingsworth predicts that 2018 is going to be a big year for software networking.” It’s absolutely true. But I didn’t say SD-WAN. I didn’t name any specific vendors. So that prediction could be used by anyone for any purpose and I’d still be able to say in December 2018 that I was 100% right.

Playing it safe is the most useless kind of prediction there is. Because all you’re doing is reinforcing the status quo and offering up soundbites to people that like it that way.

Out On A Limb

The other kind of prediction that people love to get into is the crazy, far out bold prediction. These are the ones that get people gasping and following your every word to see if it pays off. But these predictions are prone to failure and distraction.

Let’s run another example. Here are four bold sample predictions for 2018:

  • Cisco will buy Arista.
  • VMware will cease to be a separate brand inside Dell.
  • Hackers will release a tool to compromise iPhones remotely.
  • HPE will go out of business.

Those predictions are more exciting! They name companies like Cisco and VMware and Apple. They have very bold statements like huge purchases or going out of business. But guess what? They’re completely made up. I have no insight or research that tells me anything even close to those being true or not.

However, those bold predictions just sit out there and fester. People point to them and say, “Tom thinks Cisco will buy Arista in 2018!” And no one will every call me on the carpet if I’m wrong. If Cisco does end up buying Arista in 2020 or later, people will just say I was ahead of my time. If it never comes to pass, people will forget and just focus on my next bold prediction of VMware buying Cisco. It’s a hype train with no end.

And on the off chance that I do nail a big one, people are going to think I have the inside track. My little predictions will be more important. And if I hit half of my bold ones, I would probably start getting job offers from analyst firms and such. These people are the prediction masters extraordinaire. If they aren’t telling you something you already know, they’re pitching you something that have no idea about.

Apple has a cottage industry built around crazy predictions. Just look back to August to see how many crazy ideas were out there about the iPhone X. Fingerprint sensor under the glass? 3D rear camera? Even crazier stuff? All reported on as pseudo-fact and eaten up by the readers of “news” sites. Even the people who do a great job of prediction based on solid research missed a few key details in the final launch. it just goes to show that no one is 100% accurate in bold predictions.


Tom’s Take

I still do predictions for other people. Sometimes I try to make tongue-in-cheek ones for fun. Other times I try to be serious and do a little research. But I also think that figuring out what’s coming 5 years from now is a waste of my time. I’d rather try to figure out how to use what I have today and build that toward the future. I’d rather be a happy iPhone user than the people that predicted that Apple’s move into the mobile market would fail miserably. Because that’s a headline you’ll never live down.

I’d like to thank my friends at Network Collective for inspiring this post. Make sure you check out their video podcast!


by networkingnerd at November 17, 2017 03:40 PM

ipSpace.net Blog (Ivan Pepelnjak)
XKCD Comics

November 16, 2017

My Etherealmind
ipSpace.net Blog (Ivan Pepelnjak)

Pluribus Networks… 2 Years Later

I first met Pluribus Networks 2.5 years ago during their Networking Field Day 9 presentation, which turned controversial enough that I was advised not to wear the same sweater during NFD16 to avoid jinxing another presentation (I also admit to be a bit biased in those days based on marketing deja-moo from a Pluribus sales guy I’d been exposed to during a customer engagement).

Pluribus NFD16 presentations were better; here’s what I got from them:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 16, 2017 08:12 AM

November 15, 2017

Networking Now (Juniper Blog)

So many things, so little security

As the "Internet of Things (IoT)" phenomenon is catching on in a big way, I wanted to quickly capture the state of affairs of IoT in the context of security and how different Juniper technologies can help provide security to IoT infrastructure as well as protect other enterprise infrastructure from IoT devices

by snimmagadda at November 15, 2017 11:28 PM

ipSpace.net Blog (Ivan Pepelnjak)

Run Well-Designed Experiments to Learn Faster

I know that everyone learns in a slightly different way. Let me share the approach that usually works well for me when a tough topic I’m trying to master includes a practical (hands-on) component: running controlled experiments.

Sounds arcane and purely academic? How about a simple example?

A week ago I talked about this same concept in the Building Network Automation Solutions online course. The video is already online and you get immediate access to it (and the rest of the course) when you register for the next live session.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 15, 2017 07:53 AM

XKCD Comics

November 14, 2017

Moving Packets

How To Access Devices with Unsupported SSL Ciphers

With the HeartBleed bug effectively killing off SSLv3 and vulnerabilities in cipher block chaining ruling out another whole swathe of SSL ciphers, network engineers may have found themselves trying to connect to a device and either getting no response (Safari), or getting a response like this (Chrome):

Chrome SSL Error

Or this (Firefox):

Firefox SSL Error

Once upon a time, it was possible to go into settings and enable the old, insecure ciphers again, but in more recent updates, those ciphers no longer exist within the code and are thus inaccessible. So what to do? My answer was to try a proxy.

Charles Proxy

The first proxy I looked at seemed promising. Although not free, Charles Proxy offers a 30 day free trial, and that seemed like a good thing to try. It’s limited additionally by only running for 30 minutes at a time before it has to be reloaded, but for my testing purposes that was not a problem.

During installation I declined to give Charles Proxy permission to configure the system proxy settings. Instead, I manually updated just my Firefox browser to use the proxy which was now listening on port 127.0.0.1:8888. Since I was making an SSL connection, I also had to specifically allow the proxy to act as man in the middle, so added my target device to the list. I like that the default is not to intercept SSL; I think that’s a responsible position to take.

And, well, that’s it. I typed the URL into Firefox, and finally I was able to connect to the evil device with the bad ciphers. Once I had updated the firmware, I was able to remove the proxy and uninstall Charles Proxy because the device finally supported some better ciphers.

My 2 Bits

I doubt I’m the only one in possession of devices which are running old firmware. Even if they’re not in production, I’d bet there are a few devices in storage which have this problem, and if they’re ever pulled out of storage to replace a failed device, this will be a problem. Similarly, some older devices may not be receiving firmware updates any more and may never support newer ciphers, and finding a way to access them is important. It has only taken about two years for browser connectivity to go from no problem to inaccessible. I’d complain, but it’s all for the right reasons.

There’s another concern here though, which is that Charles Proxy works for me in this scenario because it still supports SSL ciphers which are considered to be insecure. I’m very pleased that it does, but it does raise the question of whether other commercial proxy solutions have mirrored the browsers in terms of disabling insecure ciphers. If not, there’s a danger that the proxy may be negotiating insecure ciphers and protocols on your behalf, even though the local side of the connection uses more secure ciphers because that’s all the browsers will support. This scenario could also occur on the server side of load balanced connections (for those VIPs which require re-encrypting to SSL on the server side), where some of the weaker/older ciphers may be preferred for an onward SSL connection because they have a lower impact on the encryption capacity of the device.

Meanwhile, I’ll get back to updating my old devices at home!

If you liked this post, please do click through to the source at How To Access Devices with Unsupported SSL Ciphers and give me a share/like. Thank you!

by John Herbert at November 14, 2017 03:23 PM

ipSpace.net Blog (Ivan Pepelnjak)

Another Reason to Run Linux on Your Data Center Switches

Arista’s OpenFlow implementation doesn’t support TLS encryption. Usually that’s not a big deal, as there aren’t that many customers using OpenFlow anyway, and those that do hopefully do it over a well-protected management network.

However, lack of OpenFlow TLS encryption might become an RFP showstopper… not because the customer would really need it but because the customer is in CYA mode (we don’t know what this feature is or why we’d use it, but it might be handy in a decade, so we must have it now) or because someone wants to eliminate certain vendors based on some obscure missing feature.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 14, 2017 07:58 AM

November 13, 2017

My Etherealmind

Turn Network Engineers into Software Engineers

Peyton Koran, Director of Technical Engagement at Electronic Arts, delivered a great session on why network vendors are losing to open source and whitebox. His view is that network engineers need to embrace software engineering, be flexible. Vendors and VARs are no longer working to benefit of the customer but to benefit themselves with increased […]

by Greg Ferro at November 13, 2017 05:07 PM

ipSpace.net Blog (Ivan Pepelnjak)

New Dates for the Building Network Automation Solutions Online Course

We’re slowly wrapping up the autumn 2017 Building Network Automation Solutions online course, so it’s time to schedule the next one. It will start on February 13th and you can already register (and save $700 over regular price as long as there are Enthusiast tickets left).

Do note that you get access to all course content (including the recordings of autumn 2017 sessions) the moment you register for the course. You can also start building your lab and working on hands-on exercises way before the course starts.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 13, 2017 08:04 AM

XKCD Comics

November 12, 2017

Potaroo blog

Thanks Google!

Thanks Google in demonstrating that you really care about getting IPv6 right. I appreciate it, and I’m sure many others do as well.

November 12, 2017 09:30 PM

November 11, 2017

ipSpace.net Blog (Ivan Pepelnjak)

Things that cannot go wrong

Found this Douglas Adams quote in The Signal and the Noise (a must-read book):

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair

I’ll leave to your imagination how this relates to stretched VLANs, ACI, NSX, VSAN, SD-WAN and a few other technologies.

by Ivan Pepelnjak (noreply@blogger.com) at November 11, 2017 07:38 AM

November 10, 2017

ipSpace.net Blog (Ivan Pepelnjak)

Separate Data from Code [Video]

After explaining the challenges of data center fabric deployments, Dinesh Dutt focused on a very important topic I cover in Week#3 of the Building Network Automation Solutions online course: how do you separate data (data model describing data center fabric) from code (Ansible playbooks and device configurations)

by Ivan Pepelnjak (noreply@blogger.com) at November 10, 2017 08:11 AM

The Networking Nerd

An Opinion On Offense Against NAT

It’s been a long time since I’ve gotten to rant against Network Address Translation (NAT). At first, I had hoped that was because IPv6 transitions were happening and people were adopting it rapidly enough that NAT would eventually slide into the past of SAN and DOS. Alas, it appears that IPv6 adoption is getting better but still not great.

Geoff Huston, on the other hand, seems to think that NAT is a good thing. In a recent article, he took up the shield to defend NAT against those that believe it is an abomination. He rightfully pointed out that NAT has extended the life of the modern Internet and also correctly pointed out that the slow pace of IPv6 deployment was due in part to the lack of urgency of address depletion. Even with companies like Microsoft buying large sections of IP address space to fuel Azure, we’re still not quite at the point of the game when IP addresses are hard to come by.

So, with Mr. Huston taking up the shield, let me find my +5 Sword of NAT Slaying and try to point out a couple of issues in his defense.

Relationship Status: NAT’s…Complicated

The first point that Mr. Huston brings up in his article is that the modern Internet doesn’t resemble the one build by DARPA in the 70s and 80s. That’s very true. As more devices are added to the infrastructure, the simple packet switching concept goes away. We need to add hierarchy to the system to handle the millions of devices we have now. And if we add a couple billion more we’re going to need even more structure.

Mr. Huston’s argument for NAT says that it creates a layer of abstraction that allows devices to be more mobile and not be tied to a specific address in one spot. That is especially important for things like mobile phones, which move between networks frequently. But instead of NAT providing a simple way to do this, NAT is increasing the complexity of the network by this abstraction.

When a device “roams” to a new network, whether it be cellular, wireless, wired, or otherwise, it is going to get a new address. If that address needs to be NATed for some reason, it’s going to create a new entry in a NAT state table somewhere. Any device behind a NAT that needs to talk to another device somewhere is going to create twice as many device entries as needed. Tracking those state tables is complicated. It takes memory and CPU power to do this. There is no ASIC that allows a device to do high-speed NATing. It has to be done by a general purpose CPU.

Adding to the complexity of NAT is the state that we’re in today when we overload addresses to get connectivity. It’s not just a matter of creating a singular one-to-one NAT. That type of translation isn’t what most people think of as NAT. Instead, they think of Port Address Translation (PAT), which allows hundreds or thousands of devices to share the same IP address. How many thousands? Well, as it turns out about 65,000 give or take. You can only PAT devices if you have free ports to PAT them on. And there are only 65,636 ports available. So you hit a hard limit there.

Mr. Huston talks in his article about extending the number of bits that can be used for NAT to increase the number of hosts that can be successfully NATed. That’s going to explode the tables of the NATing device and cause traffic to slow considerably if there are hundreds of thousands of IP translations going on. Mr. Huston argues that since the Internet is full of “middle boxes” anyway that are doing packet inspection and getting in the way of true end-to-end communications that we should utilize them and provide more space for NAT to occur instead of implementing IPv6 as an addressing space.

I’ll be the first to admit that chopping the IPv6 address space right in the middle to allow MAC addresses to auto-configure might not have been the best decision. But, in the 90s when we didn’t have DHCP it was a great idea in theory. And yes, assigning a /48 to a network does waste quite a bit of IP space. However, it does a great job of shrinking the size of the routing table, since that network can be summarized a lot better than having a bunch of /64 host routes floating around. This “waste” echoes the argument for and against using a /64 for a point-to-point link. If you’re worried about wasting several thousand addresses out of a potential billion then there might be other solutions you should look at instead.

Say My Name

One of the points that gets buried in the article that might shed some light on this defense of NAT is Mr. Huston’s championing for Named Data Networking. The concept of NDN is that everything on the Internet should stop being referred to as an address and instead should be tagged with a name. Then, when you want to look for a specific thing, you send a packet with that name and the Internet routes your packet to the thing you want. You then setup a communication between you and the data source. Sounds simple, right?

If you’re following along at home, this also sounds suspiciously like object storage. Instead of a piece of data living on a LUN or other SAN construct, we make every piece of data an object of a larger system and index them for easy retrieval. This idea works wonders for cloud providers, where object storage provides an overlay that hides the underlying infrastructure.

NDN is a great idea in theory. According to the Wikipedia article, address space is unbounded because you just keep coming up with new names for things. And since you’re using a name and not an address, you don’t have to NAT anything. That last point kind of blows up Mr. Huston’s defense of NAT in favor of NDN, right?

One question I have makes me go back to the object storage model and how it relates to NDN. In an object store, every piece of data has an Object ID, usually a UUID of 32 bits or 64 bits. We do this because, as it turns out, computers are horrible at finding names for things. We need to convert those names into numbers because computers still only understand zeros and ones at their most basic level. So, if we’re going to convert those names to some kind of numeric form anyway, why should we completely get rid of addresses? I mean, if we can find a huge address space that allows us to enumerate resources like an object store, we could duplicate a lot of NDN today, right? And, for the sake of argument, what if that huge address space was already based on hexadecimal?

Hello, Is It Me URLooking For?

To put this in a slightly different perspective, let’s look at the situation with phone numbers. In the US, we’ve had an explosion of mobile phones and other devices that have forced us to extend the number of area codes that we use to refer to groups of phone numbers. These area codes are usually geographically specific. We add more area codes to contain numbers that are being added. Sometimes these are specific to one city, like 212 is for New York. Other times they can cover a whole state or a portion of a state, like 580 does for Oklahoma.

It would be a whole lot easier for us to just refer to people by name instead of adding new numbers, right? I mean, we already do that in our mobile phones. We have a contact that has a phone number and an email address. If we want to contact John Smith, we look up the John Smith we want and choose our contact preference. We can call, email, or send a message through text or other communications method.

What address we use depends on our communication method. Calls use a phone number. If you’re on an iPhone like me, you can text via phone or AppleID (email address). You can also set up a video call the same way. Each of these methods of contact uses a different address for the name.

With Named Data Networking, are we going to have different addresses for each resource? If we’re doing away with addresses, how are we going to name things? Is there a name registry? Are we going to be allowed to name things whatever we want? Think about all the names of videos on Youtube if you want an idea of the nightmare that might be. And if you add some kind of rigid structure in the mix, you’re going to have to contain a database of names somewhere. As we’ve found with DNS, having a repository of information in a central place would make an awfully tempting target. Not to mention causing issues if it ever goes offline for some reason.


Tom’s Take

I don’t think there’s anything that could be said to defend NAT in my eyes. It’s the duct tape temporary solution that never seems to go away completely. Even with depletion and IPv6 adoption, NAT is still getting people riled up and ready to say that it’s the best option in a world of imperfect solutions. However, I think that IPv6 is the best way going forward. With more room to grow and the opportunity to create unique IDs for objects in your network. Even if we end up going down the road of Named Data Networking, I don’t think NAT is the solution you want to go with in the long run. Drive a sword through the heart of NAT and let it die.


by networkingnerd at November 10, 2017 03:57 AM

XKCD Comics

November 09, 2017

Networking Now (Juniper Blog)

GDPR and the Information Lifecycle

29280.png

 

 

 

 

 

I’m keen to change the perception that GDPR (General Data Protection Regulation) will act as a drag on organizations. I also want to avoid others falling into the trap of thinking the only inducement for an organization to comply is to avoid a fine. But before I attempt this, I’m going to briefly stray into another passion of mine; cars – just to make a point.

by lpitt at November 09, 2017 09:00 AM

ipSpace.net Blog (Ivan Pepelnjak)

Create a VLAN Map from Network Operational Data

It’s always great to see students enrolled in Building Network Automation Solutions online course using ideas from my sample playbooks to implement a wonderful solution that solves a real-life problem.

James McCutcheon did exactly that: he took my LLDP-to-Graph playbook and used it to graph VLANs stretching across multiple switches (and provided a good description of his solution).

by Ivan Pepelnjak (noreply@blogger.com) at November 09, 2017 07:45 AM

Networking Now (Juniper Blog)

A look into LokiBot infostealer

Introduction

We recently detected a Lokibot sample that was delivered as an email attachment to one of our customers in the healthcare vertical. Below is the technical analysis of the sample.

 

LokiBot is an infostealer that is known to steal various kinds of data like ftp credentials, email clients passwords, passwords stored in the browser, etc. Lokibot is distributed in phishing emails and known to exfiltrate data using the POST method over http.

 

Indicators of Compromise

  • iso file :
    • Md5: 17c9e6f0df7557962d6bc90a891693d9
    • Sha1: 2ee42a051823b4e1bc0ed643c0b15843cce7c056
  • filename: Proforma Invoice pdf.exe

<li-wrapper></li-wrapper>

    • Md5: 66837f4f5ee989a119eb7dcd8c5425b3
    • Sha1: 76a5919be86a7035fa6766d01a26094c49a30078
  • Unpacked:
    • Md5: 9335ce514bbdd9d146f30970569be44f
    • Sha1: 06aacbc54f93afcf29e3ee7966e236d7d9b98e60
  • .hdb file found in appdata
  • Connects to URLs that end with fre.php

Technical Analysis

The file is packed with a VB-compiled packer which usually makes the reversing tougher.

Additionally,  this sample uses anti-debug techniques and runpe which makes it harder to reverse engineer.

 

The obfuscated code decrypts to a virtually allocated memory by pushing to stack and then popping and xoring the data:

1.png

Fig: Obfuscated code in the file

 

The obfuscated code is copied to memory using a sequence of push and pop created in reverse order.The content can be decrypted with the xor key  0x5BD09268.

2.png

Fig: Decryption loop

 

Anti-debugging

The malware then jumps to the decrypted code. First it checks for anti-debug techniques. If a debugger present it jumps to a code which throws an exception.

3.png

Fig:Checks BeingDebugged falg in PEB

 

Sandbox detection code:

The above code detects a sandbox by saving the CurCursorPos then sleeping for a second and then comparing the cursor position to its previously known location. If it is the same, the malware throws an exception.

4.png

Fig: sandbox Detection

 

Other anti-debug checks

5.png

Fig: Checks for NtGlobalFlag in PEB for debugger detection

 

When satisfied it is not being monitored, the malware uses process hollowing to inject a payload into its own newly created suspended process.

 

Unpacked sample:

After unpacking, we can identify a lot of strings in the malware. The malware strings look similar to the strings observed in LokiBot.

 

The malware checks for the presence for various configs, settings files for ftp, browsers, email clients with hopes it can steal their credentials.

6.png

 Fig:Reads config files of of various softwares in loop

 

7.png

Fig:config files of various softwares

 

8.png

Fig:List of FTP files

 

9.png

Fig: malware reads config files of Secure FTP Expert

  

A .hdb is created in appdata folder which indicates the presence of lokiBot . This file seems to be some kind of database used by the malware. This can be used as IOC for LokiBot.

 

10.png

LokiBot is known to compress this data before sending it to the CnC server.

The malware uses an http POST method to send the stolen data to the CnC server.

11.png

Fig: LokiBot sends data to CnC server

 

CnC:

The sample connects to following URL and sends the stolen data:

http://newpanelme.info/042/fre[.]php

These C&C URLs usually end with fre.php

Here are a few more URLs used for the same purpose, discovered by other security vendors

  • southeasterncontractingco.com/AM/G00gle/fre[.]php     
  • axpired.xyz/013/fre[.]php  
  • 154.16.49.153/loved/know/fre[.]php
  • toopolex.com/controllers/user/fre[.]php  

Detection

Both Juniper Sky ATP and Cyphort(now a Juniper company) on-prem solutions detect this threat as seen in the screenshots below:

12.png

13.png

 cyphort.png

 

 

by amohanta at November 09, 2017 04:06 AM

Leverage the Entire Network for Lateral Threat Remediation

Today’s dynamic business environment requires organizations to defend themselves against increasingly sophisticated cybersecurity attacks powered by advanced threat intelligence and enforcement capabilities. That demands a comprehensive security platform that ties together and coordinates various threat analytics platforms, as well as a simpler policy mechanism.  Most important, you must be able to leverage the entire network—not just the perimeter—as a threat detection and enforcement tool.

by abdis at November 09, 2017 02:38 AM

November 08, 2017

My Etherealmind

WISP Design: Using eBGP and OSPF transit fabric for traffic engineering – YouTube

Kevin Myers talks at the Mikrotik conference about the use of BGP & OSPF in WISP design.

by Greg Ferro at November 08, 2017 05:41 PM

ipSpace.net Blog (Ivan Pepelnjak)

DMVPN or Firewall-Based VPNs?

One of my readers sent me this question:

I'm having an internal debate whether to use firewall-based VPNs or DMVPN to connect several sites if our MPLS connection goes down. How would you handle it? Do you have specific courses answering this question?

As always, the correct answer is it depends, in this case on:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 08, 2017 11:20 AM

Networking Now (Juniper Blog)

A look into LokiBot infoatealer

Introduction

We recently detected a Lokibot sample that was delivered as an email attachment to one of our customers in the healthcare vertical. Below is the technical analysis of the sample.

 

LokiBot is an infostealer that is known to steal various kinds of data like ftp credentials, email clients passwords, passwords stored in the browser, etc. Lokibot is distributed in phishing emails and known to exfiltrate data using the POST method over http.

 

Indicators of Compromise

  • iso file :
    • Md5: 17c9e6f0df7557962d6bc90a891693d9
    • Sha1: 2ee42a051823b4e1bc0ed643c0b15843cce7c056
  • filename: Proforma Invoice pdf.exe

<li-wrapper></li-wrapper>

    • Md5: 66837f4f5ee989a119eb7dcd8c5425b3
    • Sha1: 76a5919be86a7035fa6766d01a26094c49a30078
  • Unpacked:
    • Md5: 9335ce514bbdd9d146f30970569be44f
    • Sha1: 06aacbc54f93afcf29e3ee7966e236d7d9b98e60
  • .hdb file found in appdata
  • Connects to URLs that end with fre.php

Technical Analysis

The file is packed with a VB-compiled packer which usually makes the reversing tougher.

Additionally,  this sample uses anti-debug techniques and runpe which makes it harder to reverse engineer.

 

The obfuscated code decrypts to a virtually allocated memory by pushing to stack and then popping and xoring the data:

1.png

Fig: Obfuscated code in the file

 

The obfuscated code is copied to memory using a sequence of push and pop created in reverse order.The content can be decrypted with the xor key  0x5BD09268.

2.png

Fig: Decryption loop

 

Anti-debugging

The malware then jumps to the decrypted code. First it checks for anti-debug techniques. If a debugger present it jumps to a code which throws an exception.

3.png

Fig:Checks BeingDebugged falg in PEB

 

Sandbox detection code:

The above code detects a sandbox by saving the CurCursorPos then sleeping for a second and then comparing the cursor position to its previously known location. If it is the same, the malware throws an exception.

4.png

Fig: sandbox Detection

 

Other anti-debug checks

5.png

Fig: Checks for NtGlobalFlag in PEB for debugger detection

 

When satisfied it is not being monitored, the malware uses process hollowing to inject a payload into its own newly created suspended process.

 

Unpacked sample:

After unpacking, we can identify a lot of strings in the malware. The malware strings look similar to the strings observed in LokiBot.

 

The malware checks for the presence for various configs, settings files for ftp, browsers, email clients with hopes it can steal their credentials.

6.png

 Fig:Reads config files of of various softwares in loop

 

7.png

Fig:config files of various softwares

 

8.png

Fig:List of FTP files

 

9.png

Fig: malware reads config files of Secure FTP Expert

  

A .hdb is created in appdata folder which indicates the presence of lokiBot . This file seems to be some kind of database used by the malware. This can be used as IOC for LokiBot.

 

10.png

LokiBot is known to compress this data before sending it to the CnC server.

The malware uses an http POST method to send the stolen data to the CnC server.

11.png

Fig: LokiBot sends data to CnC server

 

CnC:

The sample connects to following URL and sends the stolen data:

http://newpanelme.info/042/fre[.]php

These C&C URLs usually end with fre.php

Here are a few more URLs used for the same purpose, discovered by other security vendors

  • southeasterncontractingco.com/AM/G00gle/fre[.]php     
  • axpired.xyz/013/fre[.]php  
  • 154.16.49.153/loved/know/fre[.]php
  • toopolex.com/controllers/user/fre[.]php  

Detection

Both Juniper Sky ATP and Cyphort on-prem solutions detect this threat as seen in the screenshots below:

12.png

13.png

 cyphort.png

 

 

by amohanta at November 08, 2017 02:29 AM

XKCD Comics

November 07, 2017

Dyn Research (Was Renesys Blog)

Widespread impact caused by Level 3 BGP route leak

For a little more than 90 minutes yesterday, internet service for millions of users in the U.S. and around the world slowed to a crawl.  Was this widespread service degradation caused by the latest botnet threat?  Not this time.  The cause was yet another BGP routing leak — a router misconfiguration directing internet traffic from its intended path to somewhere else.

<script async="async" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

While not a day goes by without a routing leak or misconfiguration of some sort on the internet, it is an entirely different matter when the error is committed by the largest telecommunications network in the world.

In this blog post, I’ll describe what happened in this routing leak and some of the impacts.  Unfortunately, there is no silver bullet to completely remove the possibility of these occurring in the future.  As long as we have humans configuring routers, mistakes will take place.

What happened?

At 17:47:05 UTC yesterday (6 November 2017), Level 3 (AS3356) began globally announcing thousands of BGP routes that had been learned from customers and peers and that were intended to stay internal to Level 3.  By doing so, internet traffic  to large eyeball networks like Comcast and Bell Canada, as well as major content providers like Netflix, was mistakenly sent through Level 3’s misconfigured routers.  Traffic engineering is a delicate process, so sending a large amount of traffic down an unexpected path is a recipe for service degradation.  Unfortunately, many of these leaked routes stayed in circulation until 19:24 UTC leading to over 90 minutes of problems on the internet.

Bell Canada (AS577)

<script async="async" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

Bell Canada (AS577) typically sends Level 3 a little more than 2,400 prefixes for circulation into Level 3’s customer cone.  During the routing leak yesterday, that number jumped up to 6,459 prefixes – most of which were more-specifics of existing routes and, equally as important, announced to Level 3’s Tier 1 peers like NTT (AS2914) and XO (AS2828, now a part of Verizon).

Below is a visualization of the latency impact of the routing leak.


Next is the propagation profile of just one of those Bell Canada routes leaked by Level 3.  50.100.32.0/22, for example, is not normally in the global routing table.  That address space is covered by 50.100.0.0/16, a less-specific route.  During the leak, this route (along with about 4,000 others) appeared in the global routing table as originated by AS577 and transited by AS3356.  About 40% of our BGP sources had these leaked routes in their routing tables and most chose NTT (AS2914) to reach AS3356 en route to AS577 (below right).


Comcast (various ASNs)

Comcast, the largest internet service provider in the United States, was also directly impacted by yesterday’s routing leak.

<script async="async" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

Comcast uses numerous ASNs to operate their network and Level 3 leaked prefixes from quite a few of them, diverting and slowing internet traffic bound for Comcast. According to our data, Level 3 leaked over 3000 prefixes from 18 of Comcast’s ASNs listed below.

  • AS33491 (356 leaked prefixes)
  • AS7725 (252 leaked prefixes)
  • AS7015 (248 leaked prefixes)
  • AS33287 (241 leaked prefixes)
  • AS33651 (235 leaked prefixes)
  • AS22909 (198 leaked prefixes)
  • AS33657 (178 leaked prefixes)
  • AS33668 (176 leaked prefixes)
  • AS20214 (176 leaked prefixes)
  • AS7016 (161 leaked prefixes)
  • AS33650 (152 leaked prefixes)
  • AS33667 (145 leaked prefixes)
  • AS33652 (142 leaked prefixes)
  • AS33490 (117 leaked prefixes)
  • AS13367 (117 leaked prefixes)
  • AS33660 (101 leaked prefixes)
  • AS33659 (97 leaked prefixes)
  • AS33662 (89 leaked prefixes)

Our traceroute measurements into Comcast reveal the impact of the leak from a performance standpoint.  The two visualizations below show a bulge of internet traffic headed for the leaked IP address space diverted through Level 3, and the increase in observed latency.


Other Impacts

Level 3 leaked 81 prefixes from RCN who appeared to pull the plug on their Level 3 connection at 18:34 UTC, once they figured out what was causing a slowdown in their network.


Level 3 leaked 97 prefixes from Netflix (AS2906) including the following:


Impacts were not limited to the United States. Networks in Brazil, Argentina and the UAE also had routes leaked by Level 3 yesterday.  Below are example routes leaked from Giga Provedor de Internet Ltda (AS52610, 42 leaked prefixes), Cablevision S.A. (AS10481, 365 leaked prefixes), and even the Weill Cornell Medical College in Qatar (AS32539, 3 leaked prefixes):


Conclusion

It is important to keep in mind that the internet is still a best-effort endeavor, held together by a community of technicians in constant coordination.  In this particular case, initial clues as to the to origin of this incident were first reported in a technical forum (the outages list) when Job Snijders astutely observed new prefixes being routed between Comcast and Level 3 yesterday.

Peer leaks are a continuing risk to the internet without any silver bullet solution.  We previously suggested to use protection when peering promiscuously, but even a well-run network like Google has been both the leaker and the leaked.

Networks share more-specific routes to a peer in order to ensure that return traffic comes directly back over the peering link. But there is always the risk that the peer could leak those routes and adversely affect your network.  When the leaker is the biggest telecom in the world (and only getting bigger), the impact is likely to be significant.

by Doug Madory at November 07, 2017 08:34 PM

Networking Now (Juniper Blog)

Data - Valuable Asset or Business Risk?

 

Commerce is built on the concept of the value chain. The notion that you can take something of relatively little worth and, through various processes, increase its value is fundamental to a sustainable global economy. And, in the early part of the 21st century, it is “data” that gives rise to perhaps the most significant contemporary value chain of all.

by lpitt at November 07, 2017 04:50 PM

ipSpace.net Blog (Ivan Pepelnjak)

Update: Cisco Nexus Switches

Third vendor in this year’s series of data center switching updates: Cisco.

As expected, Cisco launched a number of new switches in 2017, and EOL’d older models … for pretty varying value of old. For example, most of the original Nexus 9300 models are gone.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 07, 2017 08:44 AM

November 06, 2017

ipSpace.net Blog (Ivan Pepelnjak)

[Video] Building a Pure Layer-3 Data Center with Cumulus Linux

One of the design scenarios we covered in Leaf-and-Spine Fabric Architectures webinar is a pure layer-3 data center, and in the “how do I do this” part of that section Dinesh Dutt talked about the details you need to know to get this idea implemented on Cumulus Linux.

We covered a half-dozen design scenarios in that webinar; for an even wider picture check out the new Designing and Building Data Center Fabrics online course.

by Ivan Pepelnjak (noreply@blogger.com) at November 06, 2017 10:08 AM

[Video] Data Center Fabric Validation

Validating the expected network behavior is (according to the intent-driven pundits) a fundamental difference that makes intent-driven products more than glorified orchestration systems.

Guess what: smart people knew that for ages and validated their deployments even when using simple tools like Ansible playbooks.

Dinesh Dutt explained how he validates data center fabric deployment during the Network Automation Use Cases webinar; I’m doing something similar in my OSPF deployment playbooks (described in detail in Ansible online course).

by Ivan Pepelnjak (noreply@blogger.com) at November 06, 2017 10:08 AM

The Three Paths of Enterprise IT

Everyone knows that Service Providers and Enterprise networks diverged decades ago. More precisely, organizations that offer network connectivity as their core business usually (but not always) behave differently from organizations that use networking to support their core business.

Obviously, there are grey areas: from people claiming to be service providers who can’t get their act together, to departments (or whole organizations) who run enterprise networks that look a lot like traditional service provider networks because they’re effectively an internal service provider.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 06, 2017 08:35 AM

XKCD Comics

November 04, 2017

My CCIE Training Guide

Risk Management - Quantitative risk assessment

The name kind of give away the type of assessment we talk about "Quantitative" according to google translate:

relating to, measuring, or measured by the quantity of something rather than its quality.

Well although it is most likely not always going to be the case were you can place a $ value to a risk, with Quantitative  risk assessment that is the goal, and it can be achieved for assets are tangible (server, safe, storage...) or intangible ( patent, software...)

Step 1

Determine the Asset you wish to protect and from what is the threat is risking the asset.

Step 2

AV - determine the asset value in $ value

EF - assess the Exposure factor or how bad would the asset be impacted in case threat exploit happened and the value is in %

SLE = AV * EF , that is single loss expectancy or in other words the $ value of single incident

ARO - Annual rate of Occurrence basically it is a counter of how many times we expect that incident to happen in 1 year, and it can be a whole number or a fraction for example if we know that a major earthquake in our are can happen 1 every 100 years then the ARO would be 1/100 = 0.01

ALE = SLE * ARO , Annual loss expectancy is taking the single loss $ value times the annual rate and we are getting the $ value of our risk per year.

Now that is not the whole deal as once we have the $ value of our risk we want to see if we can reduce it or alternatively we need to accept it if the reduction cost is for example more expensive.

Step 3

So the next step is to identify the risk mitigation / reduction tools (safe guards) and once we understand them we need to go back and recalculate ALE after implementing our safe guards.

ALE1 ( before implementing safe guards)
ALE2 ( After implementing safe guards) or Residual Risk
SafeGuards - FW, IPS/IDS, Fence, fire system

ALE1 - ALE2 - SafeGuards = Risk Mitigation Value

Risk Value with negative value would be tricky as there is no clear return on investment for placing counter measures. so your other options are:

Accept the risk by executive decision that must be documented.
Sharing the risk for example by buying an insurance policy.
Avoid the risk not always you can but if possible, avoiding an act or usage may eliminate the risk



Note: ignore the risk is never a valid option!

by shiran guez (noreply@blogger.com) at November 04, 2017 08:41 PM

ipSpace.net Blog (Ivan Pepelnjak)

Lab Requirements for Ansible for Networking Engineers Online Course

One of the undergraduate students attending my Ansible for Networking Engineers online course got to the point where he wanted to start hands-on work and sent me a list of questions:

Do I have to buy a VIRL license to use your Ansible course materials? Or is VIRL in any Github repository? Is there a way to use your files in a free Tool like GNS3?

Let’s go through them one by one:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at November 04, 2017 09:28 AM

November 03, 2017

Moving Packets

Hive Mind, Help Me Out with A10 AXAPI?

Dear Internet,

I am writing some automation code in Go to create client-ssl templates on an A10 load balancer running AXAPI version 2. It’s going as swimmingly as it can with the v2 API, but one area of non-complete API coverage has led to another issue and I’m wondering if anybody has seen the same thing.

A10 Networks Logo

Background – Disabling SSLv3

SSL access to VIPs on the A10 load balancer is controlled by means of client-ssl templates which define which certificates should be presented and the ciphers and protocols supported for the incoming connection. In this case therefore, disabling SSLv3 is accomplished in the client-ssl template (unfortunately there is no global switch to turn SSLv3 off by default). A typical template might look like this in the configuration:

slb template client-ssl mytemplate
   cert my_certificate
   key my_private_key
   chain-cert some_chain_cert
   disable-sslv3
!

As it turns out, all aspects of the client-ssl template are exposed via the API except for “disable-sslv3” which shows neither as a returned property of the template (highly annoying), nor as a property which can be set when creating a template (also annoying). Thus to replicate a template like the one above, I choose to set everything I can using the JSON client-ssl template object, then – and this is the bit that grinds my grits – I have to make a second API call to the CLI in order to then issue commands thus:

slb template client-ssl mytemplate
   disable-sslv3

If you’re thinking this sounds lame, then you’ve just understood why at Tech Field Day events, a common question asked of vendors is “does your API have 100% configuration coverage?”

Communicating With AXAPI

In order to use the A10’s API, it’s necessary first to authenticate to the device. In return, the A10 provides a session_id token which has to then be provided in the URI of every subsequent request during that session. Consequently every API call looks similar to this:

https://a10.fqdn/services/rest/V2.1/?session_id=[SESSION_ID]&format=json&method=slb.client_ssl.search

This works well and is pretty fast. To enter configuration lines the same paradigm is used, consisting of an HTTP POST to:

https://a10.fqdn/services/rest/V2.1/?session_id=[SESSION_ID]&format=json&method=cli.deploy

The body of the POST is simply the commands to be entered, as if they were to be cut and paste in configuration mode. Most of the time this works ok, but I have noticed when testing against my vThunder (a virtualized A10 load balancer) I get this error back:

Invalid username/password

Obviously, the username and password are just fine, because I authenticated before any of this began, and the local account I’m logging into (for testing purposes only; production devices use RADIUS of course) has CLI rights as well as API rights. In fact it must be correct because most of the time it works and SSLv3 is disabled. But sometimes, more frequently than I’d like, the command fails with this error.

It’s possible to override the session_id and provide a username and password for the cli.deploy method in the URI as well; I’ve tried this and it’s no better.

Has anybody else seen this and found a solution? I’ll do some testing using a RADIUS admin account shortly in case the type of login makes a difference, and failing that I guess I’ll raise a support case with A10 as this smells awfully like a bug. I was just rather hoping there was a workaround meanwhile!

Long term the solution is to move to the v3 API which promises 100% command coverage, which is something I’m working on in parallel. For the moment, though this is generating instability in a process I’d really like to be solid, and it seemed rude of me not to share my frustration with you on a Friday afternoon. Enjoy your weekend!

 

 

 

If you liked this post, please do click through to the source at Hive Mind, Help Me Out with A10 AXAPI? and give me a share/like. Thank you!

by John Herbert at November 03, 2017 09:32 PM

The Networking Nerd

VMware and VeloCloud: A Hedge Against Hyperconvergence?

VMware announced on Thursday that they are buying VeloCloud. This was a big move in the market that immediately set off a huge discussion about the implications. I had originally thought AT&T would buy VeloCloud based on their relationship in the past, but the acquistion of Vyatta from Brocade over the summer should have been a hint that wasn’t going to happen. Instead, VMware swooped in and picked up the company for an undisclosed amount.

The conversations have been going wild so far. Everyone wants to know how this is going to affect the relationship with Cisco, especially given that Cisco put money into VeloCloud in both 2016 and 2017. Given the acquisition of Viptela by Cisco earlier this year it’s easy to see that these two companies might find themselves competing for marketshare in the SD-WAN space. However, I think that this is actually a different play from VMware. One that’s striking back at hyperconverged vendors.

Adding The Value

If you look at the marketing coming out of hyperconvergence vendors right now, you’ll see there’s a lot of discussion around platform. Fast storage, small footprints, and the ability to deploy anywhere. Hyperconverged solutions are also starting to focus on the hot new trends in compute, like containers. Along the way this means that traditional workloads that run on VMware ESX hypervisors aren’t getting the spotlight they once did.

In fact, the leading hyperconvergence vendor Nutanix has been aggressively selling their own hypervisor, Acropolis as a competitor to VMware. They tout new features and easy configuration as the major reason to use Acropolis over ESX. The push by Nutanix is to get their customers off of ESX and on to Acropolis to get a share of the VMware budget that companies are currently paying.

For VMware, it’s a tough sell to keep their customers on ESX. There’s a very big ecosystem of software out there that runs on ESX, but if you can replicate a large portion of it natively like Acropolis and other hypervisors do there’s not much of a reason to stick with ESX. And if the VMware solution is more expensive over time you will find yourself choosing the cheaper alternative when the negotiations come up for renewal.

For VMware NSX, it’s an even harder road. Most of the organizations that I’ve seen deploying hyperconverged solutions are not huge enterprises with massive centralized data centers. Instead, they are the kind small-to-medium businesses that need some functions but are very budget conscious. They’re also very geographically diverse, with smaller branch offices taking the place of a few massive headquarters locations. While NSX has some advantages for these companies, it’s not the best fit for them. NSX works optimally in a data center with high-speed links and a well-built underlay network.

vWAN with VeloCloud

So how is VeloCloud going to play into this? VeloCloud already has a lot of advantages that made them a great complement to VMware’s model. They have built-in multi tenancy. Their service delivery is virtualized. They were already looking to move toward service providers as their primary market, but network services and managed service providers. This sounds like their interests are aligning quite well with VMware already.

The key advantage for VMware with VeloCloud is how it will allow NSX to extend into the branch. Remember how I said that NSX loves an environment with a stable underlay? That’s what VeloCloud can deliver. A stable, encrypted VPN underlay. An underlay that can be managed from one central location, or in the future, perhaps even a vCenter plugin. That gives VeloCloud a huge advantage to build the underlay to get connectivity between branches.

Now, with an underlay built out, NSX can be pushed down into the branch. Branches can now use all the great features of NSX like analytics, some of which will be bolstered by VeloCloud, as well as microsegmentation and other heretofore unseen features in the branch. The large headquarters data center is now available in a smaller remote size for branches. That’s a huge advantage for organizations that need those features in places that don’t have data centers.

And the pitch against using other hypervisors with your hyperconverged solution? NSX works best with ESX. Now, you can argue that there is real value in keeping ESX on your remote branches is not costs or features that you may one day hope to use if your WAN connection gets upgraded to ludicrous speed. Instead, VeloCloud can be deployed between your HQ or main office and your remote site to bring those NSX functions down into your environment over a secure tunnel.

While this does compete a bit with Cisco from a delivery standpoint, it still doesn’t affect them with complete overlap. In this scenario, VeloCloud is a service delivery platform for NSX and not a piece of hardware at the edge. Absent VeloCloud, this kind of setup could still be replicated with a Cisco Viptela box running the underlay and NSX riding on top in the overlay. But I think that the market that VMware is going after is going to be building this from the ground up with VMware solutions from the start.


Tom’s Take

Not every issues is “Us vs. Them”. I get that VMware and Cisco seem to be spending more time moving closer together on the networking side of things. SD-WAN is a technology that was inevitably going to bring Cisco into conflict with someone. The third generation of SD-WAN vendors are really companies that didn’t have a proper offering buying up all the first generation startups. Viptela and VeloCloud are now off the market and they’ll soon be integral parts of their respective parent’s strategies going forward. Whether VeloCloud is focused on enabling cloud connectivity for VMware or retaking the branch from the hyperconverged vendors is going to play out in the next few months. But instead of focusing on conflict with anyone else, VeloCloud should be judged by the value it brings to VMware in the near term.


by networkingnerd at November 03, 2017 01:15 AM

XKCD Comics

November 02, 2017

Honest Networker