This is a follow-up question based on this original question.

The following topology is present:


The Cisco ASA is our Internet firewall, as well as VPN gateway, terminating VPN connections. The ASA performs RRI, to add those VPN routes into the OSPF domain. Both the ASA and the MLS are in OSPF Process 2 Area 0, and exchange routes. The OSPF setup is correct.

The default behaviour of RRI is to set the next-hop of the generated static route to the default gateway of the ASA interface where the crypto map is applied (which is outside in our case). In our case, it is xx.xx.192.21, which is the interface of the MLS. Hence, the route on the ASA looks like this:

S xx.xx.202.13 [1/0] via xx.xx.192.21, outside

Those routes are redistributed into OSPF via the redistribute static command in router ospf 2.

At the MLS however, the routes are in database, but not in the routing table. The Type 5 LSA looks like this:

  Routing Bit Set on this LSA
  LS age: 1887
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: xx.xx.202.5 (External Network Number )
  Advertising Router: xx.xx.192.20
  LS Seq Number: 80000001
  Checksum: 0x8147
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: xx.xx.192.21
        External Route Tag: 0

Hence, the ASA sets the Forward Address to the next hop of the outside interface. According to Cisco Documentation, a non-zero forwarding address is set, if the following conditions are met:

OSPF is enabled on the ASBR’s next hop interface AND ASBR’s next hop interface is non-passive under OSPF AND ASBR’s next hop interface is not point-to-point AND ASBR’s next hop interface is not point-to-multipoint AND ASBR’s next hop interface address falls under the network range specified in the router ospf command.

As we need the ASA and the MLS to participate in OSPF routing, we cannot prohibit the ASA to set the forward address, if I understand that correctly.

The MLS however does not install the LSA into the routing table, as the forward address is not an OSPF O or O IA route, it is its own interface.

Configuration of the ASA

 router ospf 2
  ! External Routing Process
  router-id xx.xx.192.20
  network xx.xx.192.0 area 0
  area 0 authentication message-digest
  redistribute static subnets route-map STATIC->OSPF2

 route-map STATIC->OSPF2 permit 10
  match ip address prefix-list STATIC->OSPF2

 ! Both prefixes are used in the VPN pools
 prefix-list STATIC->OSPF2 seq 5 permit xx.xx.202.0/24 ge 32
 prefix-list STATIC->OSPF2 seq 15 permit xx.xx.37.0/24 ge 32

 crypto dynamic-map VPN-dynamic 10 set reverse-route
 crypto map VPN 111 ipsec-isakmp dynamic VPN-dynamic
 crypto map VPN interface outside

So the question now is: How can the situation be solved to allow the MLS to add the routes into the routing table?

  • What does your RRI and Redstribution configuration look like on the ASA? Would it be possible to use a little PBR to modify the static route created by RRI? – Robert Mar 10 '15 at 20:17
  • @Robert: sorry for my late reply, I have added the relevant path of the ASA configuration to the question. – waza-ari Mar 16 '15 at 14:06
  • ASA points to MLS, then somehow MLS should know how to deal with 202.13 on its own without MLS getting any hint from ASA. Make sense? – user1602017 Jun 27 at 21:14

At the risk of another down-voted answer because I can't comment I'm going to propose a possible solution.

The Problem:
The forwarding address of the Type5 LSA is non-zero. According to the Cisco docs and RFC2328:

If the forwarding address is non-zero, look up the forwarding address in the routing table.[24] The matching routing table entry must specify an intra-area or inter-area path; if no such path exists, do nothing with the LSA and consider the next in the list.


[24]When the forwarding address is non-zero, it should point to a router belonging to another Autonomous System.

I believe when it does that look-up and sees the next-hop address is a connected route it is skipping the LSA and not installing it into the route table. I think this is quite a literal interpretation; I would consider a connected route as intra-area. However since it is all a single area it is still flooding the LSA on to your external router, where it sees the LSA's next-hop as an OSPF route advertised by the MLS and therefore installs the LSA into the routing table.

According to your post and the Cisco doc:

These conditions set the forwarding address field to a non-zero address:
OSPF is enabled on the ASBR's next hop interface AND
ASBR's next hop interface is non-passive under OSPF AND
ASBR's next hop interface is not point-to-point AND
ASBR's next hop interface is not point-to-multipoint AND
ASBR's next hop interface address falls under the network range specified in the router ospf command.

Possible Solution:
So according to this information if the ospf network type is set to point-to-point between the ASA the MLS then the LSA's next-hop should be set to zero. This could be checked beforehand by show ip ospf interface; it is probably at broadcast currently.

On both devices you would need to set the interface OSPF network type to point-to-point and also statically define the neighbor under the OSPF config.

You should then see the Type5 LSA next-hop address set to zero and

If the forwarding address is set to, packets should be sent to the ASBR itself.

| improve this answer | |
  • Hi Robert, thank you for your answer. As the possible solution will be distruptive, I cannot test this in live environment. I will build the topology in our lab and post the result. – waza-ari Mar 17 '15 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.