Forum Discussion

abeny_894's avatar
abeny_894
Icon for Nimbostratus rankNimbostratus
Mar 07, 2012

Diameter questions

Hi all, Good Day! I have a question about F5 LTM with Diameter need to seek advise, anybody can help?

 

 

 

For a Diameter (DCCA) charging, a CCR ( Initial, Update, Terminate) may consist multiple MSCC. Is it possible that: 1) when incoming CCR with multiple MSCC, F5 can detect it, and break it to multiple CCR (each CCR with only 1 MSCC)?

 

 

2) if 1) is possible, can F5 consolidate all related (single MSCC) CCR, concatenate to a single CCR and response to original CCR?

 

 

 

Can iRules handle the above case? Thank so much

 

 

 

 

Abeny

4 Replies

  • > 1) when incoming CCR with multiple MSCC, F5 can detect it, and break it to multiple CCR (each CCR with only 1 MSCC)?

    yes, it is possible. in latest version, you can do something like this...

    
    when DIAMETER_EGRESS {
         extract header (yeah, we should have a better way of cloning whole header)
        set v [DIAMETER::header version]
        set r [DIAMETER::header rflag]
        set p [DIAMETER::header pflag]
        set e [DIAMETER::header eflag]
        set t [DIAMETER::header tflag]
        set c [DIAMETER::command]
        set aid [DIAMETER::header hopid]
        set hid [DIAMETER::header hopid]
        set eid [DIAMETER::header hopid]
        
        set count [DIAMETER::avp count 456]
        for { set i 0 } { $i < $count } { incr i } {
             copy all AVPs to variable
            set avps [DIAMETER::payload]
             delete other MSCCs
            for { set j 0 } { $j < $count } { incr j } {
                if { $j != $i {
                    DIAMETER::avp delete 456 $j source $avps
                }
            }
             we might need to modify hop by hop id and end to end id to make it unique
             otherwise, server may be confused. however, it may also depend on server's implementation
             we might also need to keep some tracking information? so we can combine them back later on...
            DIAMETER::respond $v $r $p $e $t $c $aid $hid $eid $avps
        }
         drop original CCR
        DIAMETER::drop
    }
    

    > 2) if 1) is possible, can F5 consolidate all related (single MSCC) CCR, concatenate to a single CCR and response to original CCR?

    I guess you mean CCA? yes, it is possible. however, when we receive each CCA, we may need to save its response to variable, drop it. whenl the last response comes, then you combine all responses into the last CCA and send back to client.

    Nat
  • Thanks so much Nat :)

     

     

    Is it means that the above iRules need to used in v11.1?

     

     

    However, how does the iRules look like in question 2? Seems no any ideas about that.......

     

     

     

    Abeny
  • Hi Abeny,

    11.1 or 11.0 (11.1 is definitely better as some bugs are fixed)

    here is sample for question 2

    it is not complete but at least it may provide some example.

     
    when DIAMETER_INGRESS {
         if it is not the last one, collect data, drop
         if it is last CCA, append data which is collected earlier before pass it through
        if { ! $last_CCA_of_the_same_series } {
             save necessary part of response, for example, you may
             - delete common avp such as, Origin-Host/Realm/etc
             example:
             set avps [DIAMETER::payload]
             DIAMETER::avp delete Origin-Host source $avps
            
             Then append avps to a variable
             use some form of unique key such as hid/eid/subscriber-id?
             to ensure resposne belongs to same CCR
             append collected_avps($key) $avps
            
             Then drop current response
            DIAMETER::drop
        } else {
            DIAMETER::payload replace [DIAMETER::payload]$collected_avps
        }
    }
    

    btw, there are also one technique you can use. you can send insert proxy-info AVP in CCR, if server support it, server will echo back that information. this way, you dont need to keep state (or at least can keep less state information on BIG-IP itself)

    Nat