Peer Table Explained

Every diameter node maintains two tables to know its near about.
1) Peer Table
2) Realm Routing Table

Peer Table
It is basically maintained to know, "to which node a considered node has peer connection". I.e. to which node any considered node is connected. Peer Table has following fields.

Host identity
     In simple words name of the Node i.e. Diameter URI of Node
StatusT
    State of the peer  such as Open , Busy, Idle etc.
Static or Dynamic
   Specifies whether a peer entry was statically configured, or dynamically discovered.
Expiration time
   Specifies the time at which dynamically discovered peer table entries are to be either refreshed, or                 expired.
TLS Enabled
   Specifies whether TLS is to be used when communicating with the peer.
Some more fields can be added i.e. some fields related to Key, Certification.

For Example
Consider the following network. 
Peer Table for NodeA is as follow



Host Identity
StatusT
Static or Dynamic
Expiration Time
TLS Enabled
node_b.realm1.com
Idle
Dynamic
600
False
node_e.realm1.com
Open
Static

False
node_i.realm1.com
Pending
Static

False
node_f.realm2.com
Open
Static

True


Your Comments /Suggestions and Questions are always welcome.

29 comments:

  1. Diameter protocol is a message-based, signaling protocol designed to provide authentication, authorization, and accounting (AAA) functions in IP-based networks.

    ReplyDelete
    Replies
    1. Yes...

      http://diameter-protocol.blogspot.com/2011/03/introduction-to-diameter.html

      Delete
  2. Hi,
    can we have more than 1 Diameter connection between two Diameter peers? Or is it forbidden by RFC?

    Best regards

    ReplyDelete
    Replies
    1. Ideally we should not have more than one transport connection between two peer, but In implementation it happens. two peer ideally should connect 3868 of each other publishing all applications and security features.

      In New RFC we have two default ports 3868 and 5868 so these thing are implementation Dependant.
      "Default port for TCP or SCTP is 3868 and Default Port for TLS/TCP or DTLS/SCTP is 5868"

      Delete
  3. How is the states Open , Busy, Idle defined ?
    Any link to it would help

    ReplyDelete
    Replies
    1. Hi

      In above example states are given randomly.

      Following link could help you
      http://diameter-protocol.blogspot.in/2011/06/diameter-sessions-and-session-states.html

      Delete
  4. How is the dynamic config maintained ? Want to know about a server accepting connections from different clients. How is this implemented?

    ReplyDelete
    Replies
    1. Hi

      Practical implementation of peer table could be different from vendor to vendor but an example of peer table is given above for dynamic as well as for static configuration.'

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  5. are the default port (3868 and 5868) just just for receiving connection?
    for example, any application that diameter client/server point out, the destination port of diameter agent(relay, proxy, redirect or translate) should be the default port. is my statment right?

    ReplyDelete
    Replies
    1. Hi,

      Here in diameter Port (LISTEN) are used to receive a connection from client. Client can be an application, relay, proxy etc. any node that is initiating a message is considered as client while other as server. Client send message to server's LISTEN Port

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  6. I have a diameter client which initiates a connection (static) to DRA. Is it mandatory for my client to have DRA-HOST-ID and DRA-REALM in my peer table? Should the client validate origin-host and origin-realm from CEA message before establishing diameter connection? If yes, is there any reference for the same in RFC?

    ReplyDelete
    Replies
    1. Hi Somesh,

      Please help us that we understand your query correctly.

      For instance, You have a client with Origin-Host Id "client.test.com" and Origin-Realm "test.com" sending CER to server having Diameter Identity "server.test.com" and server realm "test.com" on common application X.

      You have also statically configured Peer table with and Realm table with entries as "server.test.com" and "test.com" on application X.

      Now server is sending CEA with Reult-Code set to success and (common) application id set to X but its origin-host as "SeRvER.test.com" instead of server.test.com and Realm as "TEST.com" instead of "test.com"

      Now now your question whether Diameter connection should establish or not.


      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
    2. Thanks for the response.

      My question is whether it is mandatory to configure Peer table with and Realm table with entries as "server.test.com" and "test.com" on application X for connection to establish.

      If yes, is there any reference for the same in RFC. My understanding is that the peer table should contain the host-id and realm of incoming connection (CER received) only.

      Thanks in advance.


      Delete
    3. Thanks for the response.

      My question is whether it is mandatory to configure Peer table with and Realm table with entries as "server.test.com" and "test.com" on application X for connection to establish.

      If yes, is there any reference for the same in RFC. My understanding is that the peer table should contain the host-id and realm of incoming connection (CER received) only.

      Thanks in advance.


      Delete
    4. Hello Somesh,

      Entry in peer table is purely implementation specific. If you have allowed unknown peers(not configured in static table) to connect your application, entries(host id and realm) will be dynamically added to peer table(there may be no static entry).

      It is preferred that except putting filtering on diameter peer table, you can put conditions on your transport layer (SCTP). SCTP abort on receiving unknown peers will more helpful in reducing network usage as well.

      Delete
  7. Hi,
    I've been working on Diameter Protocol I downloaded Free Diameter open source code from http://www.freediameter.net/trac/ . I want to change the entries of Peer Table and Realm Table as per my requirement but I can't seem to find the entries in source code.

    Need help.Thanks in advance.

    ReplyDelete
    Replies
    1. Hi Arjun,

      Will you please share your configuration file. use following links to change it accordingly.

      1)Example configuration is given Please use acl_wl.fdx extension instead of acl_wl.fx as it is a typo-error
      http://www.freediameter.net/trac/wiki/Configuration


      2) Details of extension
      http://www.freediameter.net/trac/wiki/Extensions


      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  8. Hello folks,
    I have a situation with DIAMETER connections and peer table maintenance. Suppose I have 2 instances of DIAMETER peer having same DiameterIdentity (e.g. FQDN -
    inst.domain.com), now these instances initiate transport connection and then CER (both with Origin-Host as inst.domain.com). When the server application receives these CERs, what will be the entry of Peer table and state of the Peer. I suspect, the Peer table will only have 1 entry - the later one. Should we disconnect the first connection and owner the second.

    ReplyDelete
    Replies
    1. Hi Gaurav,

      Your observation is correct. Server shall keep the entry of latest connection in peer table and shall remove the entry of previous one.

      If previous connection tries to connect again (if Re-Connect is Enabled) then it shall create a ping-pong situation where one connection disconnecting other.


      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
    2. But how can we have two nodes with same FQDN (DiameterIdentity). Is this situation feasible ?

      Delete
  9. Hi,
    I am running Diameter protocol over TCP. Is it possible that one client have multiple connection to same server (same host & realm) for same application id?

    I see client is opening multiple TCP socket and connecting to same server and also responding to watchdog message. Is it correct for diameter protocol.

    br,
    Neeraj Surana

    ReplyDelete
    Replies
    1. Hi Neeraj

      @TCP connection level it is ideally not possible a that a client with same socket details (port and id) have multiple connection to a server.


      following link shall help you.
      http://diameter-protocol.blogspot.in/2012/12/introduction-to-tcp.html


      @ Diameter Level if a server receives a CER request with diameter identity and realm that are identical to already created connection then it shall treat receiving CER as fresh and shall terminate already created connection.

      following link shall help you.
      http://diameter-protocol.blogspot.in/2011/05/diameter-peer-connection-and.html


      Please check following in your scenario
      1) Client TCP Port shall be different in each connection.
      2) Client shall be having different diameter identity for each connection.

      Hope we could help you.

      Thanks for your query.
      Happy to help you again.
      Team Diameter

      Delete
    2. This comment has been removed by the author.

      Delete
    3. Hi,

      Thanks. But RFC 6733 says:

      "A given Diameter instance of the peer state machine MUST NOT use more
      than one transport connection to communicate with a given peer,
      unless multiple instances exist on the peer, in which, case a
      separate connection per process is allowed."

      I understand this mean, different instances (process) may use same diameter identity and realm to connect with same server and will use different TCP socket.
      For ex:
      Can two process exist
      Client1 ( IP1, Port1, hostname1, realm1), PID-1 <-> Server (ServerIP, ServerPort, serverName, ServerRealm)

      Client2 ( IP1, Port2, hostname1, realm1) PID2 <-> Server (ServerIP, ServerPort, serverName, ServerRealm)


      Pls let me know if this is possible. If yes, how server will know that 2nd CER is from same process or different.

      Thanks and regrds,
      Neeraj Surana

      Delete
    4. Hi Niraj

      Appreciate your depth of knowledge.

      You are almost there, to understand statement given in rfc-6733, following suggestions shall help you.

      -- the given statement is about transport connection (Transport Layer OSI-Model) not about diameter Connection (Application Layer)

      -- Here word "peer" implies very next hop/system, could/should replace with server/pc for better understanding; means one transport connections between peer/server unless....a separate connection per process is allowed.

      -- it is sayings multiple instances not the identical instances therefore Diameter identities shal be different.

      Hope we satisfy your question.

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  10. Hi Team,

    Can diameter requests be configured to response with same Origin-Host for all logical servers?

    ReplyDelete
    Replies
    1. Hi Khushbu

      Response shall contain the origin-host on which origin-host request is received.

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete