i-Rule for Diameter AVP realm rewrite on a virtual server

Which version of BIG-IP are you using for this?

Which version of BIG-IP are you using for this?

Hello Experts

Any advice for this query?

Sumanta.

I asked about the version because the Diameter handling in 11.x is quite different than in 12.x. In 12.x, one uses the Message Routing Framework for Diameter traffic. However, the rule below should work for both 11.x and 12.x (though under 12.x, it must be applied both to the Message Routing Virtual Server and to the transport-config).

For this rule, I made a few assumption. Firstly, I assume that by "change the diameter realm", you mean "change the Origin-Realm" (rather than, say, the Destination-Realm, though if you need to do that instead of or in addition to the Origin-Realm, it is a simple change of the rule below). I further assume that in any message in your Diameter application, the Origin-Realm is present no more than once, and is never part of a grouped AVP.

when DIAMETER_EGRESS {                                                                                                                
    switch [DIAMETER::avp data get "Origin-Realm"] {                                                                                  
        "ims.mnc090.mcc100.3gppnetwork.org" {                                                                                         
            DIAMETER::avp data set "Origin-Realm" "ims.mnc099.mcc100.3gppnetwork.org"                                                 
        }                                                                                                                             
                                                                                                                                          
        "ims.mnc099.mcc100.3gppnetwork.org" {                                                                                         
            DIAMETER::avp data set "Origin-Realm" "ims.mnc090.mcc100.3gppnetwork.org"                                                 
        }                                                                                                                             
    }                                                                                                                                 
}            

As a somewhat important aside, under 11.x, the BIG-IP will act (more-or-less) as a Diameter proxy. However, unless you tell it to do so, it will not assert its own Origin-Host and Origin-Realm. It will also not pro-actively open transport and Diameter sessions toward pool members. Instead, when a client makes a connection to the Virtual Server and a Diameter message LB decision is made, if an existing Diameter connection is not open to the target pool member, a connection will be opened, and the client's Origin-Host and Origin-Realm will be used. When the pool member responds, it's Origin-Host and Origin-Realm will be asserted toward the client. However, the BIG-IP will maintain independent Diameter sessions on each side. Among other things, this means that watchdog messages are not proxied in any way.

I asked about the version because the Diameter handling in 11.x is quite different than in 12.x. In 12.x, one uses the Message Routing Framework for Diameter traffic. However, the rule below should work for both 11.x and 12.x (though under 12.x, it must be applied both to the Message Routing Virtual Server and to the transport-config).

For this rule, I made a few assumption. Firstly, I assume that by "change the diameter realm", you mean "change the Origin-Realm" (rather than, say, the Destination-Realm, though if you need to do that instead of or in addition to the Origin-Realm, it is a simple change of the rule below). I further assume that in any message in your Diameter application, the Origin-Realm is present no more than once, and is never part of a grouped AVP.

when DIAMETER_EGRESS {                                                                                                                
    switch [DIAMETER::avp data get "Origin-Realm"] {                                                                                  
        "ims.mnc090.mcc100.3gppnetwork.org" {                                                                                         
            DIAMETER::avp data set "Origin-Realm" "ims.mnc099.mcc100.3gppnetwork.org"                                                 
        }                                                                                                                             
                                                                                                                                          
        "ims.mnc099.mcc100.3gppnetwork.org" {                                                                                         
            DIAMETER::avp data set "Origin-Realm" "ims.mnc090.mcc100.3gppnetwork.org"                                                 
        }                                                                                                                             
    }                                                                                                                                 
}            

As a somewhat important aside, under 11.x, the BIG-IP will act (more-or-less) as a Diameter proxy. However, unless you tell it to do so, it will not assert its own Origin-Host and Origin-Realm. It will also not pro-actively open transport and Diameter sessions toward pool members. Instead, when a client makes a connection to the Virtual Server and a Diameter message LB decision is made, if an existing Diameter connection is not open to the target pool member, a connection will be opened, and the client's Origin-Host and Origin-Realm will be used. When the pool member responds, it's Origin-Host and Origin-Realm will be asserted toward the client. However, the BIG-IP will maintain independent Diameter sessions on each side. Among other things, this means that watchdog messages are not proxied in any way.

Hi Vernon

Can we apply the same i-rule for reverse traffic (to revert the AVP value) since virtual server will only deal with forward traffic to the nodes?

This rule applies to both directions of a flow. Under 11.5, BIG-IP retains its full-proxy "client-server" view for Diameter traffic. In this architecture, the "client-side" is a transport flow between a system and a BIG-IP Virtual Server. The "server-side" is the proxied flow based on client-side traffic. Thus, when a Diameter instance initiates a flow toward a BIG-IP Virtual Server with the diameter profile applied, this usually initiates a server-side flow toward a pool member, which is a different Diameter instance. I say "usually" because it may re-use an existing server-side Diameter connection. In either case, there client-side traffic and server-side traffic belong to single connection (aka, flow) table entry. the DIAMETER_EGRESS event will fire just before a Diameter message is proxied in either direction.

So let us assume your flow looks like this:

peer1  <-->  BIG-IP  <-->  peer2

peer1 is talking to a BIG-IP Virtual Server, while peer2 is a pool member. Let's say that peer1 sends a CCR with the Origin-Realm set to "ims.mnc090.mcc100.3gppnetwork.org". The iRule above, if applied to the Virtual Server, will fire. The message will be proxied to peer2, but the Origin-Realm will be set to "ims.mnc099.mcc100.3gppnetwork.org". When peer2 responds with a CCA, it belongs to the same BIG-IP connection table (aka, flow) entry, so the iRule will apply to it, as well. Therefore, when it assert "ims.mnc099.mcc100.3gppnetwork.org" as the Origin-Realm, the message will be proxied to peer1, but the Origin-Realm will be changed to "ims.mnc090.mcc100.3gppnetwork.org".

Based on your request, I believe this is what you desire and expect.

If, on the other hand, you are saying that either peer1 or peer2 may initiate a Diameter connection (meaning, it will initiate the transport and assert the CER), then you will need a Virtual Server or set of Virtual Servers (each with the diameter profile and this iRule applied) to which either peer can connect.

This rule applies to both directions of a flow. Under 11.5, BIG-IP retains its full-proxy "client-server" view for Diameter traffic. In this architecture, the "client-side" is a transport flow between a system and a BIG-IP Virtual Server. The "server-side" is the proxied flow based on client-side traffic. Thus, when a Diameter instance initiates a flow toward a BIG-IP Virtual Server with the diameter profile applied, this usually initiates a server-side flow toward a pool member, which is a different Diameter instance. I say "usually" because it may re-use an existing server-side Diameter connection. In either case, there client-side traffic and server-side traffic belong to single connection (aka, flow) table entry. the DIAMETER_EGRESS event will fire just before a Diameter message is proxied in either direction.

So let us assume your flow looks like this:

peer1  <-->  BIG-IP  <-->  peer2

peer1 is talking to a BIG-IP Virtual Server, while peer2 is a pool member. Let's say that peer1 sends a CCR with the Origin-Realm set to "ims.mnc090.mcc100.3gppnetwork.org". The iRule above, if applied to the Virtual Server, will fire. The message will be proxied to peer2, but the Origin-Realm will be set to "ims.mnc099.mcc100.3gppnetwork.org". When peer2 responds with a CCA, it belongs to the same BIG-IP connection table (aka, flow) entry, so the iRule will apply to it, as well. Therefore, when it assert "ims.mnc099.mcc100.3gppnetwork.org" as the Origin-Realm, the message will be proxied to peer1, but the Origin-Realm will be changed to "ims.mnc090.mcc100.3gppnetwork.org".

Based on your request, I believe this is what you desire and expect.

If, on the other hand, you are saying that either peer1 or peer2 may initiate a Diameter connection (meaning, it will initiate the transport and assert the CER), then you will need a Virtual Server or set of Virtual Servers (each with the diameter profile and this iRule applied) to which either peer can connect.