May 042011
 

I’ve seen this question on several forums around the globe.

Most of the answers were “You can’t”

Strange.

You actually really CAN’T. From Skype :D. But Skype is solely based on P2P connections and you can’t connect to any peer if you don’t have/know his IP address. They simply refuse to disclose their protocol for the public, so we can write our own plugins for Skype.

So, I’ve just had a look at my netstat output (Linux console, sorry – for Windows read below):

bash-4.1# netstat -tupan | grep skype
tcp        0      0 0.0.0.0:20530           0.0.0.0:*               LISTEN      2081/skype         
tcp        0      0 10.3.71.55:38804        212.75.19.204:6521      ESTABLISHED 2081/skype         
tcp        0      0 10.3.71.55:58519        93.152.140.108:23669    ESTABLISHED 2081/skype         
udp        0      0 127.0.0.1:59356         0.0.0.0:*                           2081/skype         
udp        0      0 0.0.0.0:20530           0.0.0.0:*                           2081/skype         
bash-4.1#

And then I’ve talked to one of my colleagues in office via Skype and rechecked for any new connections:

bash-4.1# netstat -tupan | grep skype
tcp        0      0 0.0.0.0:20530           0.0.0.0:*               LISTEN      2081/skype         
tcp        0      0 10.3.71.55:38804        212.75.19.204:6521      ESTABLISHED 2081/skype         
tcp        0      0 10.3.71.55:58519        93.152.140.108:23669    ESTABLISHED 2081/skype         
tcp        0    272 10.3.71.55:55886        10.3.71.97:16592        ESTABLISHED 2081/skype
udp        0      0 127.0.0.1:59356         0.0.0.0:*                           2081/skype         
udp        0      0 0.0.0.0:20530           0.0.0.0:*                           2081/skype         
bash-4.1#

See the 5-th line? There are too many lines, you may take the output in 2 files and then use diff.

bash-4.1# netstat -tupan | grep skype > file1.txt
bash-4.1# netstat -tupan | grep skype > file2.txt
bash-4.1# diff file1.txt file2.txt

Than I checked my own IP address:

bash-4.1# ifconfig | grep "addr:"
 inet addr:10.3.71.55  Bcast:10.3.255.255  Mask:255.255.0.0

Obviously my colleague’s IP address is 10.3.71.97.

It’s as easy as this in Windows actually. You only need to enter the Command prompt (Start -> Run -> cmd) and enter netstat the same way as with Linux (don’t know about the options after the dash and you will not have grep and protocol resolution). The Skype connection port is varying every time, so you may be in a bit of an analyze, but basically it’s the same. Your own IP address can be seen if you enter the command ipconfig /all:

If you are really LOST in CMD mode. Try this  little nifty program from Windows SysInternals. It’s doing it’s job splendidly. Just don’t forget to use the sort and filter functions if you happen to have too much connections with your PC. The principle is the same.

That’s basically all. Remember your IP address (see above) Talk in Skype to the person for which IP address you are interested and watch the new connection Skype opens. Voila. The IP address is there.

All of this will not happen if the person in you are interested is using Proxy or any anonymizer software. Then you will see random Proxy address. And to try to hack a proxy server is not something that you will just find out by reading blogs and forums. Also, there is some chance that Microsoft will change part of the Skype protocol. Good luck. 😉

There are a lot of attempts to crack Skype protocol, all of them in vain. Perhaps some day the protocol will be reverse engineered and Skype security will not be so tight. There are rumors of ONE person who did this and got a nifty $um of money for his silence.

Anyway. Feel free to bridge your Skype connection over a sniffer and try your luck. I cannot teach you how to disassemble the Skype protocol.

 Posted by at 3:12 pm
May 032011
 

Continuity check message (CCM)

What is good to know? (if you are familiar with the basics, go ahead and read)

First of all. CCMs are the heartbeat of the network being monitored. By protocol description, every CCM has few important parameters: Origin (Maintenance domain and association), hello interval and status bits, sequence number and some Organization specific stuff which is irrelevant to this guide. The packet looks like this:

00000000  d4 c3 b2 a1 02 00 04 00  00 00 00 00 00 00 00 00  |Ôò¡............|
00000010  ff ff 00 00 01 00 00 00  96 35 c1 4c 0d 87 05 00  |ÿÿ.......5ÁL....|
00000020  74 00 00 00 74 00 00 00  01 80 c2 00 00 31 00 a0  |t...t.....Â..1. |
00000030  12 4b 2f 30 81 00 c0 03  89 02 20 01 04 46 00 01  |.K/0..À... ..F..|
00000040  3d 88 00 01 04 02 61 31  02 03 6d 61 31 00 00 00  |=.....a1..ma1...|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 1f 00 0c 00  a0 12 02 2b 44 d3 3f 11  |........ ..+DÓ?.|
00000090  31 8a 00 04 00 01 01 02  00 01 02 00              |1...........|

If you are interested in the details, get the packet and dissect it in Wireshark.

Second. CCMs are transmitted between MEPs. By seeing each other’s CCMs the MEPs establish connectivity. There are however some  important prerequisites.

  • MEPs in different domains do not connect to each other, no matter what.
  • MEPs in different associations do not connect to each other, no matter what.
  • MEPs with different hello intervals do not connect to each other, no matter what.

Another important thing. If you have association named MA1 for monitoring VPLS service and association MA2 monitoring VLAN with id 300, you can’t have CFM entities connected between them. No matter the VPLS could label and carry over packets with VLAN tag 300 in Its topology.

Another important thing is the Domain level:

---------- CCM level 7 --------------------->
---------- CCM level 5 ------> MEP level 5
---------- CCM level 1 ------X

MEPs filter all lower level CCMs, MEPs process all same level CCMs and MEPs pass untouched all higher level CCMs. This filtering logic is important. If you take a look in the diagram from the previous tutorial page, you will see, that Level 7 domain should not be stopped at any point if we are going to monitor it. And provider or operator domains should not flood CCM packets outside their respective End Points. This logic applies to all kinds of CFM monitored services and VLANs, and It also provides some security and less control traffic over the whole network.

Fourth. You should never forget the MEPs have direction and different behavior when they are facing UP or DOWN (respectively IN or OUT). The diagram below is created for easier understanding when I did OAM CFM presentation for my colleagues in Telco systems. It’s a bit crude, but not hard to grasp. Basically IN and UP MEPs are the same and the words “In” and “Up” have 2 letters. OUT and DOWN MEPs are the same and the words have more than 2 letters. IN/UP MEPs are sending CCM packets in direction towards the other device ports, that are members of the same domain (a.k.a. MIPs) while the DOWN/OUT MEPs are sending CCM packets in the opposite direction. If we visualize the device as a box with 5 holes it will look like this:

In and Out MEPs

Easier to understand MEP direction

The difference in terminology is because of changes that took place while this relatively new monitoring protocol was developed in the last few years and the different vendors that support it. Currently, most (if not all) vendors use the Up and Down naming for MEPs, but if you happen to buy or receive older equipment or older software version – it’s good to know “which witch is which”.

Lot more can be said about CCMs and MEPs, but all in due time. If this article is too basic for you, please look at the OAM CFM connectivity chart.

 Posted by at 5:37 pm
Apr 222011
 

What is OAM CFM and what does it mean?

OAM is abbreviation of Operations, Administration, and Maintenance. It consists of several protocols able to monitor and control Layer 2 networks in different ways:

  • Connectivity;
  • Traffic limit allowance;
  • Traffic measurement;
  • Latency;
  • Breakpoint isolation;
  • SNMP traps and alerts;
  • Events propagation;
  • Protection switching etc.

In few words, OAM provides the Layer 2 (and Layer 2.5) networks, the tools for control and monitor Layer 3 networks have.

CFM is the protocol of this family that provides Connectivity Fault Management (CFM). If we are to put Layer 2 and Layer 3 tools side by side, you may notice some similarities (and differences):

Layer 3

Layer 2

Similarity

traceroute linktrace Full
ping loopback Almost full
TCP keep alive messages Continuity check messages Almost the same
IP/Name resolution Sender ID content Not very
Routing Protection switching Has some similarities
TCPdump / IPTraf SAA Y1731 test SAA is more sophisticated.
ping -f RFC2544 throughput test Not very

Layer 3

Layer 2

Similarity

Those are some of the similarities. The implementation however is nothing the same as in the Layer 3 network. The L2 CFM protocol uses 8 different Maintenance Domains (MD) for monitoring the different levels of service providers, core networks or system operators. Every level has it’s own number of Maintenance Associations (MA) dedicated to monitor specific provider/provider or provider/customer service, or a VLAN in the network. And every Maintenance Association depends on a set of Maintenance Points (Called also MEPs and MIPs) for it’s monitoring purposes:

OAM monitored network

OAM monitored network

To explain this diagram, we need to know some of the dry-theory language set, used inside.
Maintenance Domain (MD): The network or the part of the network for which faults in connectivity can be managed. The boundary of a Maintenance Domain is defined by a set of MAs and MEPs, each of which can be a connection point to other Maintenance Domains or to customer equipment.
Maintenance Domain name: In addition to the MD Level every domain has it’s own name.
Maintenance Association (MA): A set of MEPs, each configured with the same MAID and MD Level, established to verify the integrity of a single service instance or a single VLAN ID. An MA can also be thought of as a full mesh of MEPs.
Maintenance Association Identifier (MAID): An unique name (identifier) for a Maintenance Association. There are 2 parts of every MAID: the Maintenance Domain Name and the Short MA Name. This way, even with same names in different domains, the MA ID is unique.
Maintenance association End Point (MEP): An actively managed CFM entity, associated with a specific port of a service instance, which can generate and receive CFM PDUs and track any responses. It is an end point of a single MA, and is an endpoint of a separate Maintenance Entity for each of the other MEPs in the same MA.
Maintenance domain Intermediate Point (MIP): A CFM entity that is not actively managed. It is a physical port member of the monitored VLAN or service in the network.
Continuity Check Message (CCM): A multicast CFM PDU transmitted periodically by a MEP in order to ensure continuity over the MA to which the transmitting MEP belongs. No reply is sent by any MP in response to receiving a CCM.

OAM frames from higher domain levels go absolutely transparent over the MPs of lower level domains. This way, a customer line (or service) monitored with Domain of level 7 will have its CFM packets all the way through the Service operator and network provider domains untouched. If the Customer support wants to monitor the line between the border switches in this network, the service provider domain will pass the OAM packets to their destination untouched.

Same is valid with the two Network provider’s Rings in the diagram. They will allow the level 5 domain CFM packets to go to their destination over the active or the backup link of their Rings.

The End points (MEPs) are responsible to filter or process the CFM packets on the ports they are set. If an equal to their Domain level CFM packets are received, the MEPs need to process them. If higher then their level CFM frames are received, the MEPs need to pass them transparently. And if they receive lower level CFM packets – the MEPs need to drop them so they don’t go to supposedly higher level domains behind the Maintenance End point. With this logic – customer equipment is not supposed to receive CFM packets from Provider or Operator equipment and the Operator equipment will not receive CFM packets from the Provider.

The End points (MEPs) also distinguish the different Maintenance associations (MAs) and do not process packets from other associations different from their own. So far, any MA can have a set of no more than 8192 MEPs identified by their ID number (1..8192) and different MAs can have MEPs with same ID numbers (This proved to be bad practice in my work). No matter if the local MEP expects to receive a CCM message from MEP with ID 100, it will discard it if this CCM is sent from another MA. With this logic, regardless Provider 1 and Provider 2 are monitoring their ring networks with the same maintenance domain level, their OAM packets will not interfere with each other. This is important logic, because OAM controlled ring (e.g. R-APS ring) can easily be looped if wrong control packet is received.

Every maintenance point (MEP or MIP) is a physical port on the device. Every MEP generates CCMs (Continuity Check messages). Every MIP has to pass those CCMs to the next MIP or MEP in the same VLAN (or service) as his own.

CCMs are the heartbeat of the OAM monitored network. If the Heartbeat stops – then there is a failure. This failure will generate an event or an SNMP trap. Those events and traps can trigger actions or be logged for later analysis. This is basically what OAM protocol family is all about. (check the next chapter CCMs and MEP types)

 Posted by at 11:41 am