Help recognizing my network

Hi Sonic6t9,

Do you monitor the interfaces that went down on these 10720 RPR? Did you configure a Basic or an Advanced alert that should notify you when a such incident occurs?

Thanks in advance for giving more details about what you already configured.

Yann.

I believe it is setup for basic alerts when the interface goes down. I think the problem is the interface doesn't really show down and down. It doesn't get shut down. The ring just wraps but on CDP it will still see every node on the ring..... I tried to look all over the place at the neighboring nodes when we had an opening but, I couldn't find anything wrong. The only thing I did notice was for the time opened there was no traffic on that particular interface but that was it.

Thanks for the details.

Does the ring uses a specific protocol to advertise when a link is down? That would be great if we could poll a specific OID on the equipment. At which protocol layer level the issue is caused? Maybe your Cisco support could help there to find a pattern when the issue occurs you could not find anything wrong.

If the only pattern we have is that the Interface does not transmit or receive anything, we could create an alert that triggers an action when the Traffic Utilization of one of your 10720 RPR interfaces goes under e.g. 1% .

You can easily do this with the Advanced Alerts.

HTH,

Yann

Resilient Packet Ring (RPR), also known as IEEE 802.17, is a standard designed for the optimized transport of data traffic over optical fiber ring networks. Its design is to provide the resilience found in SONET/SDHnetworks (50ms protection) but instead of setting up circuit oriented connections, providing a packet based transmission. This is to increase the efficiency of Ethernet and IP services.

RPR works on a concept of dual counter rotating rings called ringlets. These ringlets are set up by creating RPR stations at nodes where traffic is supposed to drop, per flow (a flow is the ingress and egress of data traffic). RPR uses MAC (Media Access Controlprotocol) messages to direct the traffic, which can use either ringlet of the ring. The nodes also negotiate for bandwidth among themselves using fairness algorithms, avoiding congestion and failed spans. The avoidance of failed spans is accomplished by using one of two techniques known as “steering” and “wrapping”. Under steering if a node or span is broken all nodes are notified of a topology change and they reroute their traffic. In wrapping the traffic is looped back at the last node prior to the break and routed to the destination station.

All traffic on the ring is assigned a Class of Service(CoS) and the standard specifies three classes. Class A (or High) traffic is a pure CIR (Committed Information Rate) and is designed to support applications requiring low latency and jitter, such as voice and video. Class B (or Medium) traffic is a mix of both a CIR and an EIR (Excess Information Rate - which is subject to fairness queuing). Class C (or Low) is best effort traffic, utilizing whatever bandwidth is available. This is primarily used to support Internet access traffic.

Another concept within RPR is what is known as “spatial reuse”. Because RPR “strips” the signal once it reaches the destination (unlike a SONET UPSR/SDH SNCPring, in which the bandwidth is consumed around the entire ring) it can reuse the freed space to carry additional traffic. The RPR standard also supports the use of learning bridges (IEEE 802.1D) to further enhance efficiency in point to multipoint applications and VLAN tagging (IEEE 802.1Q).

One drawback of the first version of RPR was that it didn't provide spatial reuse for frame transmission to/from MAC addresses not present in the ring topology. This was addressed by IEEE 802.17b, which defines an optional Spatially aware sublayer (SAS). This allows spatial reuse for frame transmission to/from MAC address not present in the ring topology.

[edit] See also

The oid for our routers is 1.3.6.1.4.1.9.1.397..... I am not fully famiar with how to do these things with Solarwinds. I have been the CA spectrum Administrator for a few years and we just made teh switch. Well we are evaluating to see if we want to purchase the product. This is a major hangup in purchasing the product though. I need to know when the ring opens. 

We had a simliar problem recognizing the ring openings with Spectrum when we first got it.  We ended up having to get an engineer to come here and basically make 10720 specific event and alarms tables so it wouldn't recognize when east and west opened.

Thanks for the details about RPR, I did not know that protocol at all...no sure if it has been mentionned during my Sonet/SDH courses :-).

I think I found an interesting OID you could poll for each RPR interface on the ring which should tell you when the ring opens.

IEEE-802DOT17-RPR-MIB:rprIfRingOperModes | 1.0.8802.17.1.1.1.1.1.1.18

"The summary of the ring operational modes collected through the topology discovery protocol.

If at least one station doesn't support jumbo frames, the jumboFrame bit in this attribute is set to false.

Only if all stations support jumbo frames, the bit is true. If at least one station wasn't configured to wrap,
the wrap bit in this attribute is set to false. Only if all stations configured to wrap, the bit is true.
       
If the ring doesn't complete full loop, the ring is considered openRing, with at least one detected edge."

Possible Values:

jumboFrames(0)
wrapProtection(1)
openRing(2)



Could you try to run a MIB walk on one of the RPR device to see if they support that MIB?

Once you ensured that OID can be polled on all the interfaces, you will have to create a Universal Device Poller to poll this Custom OID.

This will help you walk the MIB and create a UnDP:

Once Orion has gathered the value of that OID, you will have to configure an advanced alert to trigger an action when the ring opens based on the value of that Universal Device Poller.

This post should help you to create the Alert:


Note, you should check all the OIDs available in the IEEE-802DOT17-RPR-MIB to be sure the OID I found is the best one you can use. The available OIDs should have more sense to you than for me as you are familiar with the protocol.

http://www.ieee802.org/17/projects/P802_17/802.17_MIB.txt


HTH,

Yann

I do not see that specific OID or anything really close to that. I see a crap load of sonet stuff and the actual interfaces

if-mib 1.3.6.1.2.1.2.2.1.2.2 ifdescr.2  rpr-IEEE1/1-West Span-SONET-SDH medium/section/line

if-mib 1.3.6.1.2.1.2.2.1.2.3   rpr-IEEE1/1-East Span-SONET-SDH medium/section/line

I ended up with 51374 entries running your mib walk.

On the Cisco web site, the 10720 router is advertised to suppor the IEEE-802DOT17-RPR-MIB mib.

... RPR features- Intelligent Protection Switching (IPS) with less than 50-ms restoration time and SRP/RPR MIB support ...

Could you check with your Cisco support if this is possible to enable the support of that MIB?

Concerning the two OIDs you found, they are from the IF-MIB which is the default MIB polled by Orion to monitor interfaces. I doubt we will get any real status from that MIB if Orion could not manage it.

I found another OID that gives the status of the SONET interface in the SONET-MIB.

sonetPathCurrentStatus | 1.3.6.1.2.1.10.39.2.1.1.1.2

This variable indicates the status of the interface.
The sonetPathCurrentStatus is a bit map represented as a sum, therefore, it can represent multiple defects simultaneously.
The sonetPathNoDefect should be set if and only if no other flag is set.

The various bit positions are:

1   sonetPathNoDefect
2   sonetPathSTSLOP
4   sonetPathSTSAIS
8   sonetPathSTSRDI
16   sonetPathUnequipped
32   sonetPathSignalLabelMismatch


Could you try to walk that OID and see if it returns you something?

Thanks,

Yann

I ran the mib walk and found numbers close to it. Mine have another 1 at the end

1.3.6.1.2.10.39.2.1.1.1.1.2  sonetpathcurrentwidth 2 value 5

1.3.6.1.2.1.10.39.2.1.1.1.2.2  sonetpathcurrentstatus.2    value 1

1.3.6.1.2.1.10.39.2.1.1.1.2.3 sonetpathcurrentstatus.3  value 1

I work for the City of Austin and we are evaluating the product.

1.3.6.1.2.1.10.39.2.1.1.1.2.2  sonetpathcurrentstatus.2    value 1 1.3.6.1.2.1.10.39.2.1.1.1.2.3 sonetpathcurrentstatus.3  value 1

The last number in the OIDs in the interface Index. The value returns means the interface has no problems (sonetPathNoDefect). If this OID correctly changes to something else when you get an outage on your ring, then this is the one we need. I would recommend you to make some tests before we can state it is actually reflecting the status of the interface.

once you confirmed this, follow the links of my previous post to create a Universal Device Poller and set an advanced alert to trigger an action when the value of that OID is different from 1.

I work for the City of Austin and we are evaluating the product.

If you get a chance, you should call the sales and ask if anyone among the Sales Engineer can come downtown to show you the features of the product . The SW HQ are along the South MoPac Expressway