Options

OSPF, route tags and default-information originate

trackittrackit Member Posts: 224
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.

Comments

  • Options
    networker050184networker050184 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.
  • Options
    DPGDPG 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.
  • Options
    trackittrackit 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...
  • Options
    networker050184networker050184 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.
  • Options
    trackittrackit 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.
  • Options
    networker050184networker050184 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.
  • Options
    trackittrackit Member Posts: 224
    ok, thanks for clarification!
  • Options
    networker050184networker050184 Mod Posts: 11,962 Mod
    trackit wrote: »
    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.
  • Options
    trackittrackit 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...
  • Options
    trackittrackit 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.
Sign In or Register to comment.