Skip navigation

The next release of IPAM is coming very soon. One of the behaviors we have modified is how we handle duplicate subnets. Many customers, mainly Managed Service Providers, need to manage address space for customers who may have overlapping subnets. For these customers, duplicate subnets are a must have. Unfortunately, for other customers who are managing their internal space and don’t want duplicate subnets, the current behavior of IPAM can cause issues.

In IPAM 2.0, we change all of that. Now, if you don’t want duplicate subnets, simply click on Settings –> IPAM Settings –> System Settings and make sure “Enable Duplicated Subnets” is not checked. New installs of IPAM will have duplicate subnets disabled by default, upgrades will retain the current setting (duplicate subnets allowed).

 

Settings

 

Duplicate Subnets

 

Now, I realize those are probably the most boring screenshots you’ve ever seen in a Product Blog post. The excitement is what happens behind the scenes. When the box is not checked (Duplicate subnets are not allowed), we will not allow you to create a subnet that is a duplicate or overlaps an existing subnet. Also, if you are monitoring multiple DHCP server scopes, IPAM will merge the status from those scopes into one subnet (rather than having different subnets in IPAM for each server’s scope). This example is often seen when you have multiple DHCP servers providing split scope assignments for the same subnet. See this documentation from Microsoft Technet on Optimizing DHCP Availability: http://technet.microsoft.com/en-us/library/cc757346(WS.10).aspx.

The next question is; I currently have duplicate subnets, how do I merge those duplicate subnets so I can take advantage of this new functionality? The easiest way to clean this up for scopes being monitored by DHCP is to simply delete one of the DHCP servers. When you add it and its scopes back, IPAM will merge this data into the remaining subnet. Be careful though, if you have custom fields or notes on any of these addresses, you will lose them if the subnets are deleted. As always, backup your database before making large changes like this.

If you have active maintenance, the IPAM 2.0 RC should be in your customer portal. If you don’t have IPAM yet, simply go here and download a free evaluation: http://www.solarwinds.com/products/orion/ip_address_manager/

Please refer to this blog posting:

Announcement of end of support for Internet Explorer (IE) 6 in next Orion NPM version

The same applies to the next release of NCM, also scheduled for later this year.

---------------------------

Francois Caron - Sr. Product Manager - NPM NCM IPSLAM

The internet browser market has been very busy in the last year in terms of new versions and adoption of new browser platforms. 

 
      
  • Internet Explorer 9 is currently in Release Candidate
  •    
  • Firefox 4.0 is currently in Beta
 

You can view usage statistics for last month, but also over time here - http://en.wikipedia.org/wiki/Comparison_of_web_browsers

 

With each release we evaluate usage statistics available on the web, but also looking at data from thwack.com and solarwinds.com.

 

As we are in planning stage for the next NPM release, when we release this version (meaning later this year), we will be formally dropping support for Internet Explorer 6.

During this webcast we'll demonstrate best practices for network configuration management - managing the configurations of routers, switches, firewalls and other network infrastructure devices. We'll also demonstrate the top 5 network configuration management tasks using the SolarWinds Network Configuration Manager (NCM).  

 

Some of what we'll discuss and demo:

 
      
  • Backing up the configurations of all of your routers, switches, and firewalls
  •    
  • Setting up automated configuration management jobs
  •    
  • Configuring and using real-time config change detection
  •    
  • Managing configurations against policies for compliance
 

View it now:  http://www.solarwinds.com/resources/webcasts/network-configuration-management-best-practices.html

One of my colleagues wrote a blog User Feedback for New Products a few weeks back addressing some new products we’re working on, one of which is a product that will allow you to monitor synthetic transactions.  I’d like to provide a little more detail on this product and why we decided to build it.

With IP SLA Manager you can set up a test to determine if a web server is actually reachable, but it won’t tell you if the website is up or displaying the correct page. Once you reach the webiste, APM has a couple of very useful monitors that will allow you to simulate a form login on a web page and determine if that login was successful, or monitor if a web page is up and search for a specific string as part of that validation.  Although these monitors are great for letting you know if a web page is up or if users can log into it, they don’t really give you any visibility past the first page or login screen.

Many of our customers have requested the ability to monitor more complex transactions within a website or web application.  These customers want to monitor things like:

  • How long does it take for a user to complete a registration?
  • How long does it take for a user to retrieve a trouble ticket and view its status?
  • How long does it take customers to purchase an item, add it to the shopping cart, then check out and complete their purchase?

Given requirements like these, we are currently working on a product that will allow our customers to monitor multi-step transactions with a website.  The product will allow users to record a series of steps that a typical user would take in interacting with a website or web application, then play that recording back at regular intervals which can be monitored.  This type of monitoring will give users the ability to proactively address any issues that an end user may experience when clicking through or performing certain actions on a website or in a web-based application.

Here is a sneak peek of what we’re working on.  Please note this is a mock-up; which resources are displayed and what they’re called may change, but this should give you a general idea of the functionality we’re going after.

Playback Details Mockup.

Why am I telling you about this now if it’s not ready yet?  First, in true Solarwinds fashion we want to be transparent and let you know what we’re working on.  Second, and more selfishly, I could use your help!  I’m looking for early alpha and beta testers to try it out and let us know what you think.  If you think a product like this would be useful and you’re interested in getting an early look, please shoot me an email at craig.mcdonald@solarwinds.com and we can schedule a web meeting.

Before we jump into the blog, let me introduce myself.  My name is Francois Caron and I am a new Product Manager here at SolarWinds and will be responsible for Orion NPM, NCM and IPSLA Manager going forward.  I come from a network management background in my previous life, however, one of the first things I did when I got here was to immerse myself in NPM and thwack.  Watching and learning from the posts between everyone in the community.

 

One of the new features in NPM 10.1 which has gotten a lot of questions and discussion has been Dependencies and Grouping and how do I apply these in Orion to my network.

 

With this blog, I am trying to recap the different use cases that I have seen in these discussions, i.e. what “objects” (left column) we are trying to manage and discuss some management “functions” (top row) that NPM users are trying to apply to them.

 

Each cell of the matrix presents a summary of how to approach the implementation of this function to this object, and provide pointers to more detailed information related to this use case (as opposed to re-explain what is already well explained either on Thwack or NPM’s documentation).

 

Feel free to comment and tell me about other use cases (different “objects” or “functions”), this could be a good basis for improving this blog moving forward. Also tell me about your successes (or failures!) with NPM in this area, we will use those as a basis for enhancement requests.

 

 

                                                                       
        

Physical Topology

      
        

Alert suppression*

      
        

Status propagation

      
        

Remote site reachable via an access router (single point of failure)

         

clip_image002[13]

         

Example of posting related to this case Nested Dependency Clarification.

         

 

         

 

         

 

         

 

      
        

Objective:

         
  •           
    No alert is fired on site’s devices if the access router goes down.
               

    Steps:

               
                  
    •               

      Put the remote site devices in a group.

                  
    •              
    •               

      Create a dependency between the access router and the group.

                  
    •           
               

    More:

               
                  
    • Some of you may think about the case of a topology where the access is actually a pair of redundant routers (vs a single point of failure). In this case, create a dependency between the remote site group and another group made up of the pair of redundant access routers. This is also discussed The specified item was not found..
    •              
    • Remember dependencies are 1:1 relationship only. If you need a 1 to N, then you need to create a group containing the N. This is discussed Re: Dependencies not behaving as expected.
    •              
    • More on dependencies in general Meet the Features – Orion NPM 10.1 - Dependencies 2.0 / Basic Root Cause Analysis.
    •              
    •               

      For this feature, the status “down” relates to lack of response to pings from the NPM poller.

                  
    •           
            
  •       
            

    I do not think there is a use case for propagating a status related to the access router, calculated from the status of the remote site’s devices. The access router usually has its own status.

             

    If you feel differently and have a good use case, feel free to comment.

             

     

             

     

             

     

             

     

             

     

             

     

             

     

          
     

     

                                                                           
            

    Port-Channel

          
            

    Alert suppression*

          
            

    Status propagation

          
            

    Logical link made-up of multiple identical interfaces (throughput aggregation and fault tolerance).

             

    clip_image001[14]

             

    Example of posting related to this case Re: What is the most efficient way to monitor etherchannels on NPM ?.

          
            

    I cannot see a good use case for suppressing alerts in this use case. Unless the logical Port-Channel had a state of its own sent by the device, which would make the alerts on each physical interface point less.

             

    For example, turning the Port-Channel down (admin status down) would make the interfaces down as well and the network admin wanted to suppress those alarms, considered noise.

             

    Open to your input and comments, of what you think happens in the context of your network and network devices/vendors.

          
            

    Objective:

             
                
    • Monitor the status of the Port-Channel object, based on the status of physical interfaces.
    •            
    • Port-Channel in warning state if 50% or less of the interfaces are down. Critical if more
    •         
             

    Steps:

             
                
    • Model the Port-Channel as a group that contains its 2 physical interfaces.
    •            
    • The group can be created manually or by a dynamic query if both physical interfaces have a property that has a common value.
    •            
    • Dependencies are not required for this use case.
    •         
             

    More:

                    
     

     

                                                                           
            

    Business services

          
            

    Alert suppression*

          
            

    Status propagation

          
            

    A banking service is made-up of 3 applications, each connected to a database, all running in a data center accessed via a router.

             

    clip_image001[20]

             

    This case is different from the previous cases because it involves objects that are not only network objects and it combines the need for both functions.

          
            

    Objective:

             
                
    • No alert is fired on each of the 3 applications if the database is down.
    •            
    • Applications being down is basically noise, the administrator should focus on taking the database back up.
    •         
             

    Steps:

             
                
    • Put your 3 APM applications in a group.
    •            
    • Create a dependency between the database (as an APM application too) and the group.
    •         
             

    More:

             
                
    • This is, in concept, identical to the physical topology case (above), i.e. the database plays the role of te access router and the 3 apps play the role of the remote site devices….
    •            
    • …but this is a very good opportunity to highlight the fact that APM as well, leverages dependencies in order to suppress alerts between APM objects that have a status = Down.
    •            
    • You need to be in APM V 4.0 to leverage this. `
    •            
    • This is well described in the Explicit Dependency section of Brandon’s blog Meet the Features – Orion NPM 10.1 - Dependencies 2.0 / Basic Root Cause Analysis.
    •         
          
            

    Objective:

             
                
    • Monitor the status of the Service, based on the status of each individual objects.
    •            
    • Each object going down impacts the service.
    •            
    • The number of objects going down does not make a difference.
    •            
    • But their nature does; i.e. some objects being down will turn the Service in state critical and some in state warning.
    •         
             

    Steps:

             
                
    • Model the Service as a group that contains its constituents (router, database, application 1, 2 and 3).
    •            
    • The group can be created manually or by a dynamic query.
    •         
             

    More:

             
                
    • See more about group creation Meet the Features – Dynamic Service Groups, especially at the end of the posting, describing an Exchange Service example.
    •            
    • Note that the status propagation cares about component state being “down”, whatever this means for the component.
    •            
    • For a Node this means not responding to pings while for an Application this is based on the status of its WMI status or status of its components (in this regards, Applications act a little bit like “groups” themselves).
    •         
          
     

    *More on the so-called “Alert Suppression”

     

    Remember (you will see this also explained in other blogs, e.g. Meet the Features – Orion NPM 10.1 - Dependencies 2.0 / Basic Root Cause Analysis), “alert suppressions’ is actually NOT about really suppressing alert, but rather making the system more intelligent by adding one more state to the system: Unreachable, in addition to the previously existing Up and Down states.

     

    It’s important to understand that dependencies turn dependent objects in state Unreachable (vs. Down) when the object they depend on is Down (e.g. the router which is the unique access to a remote site). In other words, Unreachable state really means: NPM or APM does not really know their state because the only access to them is Down.

     

    It just happens that alerts are sent on state=Down. So turning objects Unreachable (vs. Down) actually prevents alerts from being created in the first place, hence this common way to describe the feature.

    The NPM team is busy at work on a number of highly requested enhancements:

    • Web performance improvements
      • General tweaks and enhancements to web console
    • Improve Orion product/module integration user flow
      • Enhance UI navigation linking together data between products and more intuitive layout of data on pages
    • Improved View Management/Graphical Reporting
      • Usability enhancements on creating new Views or Dashboards within the Orion web console and scheduling those to be delivered as reports to end users
    • User Audit Trail Tracking    
      • Ability to determine who did what and when in the Orion system. e.g. add node, delete node, add interface etc.
    • SNMPv3 traps
      • Ability to receive not only SNMPv1 or v2 traps, but also SNMPv3 traps.
      • IPv6 Support
        • Ability to add and poll device via IPv4 or IPv6
      • Internationalization
        • Stronger support for users installing and running NPM on non-English operating system

      PLEASE NOTE:  We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release.  We are working on a number of other smaller features in parallel.   If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!

      The NCM team is happy to bring you NCM 6.1. What's in it for you? Well, let me tell you!

       

      Improved Policy Reporting/Compliance Functionality Policy Reporting to the policy reporter and also ported it to the integration module. This means you can do all your policy reporting tasks either from the server app, or from the tab integration with NPM. New functionality includes block-level policy checking (e.g. Interface, VPN, VLAN…) and thwack integration to enable sharing both inside and outside the organization. Additionally, a syntax checker in the integration module allows you to see how rules will be applied to a chosen config. For those of you in the federal space, you'll notice that our new content area on thwack has DISA STIG reports ready to import and begin using right away.   

      Support for multiple config types – Backup and restore configs of whatever type you prefer: Re: ASA With mutlible context

      Comprehensive IPv6 support - if you have IPv6 in your environment, NCM can handle it. 

      Improved inventory management – Performance has been greatly enhanced (8x improvement).

      Additional device templates  - Motorola WS5100 WAP and ES3000 switches, SMC switches, Meru network controller, and many others are now supported.

       

      We also fixed bugs and did some general interface enhancements. This is a really robust release with a lot of great features. We are looking forward to hearing your thoughts!

      With this GA, I am leaving NCM in the capable pm hands of Francois Caron (fcaron). So, if you ask me a question and get a reply from him - you will know why.

      Let us know what you think of 6.1! 

      Filter Blog

      By date: By tag: