OSPF, route tags and default-information originate
Hi!
I am quite confused. Can somebody explain to me the behaviour of "default-information originate" command in OSPF proccess when its is used in conjunction with route tags as so:
router ospf 1
default-information originate route-map redist_default
route-map redist_default permit 10
set tag 20
I wan under impression that this configuration will result in following: IF default route is present in routing table then it will redistribute it into OSPF and tag it with route tag 20. But it actually behaves quite differently. It generates tagged default route regardless if default route is actually present or not.
I am quite confused. Can somebody explain to me the behaviour of "default-information originate" command in OSPF proccess when its is used in conjunction with route tags as so:
router ospf 1
default-information originate route-map redist_default
route-map redist_default permit 10
set tag 20
I wan under impression that this configuration will result in following: IF default route is present in routing table then it will redistribute it into OSPF and tag it with route tag 20. But it actually behaves quite differently. It generates tagged default route regardless if default route is actually present or not.
Comments
-
networker050184
Mod Posts: 11,962 Mod
I haven't labbed this out so take this with a gain of salt, but this is what I assume is happening.
The route-map is used for conditional default advertisement. Since there is no match statement and just a permit you are meeting the condition to advertise the route and it is therefore generated and the set action is performed.An expert is a man who has made all the mistakes which can be made. -
DPG
Member Posts: 780 ■■■■■□□□□□
Your route-map is only setting a tag. You should have a prefix-list that it is matching as well if you are trying to inject a conditional default route. -
trackit
Member Posts: 224
you mean like:
access-list 1 permit 0.0.0.0 0.0.0.0
route-map redist_default permit 10
match ip address 1
set tag 20
I will try it out... -
networker050184
Mod Posts: 11,962 Mod
Well, that kind of defeats the whole purpose of a conditional advertisement. That's the same logic as not using a route-map at all.
Conditional is to make sure a condition is met. So say for example you want to only advertise a default if your uplink to an external gateway is up. You could create a prefix-list to match that subnet and use that in your route-map. That way the default is only generated when that interface is up (which means there will be a connected route in the routing table). Think of it as an if then logic.An expert is a man who has made all the mistakes which can be made. -
trackit
Member Posts: 224
I was under impression that route-map sets limitations on what predixes are actually advertised, not what conditions need to be met in order for some other prefix to be advertised... Am i totally off here? Or does "default-information originate" have some special behaviour and route-map just tells what route needs to be present in the RIB in order for default to be generated?
If that is the case, then how can i get the usual "default-information originate" behaiviour wih just tagging. -
networker050184
Mod Posts: 11,962 Mod
Yes you are totally off here. Route-maps can be used for a variety of reasons. In this scenario it is for meeting a condition not for filtering prefixes.An expert is a man who has made all the mistakes which can be made.
-
networker050184
Mod Posts: 11,962 Mod
If that is the case, then how can i get the usual "default-information originate" behaiviour wih just tagging.
Good question. In this case I would assume what you mentioned above would work for that though I haven't tried it. Redistribution with a route-map is another thought that comes to mind.An expert is a man who has made all the mistakes which can be made. -
trackit
Member Posts: 224
I have some more questions
I see that when i use "default-information originate" command under OSPF, then the default route that is generated gets a tag of 1. I cant seem to find any documentation about this auto-tagging behaviour. Can someone elaborate on that? Why does this route get tagged and is this documented somewhere?
>>>>>>>>>>>>>>>>>>>>>>>>>
LS age: 1808
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000001
Checksum: 0xFEAB
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 1
>>>>>>>>>>>>>>>>>>>>>>>>>
And also, if i have another router that has "distribute-list" applied under OSPF to block a route with tag 50 as so:
!
router ospf 1
distribute-list route-map block_50 in
!
!
route-map block_50 deny 10
match tag 50
route-map block_50 permit 20
then this default route that is generated by another router does not get installed... why is that? Why does this route-map block anything else other than a route with tag 50? And this seems to be true only for this default route, other external routes with some other tags get through with no problem.
EDIT: After some testing it seems that the tag that router automatically assigns to its OSPF generated default route is actually its OSPF process id. But still i cant seem to find any documentation about this... -
trackit
Member Posts: 224
Ok, i messed in my "lab" some more...
1) Yes, "default-information originate" tags the generated default route with its OSPF process id number. If anyone has any information why is this done then i would appreciate that...
2) The second issue i had with the filtering based on a tag: I found out that it seems to be not possible to filter a route for same destination (for exmaple default route) based on tag. For example, lets take simple case with 3 routers: R7 that is connected to R8 and R9. Both R8 and R9 redistribute route for 192.168.89.0/24 network and tag it with 8 and 9 respectivly. R7 receivs the routes as expected and in OSPF database we can see both LSA-s.
Link ID ADV Router Age Seq# Checksum Tag
192.168.89.0 8.8.8.8 459 0x80000002 0x00FCB7 8
192.168.89.0 9.9.9.9 424 0x80000002 0x00F0BE 9
in the routing table both routes show up too, but only wth the tag 9:
R7#show ip route 192.168.89.0
Routing entry for 192.168.89.0/24
Known via "ospf 1", distance 110, metric 20
Tag 9, type extern 2, forward metric 1
Last update from 192.168.78.8 on FastEthernet0/0, 00:06:00 ago
Routing Descriptor Blocks:
* 192.168.79.9, from 9.9.9.9, 00:06:00 ago, via FastEthernet0/1
Route metric is 20, traffic share count is 1
Route tag 9
192.168.78.8, from 8.8.8.8, 00:06:00 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1
Route tag 9
Why tag 9 and not 8? I dont know, but in my limited tests it seems to pick the higher number, but i might be wrong on that of course.
And because those two routes get the same tag, its not possible to filter one out (based on a tag).
If i create a route-map that attempts to block a route to R8 (match tag 8 ) and apply distribute-list under ospf then nothing happens and if i block a route with tag 9 then both routes get filtered out.
The solution that seems to work is to create a route-map that maches originating routers router-id (match ip route-source ...) and filter based on that.
And one thing else i found out. If i use default-information originate command with a route-map like so:
ip prefix-list default_route seq 5 permit 0.0.0.0/0
route-map redist_default permit 10
match ip address prefix-list default_route
match source-protocol static
set tag 40
router ospf 1
default-information originate route-map redist_default
then "match source-protocol static" has no effect, default route gets injected no matter what source it comes from... so if it learns it from OSPF it will "reinject" it back into OSPF.
