Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 9

Before the decade ends, show us your Orion Maps AND answer a few questions about them -- for 500 THWACK points!

Between sharing your Network Atlas maps and Worldwide maps, you've all helped us out as we continue to improve the Orion maps. Which is why we want MORE! Show us your Orion Maps (or at least the ones you cannot live without) OR email it directly to me at AND answer the following questions, then we'll award you 500 thwack points. (You must answer the questions as well as share your maps to get points)

  1. Share your map(s) below or email it to
  2. Are you still using features from Network Atlas that you NEED to have in Orion Maps?
  3. Why is a feature like Maps or Atlas important to you and your organization? What if you didn't have this feature?

Please submit your maps by December 31, 2019 to receive 500 THWACK points.

48 Replies

I love maps for reports and for training new Network Analysts about our sites.  Maps--when kept current--are a visual shortcut to seeing what may be impacted by losing any piece of hardware or circuit.


I need to have fewer places to reference, to keep current, to use as my sources of truth.  Towards that goal, I need maps to be able to display and filter information from Network Atlas so that I don't need to open/use Network Atlas at all any more.  I'm thinking of things like:

  • Showing Netpath information for anything I hover over--node, site, circuit, etc.
  • Discovering and displaying full L1 connectivity between any site. 
    • Then with overlays, display L2 connectivity that relies on the above L1 maps
    • Provide L3 display overlay options
  • But I don't want to have to see every L2 / VLAN / SVI for my devices.  It's a problem with mapping tools for which I haven't found a work around.  Showing me all the L1 or L2 connectivity ONLY between switches and routers, without making the map ridiculously complex.  Nortel's old Enterprise Switch Manager did it well.  If you're interested I'd be happy to discuss this further in detail offline.

Maps and Atlas are important for keeping uptime at five or six 9's.  When we have accurate maps, we know what's supposed to be connected.  If we didn't have maps and atlas, we'd have to buy something to do the discoveries for us, or do the work manually.  I'd done both and ended up more satisfied with the output of the manual discovery and tracking.  But it leaves human error as a factor for making the maps stale.  If someone removes or adds a new device to the network and doesn't add it to the map, the information is unavailable for use when planning and troubleshooting.  If someone makes an error when doing manual map modification, your mileage will vary.

Better still would be having NPM do all the mapping AND automatically learning nodes in the map based on CDP or LLDP information, and then automatically adding them to NCM and NPM monitoring while simultaneously updating the map.  When the map changes due to a node being down, if it had been correctly autodiscovered by the mapping process and added to NPM and NCM, it should stand out like a red light on the front page of NPM, and at the highest level of a map.

Maps should be nested:

  • Organization overview
    • Regional views
      • Site views
        • Network Room views (within each site)
    • Data Center views
      • Broken down by physical location, row, rack
      • Showing servers AND network connectivity
    • Security view
      • Firewalls
      • Proxies
      • VPN connectivity
    • Monitoring views
      • Splunk connectivity and exposure to any type of reporting device
      • Gigamon connectivity and view information
    • Cloud View(s)
      • Showing every different cloud
      • Displaying physical location resilience (any resource lives somewhere at some point in time--why not have maps able to show where that resource is / was at a specific time stamp?)
      • Displaying connectivity to our organization, from any site, to any cloud resource
0 Kudos
Level 10


1.Im still working on it...

2. I think I am

3. It shows the network- but can get too busy

0 Kudos
Product Manager
Product Manager

What we are looking for is clarity around what is necessary to improve your experience with the tool.  If you are still using Network Atlas over the web based Orion Maps, why?  You indicated that you use the tool to show the network but it gets too busy, what would improve that?  It is hard to tell from that screenshot but it appears you are mapping out a ton of interfaces in that example.

I emailed 2 maps to Kristin both of the same devices and links. One was in Atlas the other Orion Maps. Orion Maps can get cluttered very quickly in a small space as nato​ has indicated.

Here's a small snippet. Custom labels in Atlas, I can also choose to have custom labels/description for the links which I can move around (I have none though in the example). These can show me utilization, bandwidth speed etc. Also port channel shows red in atlas but not in orion maps (it was already down before I created the orion map)



Sorry I have not emailed you since our previous messages on this subject. My 2019.4 upgrade (just for the new Orion Maps features) was a bit of a disaster.

0 Kudos

Email sent

0 Kudos

1) MapExample.png

2) I think the main things I still use in Atlas that I couldn't do in the new maps are custom labels, custom tooltips, and being able to select and delete connections that I don't want the map to display.  Would be good to just have some kind of "hide this connection" at least.

3)  I find that the main value add in building these maps is it provides a way for someone who knows how everything comes together to document that and make it accessible to the rest of the team.  I may know all the critical interfaces for my WAN topology but the new hire hasn't learned them yet and it's a lot easier to point them to a WAN dashboard in Orion than to actually sit down and explain all the bits every time.  Similar problems apply to application architectures.

- Marc Netterfield, Github
Level 11

mesverrum​ - more on your point 3 - you can share that map with your NOC and that will make those connections obvious (for lots of teams). So when something goes red, its not just noise.