RPT Segment Fanout

[Anon Anon]

Occasionally whenever I discover connections on a switch I will get in the topology view a bunch of Rpt Segment Fanout icons. What gives? What are they exactly?

[ackjo04]

The following is from the "Modeling and Protocol Options Subview" section of the "Modeling and Managing Your IT Infrastructure Administrator Guide":

 

 

Create 802.3 Fanout

 

If this parameter is set to Yes and if CA Spectrum cannot make an accurate connection among three or more interfaces, a Fanout model named "802.3_Segment" will be created and these interfaces will be connected to the Fanout model. If this parameter is set to No, a Fanout model will not be created for the interfaces that have unclear connection information, and therefore these interfaces will not be mapped. However, if there is a data relay device’s interface among these interfaces, and all other interfaces are for end node devices, a Fanout model with name "Rpt_Segment" will be created.

 

[Anon Anon]

So does the Fanout represent a hub that is connected to a switch?

[ackjo04]

It could represent a non managable hub connected to a switch. It could also indicate a switch or managable hub connected to a switch that is not modeled in the database.

[Anon Anon]

So they could be a: hubs, b: unmanaged switches, or c: a switch not modeled in the database.  I suspect either a and/or b.

[MattClausen]

a Fanout is a way for SPECTRUM to model a "Many-To-One" connection on a switch port.... What it really represents is multiple different MAC addresses discovered on a switch port for modeled devices in the SPECTRUM landscape. So if you had a hub for example connected to a switch, and then multiple devices modeled in SPECTRUM connected to the hub - SPECTRUM would resolve the topology as SWITCH --> FANOUT --> Multiple Modeled Devices (where FANOUT represents the Hub in this case). Likewise in the case of VM environments.... the fanout can represent the trunked vSwitch coming into the network switch (as several MAC addresses for the VM will appear to the switch port).

 

A fanout can also appear when you accidentally forget to model a switch sitting in between modeled devices and an upstream switch. In this case the trunk port will have multiple MAC addresses appearing on it but SPECTRUM does not know about the downstream switch so it would model a fanout connector then connect all the modeled devices for who's MAC addresses it found to the fanout connector.

 

Just remember that at the heart of the model so to speak, is SPECTRUM representing multiple MAC addresses found on a single switch port.

[Oscar Gonzalez]

Hi MattClausen,

 

So, If I have a Fanout representing a VM enviroment, and I don't want it, How can I fix it? There's a hotfix for this issue? Can the VM enviroment be modeled as it is and not as a Fanout?

 

Thanks in advance.

[MattClausen]

If you don't want the FanOut, you can always delete it.... but depending on how you're modeling the device - the fanout will get created. If you're using the discovery console, there's some options in there that would override the behavior that creates a fanout, but if you're using Model By IP and select discover connections it'll be created.

 

You can always rename the Fanout connector to something more intuitive (i.e. the switch port) but depending on the VMWare environment - this may not be a good thing... If the VMs tend to vMotion around a lot, you're going to need something like VAIM to help SPECTRUM keep track of where everything is with the vCenter integration.... but that's a whole new topic.

[Oscar Gonzalez]

Matt,

 

Thanks for the reply.

 

So, if I don't want a fanout,  can't I discover that connection/device and model a VM device instead a fanout?

[Anon Anon]

If the conditions Joe Ackley described above are met, then any time discover connections runs on the respective switch or end node(s), a Rpt_Segment will reappear between them.  This is not configurable.

 

Scott

[Legacy User]

I had to delete this one because it was showing as contact status lost and it was suppressing the lost status on a more important downstream device.

 

F    N    13:07:08  Rpt_Segment     VAC-ACC\SpectrumAdmin  spectrum01  CRITICAL Alarm on Rpt_Segment of Device Type  N/A at 05/10/2016 13:00:05 AST - INFERRED CONNECTOR CONTACT STATUS LOST.