Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Bill_Ng
Collaborator

pep: inx invalid type

Hi All,

Since we have upgraded from R77.30 to R80.10 Take 156 on a VSX gateway and regular gateway, I am seeing 'inx invalid type (0) on the VS instances on the appliances.

When I run 'pep show pdp all' the Source IP isn't listed.  See below.

When I run 'pep show pdp all'  on R80.10 Take 121 on a gateway.  I get the info I expect.

I ran a packet capture on R80.10 Take 121 appliance using 'tcpdump -enni any port 15105'  I noticed that the IPs were different between the pep show pdp all command and the packet capture.

10.1.1.1 was shown in 'pdp show pdp all'  which is the management IP of the pdp cluster.

10.2.2.2 was shown in the packet capture which is the inside/campus interface of the same pdp cluster.

I also looked at sk60701.  Nothing is set in ia_control_connections_ip field.

Questions are below.

  1. Any reason for why we see inx invalid type (0)?
  2. Is there concern that 2 different IPs are being reflected?  And could that be causing a problem?

We are using Identity agent client using user authentication installed our workstations.

Thanks,

Bill

0 Kudos
5 Replies
Frank_Allen
Employee Alumnus
Employee Alumnus

Hey Bill,

Since you and I have a service request on this, I will be able to provide you more details on this as we investigate this with our R&D team. We aren't sure of the full impact regarding "inx invalid type (0)", but this signifies that the IP has changed somewhere between PDP and PEP in their communications, which could cause some syncing issues.

I will update you in our Service Request regarding this issue as soon as I have more information.

Thanks,

Frank

Tobias_Moritz
Advisor

We have the same problem in one of our platforms.

Identity Sharing is working fine between R77.30 PDP and R80.10 PEP Jumbo HFA T121. Any newer Jumbo HFA on the R80.10 PEP side and we have the same problem like you:

"inx invalid type (0)" instead of the PDP source IP.

We have set an ia_control_connections_ip like descriped in sk60701, so it has obviously nothing to do with this.

We are already in contact with TAC (case 6-0000617243) and they asked R&D already.

But no solution yet.

0 Kudos
Bill_Ng
Collaborator

Hi Tobias,

We ended up changing the setting under the setting under Identity Sharing for the FW from 'all sharing gateways' to the defined pdp server.  I also recall that if you did a 'pep debug ip_map' when having the issue it displayed something odd as well or coincided with inx invalid type you are seeing.  Once we pointed the FWs to the main pdp gateway, it all looked much better.

Thanks,

Bill

0 Kudos
Tobias_Moritz
Advisor

Thanks for the hint, but we checked this already. We never used the „all sharing gateways“ option, but set one specific main pdp gateway only.

We also cleaned all IDA tables with the fw tab command. It didn‘t help.

Tobias_Moritz
Advisor

Sorry, I forgot to update here:

The solution for our problem was sk63264 (manual nat rule required to hide pdp<->pep traffic behind cluster address).

This sk is very old, so it's a little strange that we never needed this with R77.x or R80.10 older jumbos.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events