If I understand correctly what you are trying to do, then I think there is a problem with your route-map. I am not sure what the meaning of "match ip next-hop" is in the context of the "default-information originate" command. I think you need to use "match ip address" instead to specify the route whose existence causes the default to be originated (i.e. if 22.214.171.124/prefix_length exists in routing table, originate default).
It's good to hear you made this work and thank you for your feedback. I am still interested on why the standard ACL did not work. What prefix-length did you use for the prefix list entry? I think the standard ACL was looking for a match on the specific route 126.96.36.199/32.
ip address 188.8.131.52/28 and the default route points to the 184.108.40.206 (the ISP router)
I started with this idea: since the next hop must be 220.127.116.11, use the match ip next hop in the route-map, and then in the standard access list i will state which default gateway use.
In EIGRP environment my configuration was working: redistribute static route-map DEFAULT-ROUTE causes the router to advertize only one route, flagged as EX.
In OSPF i see the things work differently, at least for the route-map.
I've then configured a ip prefix list like this:
ip prefix list 18.104.22.168/28
and then applied the route-map DEFAULT-ROUTE with a match ip address statement, like described in the page.
Anyway i will try to investigate a bit more working on the actual configuration: changing the statement in the route-map (match ip next hop and match ip address) and also using a standard access list rather than a prefix list. I am really curious to realize where is the trick
You could try a "permit 22.214.171.124 0.0.0.15" in the standard ACL. I think the trick has to do with the route mask. However, have in mind that the existence of the /28 route in the routing table does not necessarily mean that the gateway 126.96.36.199 is up and running. If for example the default originator connects to the gateway via an ethernet switch, the interface 188.8.131.52 of the gateway could go down, but default originator's interface in 184.108.40.206/28 is up and has connected route in its routing table. In such a case, you could try to use a route that would more accurately signal to the default originator that 220.127.116.11 is down, some route that would only be known if the path to the gateway is up.
I agree on the fact that a "permit host 18.104.22.168" in the std ACL would have been better, and this maybe can be the mistake.
About the reachability of the default gateway, the router is directly linked to the other side, so if it goes down, the interface (ethernet) goes down, and then the route is removed from the routing table.
Said this, in a different scenario it can happen the ISP router is up but not forwarding traffic, so my router advertize a valid network and the traffic, once reaches ISP is dropped.
This is however the problem when dealing with static routes..
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...