BB code in posts seems to be working again!
I haven't turned on every single tag, so please let me know if there are any that are used/needed but not activated.

Main Menu

Visio model of a Network in both Physical and Virtual

Started by cliff50, September 29, 2014, 11:51:23 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Hi ,

attached video and files demonstrating both physical and virtual aspects of a Telecommunication network.

I am using MSVisio to automate information from a backend data repository, that is fortified by periodic scan of real time data. (not a new Idea)

The visio interface is similar to Al's DCRacks project.

The demonstration shows how to trace the physical  "across a crowded room", however, once the patch lead tracing routine enters the SDH Transmission Network topology, it continues to trace the virtual connections within the Telecommunication Nodes,
delivering an end to end trace "across a crowded network". ( I have attached the resulting tracelist).

The trace listing represents a transited path of approximately 500Km in length along an actual Telecommunication Network.



Very impressive. I've not started working on rack elevations portion of my own automated network diagramming tool; just the node view, detailed view, and network block diagram views are complete. Some day when I get more time I'd love to incorporate something similar to what you've done here, or what I've seen of the DCRacks Project, into my own toolset. 

Thanks for sharing, very nice looking tool.



 :-\ I have arrived at a juncture, where I need to produce a predictive analysis of circuit failures on a very complex routed network.

Consider a state wide enterprise of 3000 plus cisco routers and devices interconnected via optical fibres. An overall birds eye view of connectivity reveals star and ring topologies everywhere you look. :o

The routing tables within the devices will redirect traffic around a singular break between two routers , However there are times when a major cable fracture will sever multiple inter router connections  (multiple physical links within the one cable are referred to as called co-locations).

Co-location ruptures to cable infrastructure can cause severe degradation to routed networks, therefore it is adviseable to have a "model" which can predict and identify these achillies heels in such networks.  >:(

Was wondering if any shared experience or thoughts regarding visio modelling of complex networks of this nature are out there.



the short answer is that for each of the components in a path, some form of 'availability' number would need to be recorded if the objective for predictive is going to be met. At it's highest level capture of 'outages' might be used, but for a more robust analysis link data should be captured. The background is that long before a link goes down hard there is often a history of intermittent data errors. My own experience is that the carrier sees the data error degradation and then takes the link out of service for maintenance forgetting to let the end-user know. In a robust network with SLAs this intermittent failure often shows up as response-time objectives not being met due to the high number of retransmissions (which tend to grow at a Log scale due to the retransmissions also being corrupted).
With a current availability history it is just a math problem of computing the overall availability of the path.


Hi Al  :)  attached are two diagrams showing my problem.

Both diagrams show 4 X routers.

One diagram shows 6 X physical interconnections, which is allowing any of the 4 routers, to have a physical path to a neighbour.

The other diagram associates the 6 X physical interconnections with cabling infrastructure, Cable A Cable B and Cable C.

When I peruse the diagram without the Cabling information, I get a warm and fuzzy feeling that the routed network is robustly designed to withstand a solitary break to any interconnection. ( Cisco routing tables will deploy traffic around a break).

However, when I look at the diagram with the Cabling information, I see a different story.
If "farmer Brown" digs up Cable B all 6 physical interconnections pop!, and as a consequence all 4 routers will be isolated from each other.

I know Cisco works produce a product that can diagram the networks routed neighbours, but I dont think it caters for cabling infrastructure along the interconnections.  ::)

Ostensibly, when I say a predictive tool, I am not refering to the ability to capture and process historical data on errored links. I was imagining a model of cabling infrastructure which would encompass the ability to identify the devices that are connected to the fibres within each cable.
(I have seen cabling models but they dont go so far as to include routing devices)

Without such a predictive tool, my next best option would be a Gypsy's crystal ball.  :-\



When I got into that issue (a long time ago), I ended up writing a routine to query the routers for 'connected neighbors' and storing the results in a database for the analysis. Your challenge of course is that both RIP and SPANNING TREE alter your routing tables so that what you view as the topology is not what the routing algorithms see as available. The
query of the "connected neighbors" identifies the ports that are being used (which is why port data is included in the
DCRack project).



Dont forget TRILL, DCE for networks and SRIOV/MRIOV for server internals for things like VxLAN
And, of course, there are all the emerging rack fabrics (OMNISCALE, PCIe Fabric, etc).

All of which may affect routing tables and such

Browser ID: smf (possibly_robot)
Templates: 4: index (default), Display (default), GenericControls (default), GenericControls (default).
Sub templates: 6: init, html_above, body_above, main, body_below, html_below.
Language files: 4: index+Modifications.english (default), Post.english (default), Editor.english (default), Drafts.english (default).
Style sheets: 4: index.css, attachments.css, jquery.sceditor.css, responsive.css.
Hooks called: 250 (show)
Files included: 34 - 1306KB. (show)
Memory used: 1109KB.
Tokens: post-login.
Cache hits: 13: 0.00138s for 26,766 bytes (show)
Cache misses: 2: (show)
Queries used: 16.

[Show Queries]