- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
03-12-2014 11:39 AM
I'm having some problems getting our traffic engineering working with OSPF, and I think I've finally figured out what's happening. But I can't figure out how to stop it.
I think the problem is coming from how the PAN firewalls are importing the external static routes into the area. Here is a "dumplsdb" snippet for one such network,
3 0.0.0.1 10.33.151.86 10.89.4.0/22 type-7 (NSSA Ext) 0x800002FB 0x0000825D 559 36
Options: [NSSA]
Mask 255.255.252.0, type 1, tos 0 metric: 1, forward 10.56.1.22, tag 0.0.0.0
Note that "forward 10.56.1.22" field. I think that's what's messing us up. I don't think that needs to be there, i.e. it should be 0.0.0.0.
That address is on an interface of the advertising router (a PAN firewall at 5.0.11). When other routers calculate the cost to that 10.89.4.0/22 network, they calculate the cost to reach 10.33.151.86, add the metric on external route, 1, and then also add the cost of reaching the network where 10.56.1.22 resides (even though it's an address on the ASBR itself). Adding that last network is wrong, and it's messing things up. It causes OSPF to choose a non-optimal path to that external network.
But I can't figure out why the PAN is adding anything to the "forward" field and cannot figure out how to clear it. I have an open ticket on this, but was hoping maybe someone in the community might be able to answer more quickly.
Thanks.
03-14-2014 04:01 PM
It is normal behavior for an OSPF router with an interface into a NSSA area to take the type-7 LSAs it learns from that area and convert it into a type-5 LSA before flooding it to other areas. When it converts the LSA from type-7 to type-5, it basically makes itself appear as the ASBR for other OSPF speakers in the attached areas. This is why you see the firewall interface IP as the "forward" address for this route.
Regarding the cost of the route, it is also normal OSPF behavior for the cost of a type-1 external route to be the cost of the route plus the sum of the costs to reach the ASBR (your firewall, in this case). If you don't want the other routers to consider the cost to the ASBR in the route selection process, then you can change the way this route is injected into your NSSA from a type-1 external to a type-2 external.
Hope this helps.
-C
03-18-2014 03:06 PM
The firewall/router in question is not an ABR between two areas. It is only in a single area. It is an ASBR. The external routes it is bringing into OSPF are static routes configured on itself. It is listing itself as the forwarder.
Section 2.3 of RFC2328 discusses what the forwarding field is used for,
"...the OSPF protocol allows an AS boundary router to specify a "forwarding address" in its AS-external-LSAs. [The ASBR] would specify [the other router's] IP address as the "forwarding address" for all those destinations whose packets should be routed directly to [the other router]."
There is no other router in this case. The ASBR itself is the correct next hop for the traffic. It also doesn't seem to make sense for a router to specify itself as the forwarder. The field should be zeroed if the ASBR itself is the next best hop.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!