Tracking tunnel interface this possible ?

Unanswered Question
Mar 10th, 2010

Hi there,

It has been quite a while since i've posted here.... hope any of you can help me !!!

I have a complex network that i'll try to describe the best i can. There is a specific router that manages ip sessions on a subscription basis (GGSN for thos who know ..), and, in this case, corporate sessions, that are binded by APN (access point`s).. something like a vpn for a group of devices...

So, at this moment, i have a IPSEC tunnel established between a loopback address in the GGSN and the costumer premises, which allows me to deliver ip traffic from the devices to the corporate LAN and vice-versa. This GGSN is clever engouh to prevent any ip session if the tunnel goes down...

Now, i'm proposing to shift the IPSEC tunnel from the GGSN to the boundary router (security, performance and design issues), but ran into a huge handycap. This approach makes GGSN blind to reachability concerns... i.e. if IPSEC tunnel goes down, GGSN is not aware and will continue forwarding traffic and worse will continue allowing session creating...

To overcome this issue, the only way i can think of is configuring a simple tunnel (i.e. GRE) between ggsn and Router and then have some kind of reachabilitiy feature ..or interface tracking so that in the case ipsec tunnel goes down, GRE tunnel goes down and GGSN is aware if it and prevents any new session .....

Thank you,


([email protected])

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Laurent Aubert Wed, 03/10/2010 - 21:03


If the GGSN supports a routing protocol, I would activate it with the router and use either RRI or a routing protocol inside the tunnel as well to learn the remote subnets.

Try also to look if the GGSN doesn't have any keepalive mechanism at the application level that could help in this end-2-end failure detection.



ptrigueira Thu, 03/11/2010 - 07:21

Salut Laurent,

Well, that would be a solution, but ggsn doesn't support OSPF per instance or per vrf. We need this setup because of overlapping issues... our clients can use any IP POOL they want....

Aplication level keepalive ..uhm... i'll investigate that ... maybe it could be a solution...




This Discussion