So What’s ”indeni”

Not a week goes by without someone asking me – “So, what’s indeni?”.

Those who know me well, know that when I notice something repeating itself, I try to find a permanent solution for it. So what’s a better solution than writing a post about it?

When we first started off working on what today is indeni, we didn’t have a name. We just had an idea and some initial code. We started talking to prospective users and at a certain point, one of them asked us, “So, what’s your company called?”

That’s the first time we realized, we actually don’t have a name.

Strange, but I guess that’s what happens when you try to run as fast as possible. Naturally, something had to be done about it.

There are different ways to pick a name. We decided to make it simple.

We looked at names of other companies, like Cisco, Juniper and SolarWinds, and realized the name itself means very little to the companies’ customers and partners. They may mean something to the founders, but that’s about it. This opened up a whole world of possibilities as there was no need to have a name that actually meant anything significant.

Me being me, I sat down and wrote a script to automate this process. The script took 10,000 words in English and put them through a known translation web service (without violating the terms of use, of course). It tried to translate the words to all languages that use Latin characters and checked the availability of the “.com” domain of the resulting word.

The script ended up checking the “.com” availability of roughly 150,000 words. Those words that had the “.com” available were saved to an Excel file together with their English meaning. It took less than three hours to code and run.

One of the words that came up was indeni:

in-de-ni -adverb ~ Danish.

:inside, indenfor, indeni, ind

That worked for us.

And so, indeni was born.

Blue Coat Setting up VAPs Crossbeam

Recently I’ve invested some time integrating indeni with our newly supported Blue Coat’s X-series chassis (previously known as Crossbeam). So here are a few tips on setting up VAPs on Crossbeam. Blue Coat X-Series Chassis is designed to run applications from third-party security software vendors (for example, Check Point) on VAPs (Virtual Application Processes). A Blue Coat Chassis supports up to 14 VAPs and is divided into three types of hardware blades or modules:

  • Network Processor Module (NPM)
  • Control Processor Module (CPM)
  • Application Processor Module (APM)

The setup of the security models is managed by the CPM. The CPM CLI allows defining and running the security modules on the APMs through VAP (Virtual Application Processing) groups. These are essentially Security Software virtual modules that can be allocated to run on APMs dynamically.

 

Initial Setup to Create VAP Groups on Blue Coat

 

To create a VAP group in XOS using the CLI, run the following commands in sequence:

Configure vap-group <vap group name> <xslinux_v3/v5/v5_64/xsve>

 

There are 4 different Linux versions, make sure the Linux version is supported by the APM:

VersionSupported APMs
xslinux_v3APM-8600/8650
xslinux_v5APM-8600/8650, APM-9600
xslinux_v5_64 *APM-8600/8650, APM-9600
xsve **APM-9600

* The determination between xslinux_v5 and xslinux_v5_64 is based on the target application’s requirements and XOS will prompt you for the correct version when you install the application on the VAP Group.

** Platform that allows non-Linux based applications to run on APMs.

 

vap-count <count>

vap-count is the number of VAPs (APMs) in this group. For example, in Check Point (standalone) security gateway this would be set to 1; for a cluster it would be set to 2.

 

max-load-count <number of APMs to dynamically allocate to>

The maximum number of VAP members in the VAP group cannot exceed the vap-count.

 

ap-list <list of potential APMs ap1..ap14>

Assign APMs to support the VAP group. This command specifies the list of APMs to be loaded.

 

load-balance-vap-list <indexes 1..14>

This is a list of VAP indexes that the NPM uses to load balance new flows. By default, the NPM load balances over all the VAPs in the VAP group.

 

ip-flow-rule <flow rule name>

Create the load balancing flow rule for the VAP group.

 

action load-balance

Set flow rule action to load-balance traffic to all available VAP members.

 

activate

Set the activate flag to enable the action.

 

exit

 

Example for Initial Setup:

 

vap-group r7540cxl xslinux_v5_64 vap-count 2 max-load-count 2 ap-list ap1 ap2 ap3 ap4 ap5 ap6 ap7 ap8 ap9 ap10 load-balance-vap-list 1 2 3 4 5 6 7 8 9 10 ip-flow-rule r7540cxl_lb action load-balance activate

 

When you’ve finished configuring the VAPs, it is recommended that you save the config by running the following command:

copy running-config startup-config

 

To view the allocation of VAPs on the APMs, run the following command, which displays VAP group to APMs mapping. It will give you a quick indication of which VAP groups are running on which APMs:

show ap-vap-mapping

 

As part of indeni’s monitoring of Blue Coat’s XOS, we:

  • Compare the VAPs as defined under the vap-group section of the configuration with the output of show ap-vap-mapping. If indeni finds VAPs that are defined but not running, we alert you.
  • Run show application vap-group periodically for all the VAPs that are set up. If indeni finds VAPs that have a status different than ‘Up’, we alert you.

BGP Routing Protocol

So what is BGP? In this series of posts I will be explaining the main principles of BGP. BGP–Border Gateway Protocol–is the de facto core routing protocol of the Internet. It operates by exchanging routes among Internet Autonomous Systems, and it is considered a path vector protocol. Routing is performed by shortest path possible and according to network policies within each Autonomous System. Most large service providers use BGP, and enterprises can operate BGP internally to influence metrics.

 

BGP operates in Layer 4 of the OSI network model and establishes TCP connections via port 179 between neighbors. BGP that is used internally is designated as iBGP and when used externally it is designated as eBGP. The implementation of routing policies are done mainly by route maps. For example, influencing traffic with BGP policies can be done with the MED (Multi-Exit Discriminator) attribute, which tells a remote AS that a specific entry into an AS is the preferred one. Therefore, BGP is great for multi-homing to different ISPs (in terms of load balancing and backup).

 

ISPs that run BGP also integrate Multiprotocol BGP (MP-BGP). It is a special extension of BGP that works with MPLS, which allows service providers to offer businesses VPN capabilities and secure connectivity across multiple branches.

This technology is very widespread in large-scale enterprises. Proactive monitoring and fault resolution of BGP is essential due to its importance and influence on the topology.

Smart BGP signatures are already embedded into indeni and many others are planned.

Here are several examples for checks indeni has around BGP configuration:

Network Summarizations Made Easy

Network summarization is rather simple to setup, yet may be potent if not done properly. I wanted to share some of my insight with you regarding this topic. We all know that some of the most popular dynamic routing protocols would summarize network automatically for you if you configured them to, for example, EIGRP and RIP allow for automatic summarization while OSPF does not. With that said, most network admins would avoid setting up automatic summarization as this is very error prone and usually results in network summarizations being too loose. I recently added a signature to indeni’s Dynamic Knowledge platform that helps users out with network summarization. In this signature, we take all the summarized routes and look at them to make sure that they are as summarized as possible. If they are not, we propose a more summarized option for the user.

The way we actually do it is quite simple, we use “show ip routes” to get all the routes including those summarized. We then select all the summarized routes and check whether they are loose and could be “tightened up”.

Here is what it looks like on indeni:

Alert Description:

Network summarizations might be too loose. Some of the network summaries can be tightened and still contain all the currently summarized networks. The following loose networks have been found: 10.10.0.0/16 192.0.0.0/8

 

Manual Remediation steps:

The suggested networks summarizations can be manually configured using the command: “ip summary-address PROTOCOL x.x.x.x x.x.x.x” Auto summarization can be turned off by manually issuing the command “no auto-summary” under the relevant protocol configuration.

 

For those of you who choose to do it manually, here is how you summarize routes:

Say you want to summarize these networks: 192.168.4.0/24 192.168.5.0/23 192.168.6.0/24

First thing you have to do is convert the networks into their binary octets (here is a simple conversion table) 192.168.4.0 / 24 turns into 11000000.10101000.00000100.00000000 / 24 192.168.5.0 / 23 turns into 11000000.10101000.00000101.00000000 / 23 192.168.6.0 / 22 turns into 11000000.10101000.00000110.00000000 / 22 A / 24 mask is translated to 24 one bits followed by 32-24=8 trailing zeros: 11111111.11111111.11111111.00000000 To apply the mask you have to do a bitwise AND between the network and its mask.

 

1100 0000 .1010 1000 .0000 0100 .0000 0000 &

1111 1111 .1111 1111 .1111 1111 .0000 0000

1100 0000 .1010 1000 .0000 0100 .0000 0000

1100 0000 .1010 1000 .0000 0101 .0000 0000 &

1111  1111 .1111  1111  .1111 1110  .0000 0000

1100 0000 .1010 1000 .0000 0100 .0000 0000

1100 0000.1010 1000 .0000 0110.0000 0000 &

1111 1111 .1111 1111 .1111 1111 .0000 0000

1100 0000.1010 1000. 0000 0110.0000 0000

Notice that the first two networks are the same.

Now, let’s look at our networks and summarize them, summarizing the networks is all about finding a common prefix.

11000000.00000000.00000000.00000000 is a common prefix for both our networks, but so is 11000000.10101000.00000000.00000000 so how do you choose?

Each of the proposed summarizations contain networks that we didn’t want to include in our summary and the rule of thumb in our case says: “The tighter the summary is, the less unwanted networks are included in it”.

The tightest summary is the longest common prefix between all summarized networks, and in our case it’s: 11000000.10101000.00000100.00000000

Which translates back (use the table) to the original network of: 192.168.4.0