[c-nsp] Remote Access to MPLS - neverending story

[piestaga]

Hi,

as always the lab config worked perfect the commercial one does not want to.
I followed exactly the guidelines available on cco, nevertheless I can 
not find the explanation for such behaviour.

I have run the remote access to mpls service which uses VRF aware IPSec 
feature including FVRF and IVFR capability.

The whole IPSec traffic before it gets the IPSec aggregator (Cisco 7206) 
it goes through the additional QoS router (also Cisco7206) which 
implicates the per customer VLAN betwen QoS and IPSec agregator.
That part is to implement the bandwidth management per customer basis on 
rate-limit.

At IPSsec aggregator site, the VLAN enpoint is terminated directly 
within the VRF which in this case acts as FVRF. There is also (and only) 
a default routing entry that is set to VLAN endpoint ip address (at QoS 
router side).

At the same time the ISAKMP profile configuration using the 'vrf' 
command indicate the IVRF, where the IPSec session should be finaly 
terminated.
And untill that moment everything works perfect. The IPSec session is 
correctly authenticated and the customer is remotely connected to its VPN.
My problem is with the routing.


The     'show ip route vrf  ivrf-name'     shows that there is a static 
entry created by the session

 >>         S      172.16.10.10    via 195.xxx.xxx.62     <<

where:   172.16.10.10   is the inner addres assigned from customer pool
             195.xxx.xxx.62 is the outter addres that indicates the real 
IP that the customer session comes from

detailed viev shows:

 >>     Routing entry for 172.16.10.10/32
          Known via "static", distance 1, metric 0
          Redistributing via bgp 12xxx
          Advertised by bgp 12xxx
          Routing Descriptor Blocks:
          * 195.xxx.xxx.62
              Route metric is 0, traffic share count is 1    <<

whereas the command      'show ip cef vrf ivrf-name 172.16.10.10'   shows:

 >>   172.16.10.10/32, version 2287, epoch 0, cached adjacency 81.xxx.xxx.65
        0 packets, 0 bytes
          tag information set
            local tag: 814
            fast tag rewrite with Gi0/2.100, 81.xxx.xxx.65, tags 
imposed: {223 1014}
          via 195.xxx.xxx.62, 0 dependencies, recursive
            next hop 81.xxx.xxx.65, GigabitEthernet0/2.100 via 0.0.0.0/0
            valid cached adjacency
            tag rewrite with Gi0/2.100, 81.xxx.xxx.65, tags imposed: 
{223 1014}   <<

where:      81.xxx.xxx.65   is the routing known as default within VPN 
routing lerned by bgp.


and the behaviour is, that despite the fact that the session is 
established, the customer is not able to contact any address within its VPN.
There is a default routing within the IFRV (independent customer 
requirement) and it looks like the cef is not able to find route to 
195.xxx.xxx.62 and it tries to send the traffic to default entry that it 
finds within the VRF.

I realy do not know why the cef instead of looking for the route to 
195.xxx.xxx.62 in the area it learned the route from (I mean from 
additional VRF = FVRF which I mentioned earlier) and it prefers to 
choose the default.

The case is that the session is not forwarding any communication within 
the IPSec 'tunnel' despite the fact the IPSec session itself is still 
established.

Could you please verify if you have any solution for that case.
I would appreciate any help

Regards
Piestaga