Problems with ospf routing updates

[keesepema]

Hi all,

I'm having a hard time in Packet Tracer with ospf routing.

My network consists of 5 routers. There is one ISP router configured with ip address 209.165.201.2.

All other routers are part of ospf process id 1.

To enable ospf routing, I only added the networks that were directly connected to the specific router.

For example my R1 routes:

(config)router ospf 1
router-id 9.9.9.9 # (It will be the DR, other router-id's are 1.1.0.0, 1.1.1.1, 6.6.6.6)
R1 is connected via s0/0/0 to network 172.16.10.0 0.0.0.3 area 0 and
R1 is connected via s0/0/1 to network 172.16.10.8 0.0.0.3 area 0 and
R1 is connected via subinterface G0/1.10 to network 192.168.10.0 0.0.0.255 area 0 and
R1 is connected via subinterface G0/1.20 to network 192.168.20.0 0.0.0.255 area 0

When I try to debug a -failing- traceroute to the ISP router on 209.165.201.2, the packet information in simulation mode on R1 tells me "...The routing table does not have a route to the destination IP address. The device drops the packet."

And that puzzles me...

If I issue show ip route on R1, the route to the network is shown as below:

209.165.201.0/24 is variably subnetted, 2 subnets, 2 masks

As you can see, there is no "O" character preceeding the information, so the network is not provided by ospf.

But I entered the route in ospf as "router ospf 1; network 209.165.201.0 0.0.0.255 area 0"

I want all routes to be handled by ospf.

The only static route I provided was a route to the ISP network and the internet. (ip route 0.0.0.0 0.0.0.0 )

To force updates, I regularly issued a "clear ip ospf process (yes)" commend.

It seems that routing updates are not exchanged in my ospf setup, so packets aimed for the internet, can't leave the border router.

So my question is: what can I do to make the ospf advertise routes succesful?

Thanks in advance,

Kees Epema

[Georg Pauwen]

Hello,

post the zipped Packet Tracer project (.pkt) file...

[keesepema]

Below is the zip file. Thanks!

[Georg Pauwen · Accepted solution]

Hello,

the route for 209.165.201.0/24 will never show up as an 'O' route, because it is directly connected.

R1#sh ip route 209.165.201.2
Routing entry for 209.165.201.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet0/0
Route metric is 0, traffic share count is 1

Your ISP needs a default route towards R1. Typically, R1 would have a default route towards the ISP, and then, under the OSPF routing process, have 'default-information originate' confgured, so the default route gets redistributed to all other OSPF routers.

I have made the above mentioned changes to your file (file attached, saved in PT version 8).

[keesepema]

Wonderful!

Connection from all pc's to the ISP server is now possible!

So I guess the only thing I had to change was entering a default route on R1 and way back to the ISP router?

Thanks very much for your help!

[Georg Pauwen]

Hello,

the default route was needed indeed, as well as the 'default-information  originate' on R1...

[paul driver]

Hello

---

@Georg Pauwen wrote:

Hello,

the default route was needed indeed, as well as the 'default-information  originate' on R1...

---

Apologies @Georg Pauwen  the above statement is not correct

In this topology the isp rtr requires probably to advertise its connected interface for SERVER-PT but it does NOT require a static default pointing towards R1 neither does R1 require a static default route towards the isp this will incur a routing loop.

A more viable approach would be for ISP advertise its connect interfaces and also advertise default-information originate always into ospf but NOT have any static default route towards R1

R1 will receive the advertised ospf default from ISP rtr and propagate that throughout the ospf domain, this rtr again does not require any static default route however I am not sure PT will support such configuration.

[Georg Pauwen]

Hello,

the ISP does not run OSPF, so I am not sure what you are referring to. I have actually never seen an ISP that DOES run OSPF with a customer network...

[paul driver]

Hello

---

@Georg Pauwen wrote:

Hello,

the ISP does not run OSPF, so I am not sure what you are referring to. I have actually never seen an ISP that DOES run OSPF with a customer network...

---

TBH I don't know of any ISP that has a static default routing into a LAN either, but that's irrelevant, What I am getting at is that you have two static default routes pointing each other between directly connect rtrs and that defiantly not viable.

In the OP topology the "ISP" rtr only has two connected interfaces ( one towards "LAN" and the other towards a single server) so it really isn't an ISP its just a rtr called "ISP"s

So to make a viable routing connection I suggested to introduce ospf to the ISP rtr so it would receive all internal lan subnets and at the same time advertise a default route ( even this isn’t required as the ISP has nowhere to route onwards to) and its connected interfaces., And negated the potential routing loop by removing both default static routes from both (ISP rtr-RTR1) that were directly connected.
However as stated given the restriction on PT I doubt this even would work or even be able to apply, something I cannot validate at this present time.

[Georg Pauwen]

I don't want to argue just for the sake of arguing, but when a routet is called ISP, that is usually for a reason. OP might as well configure specific static routes for all customer networks, but since this is a closed environment, what is the point ? And with regard to MPLS and OSPF, isn't that typically used for L3VPN environments ? Either way, Packet Tracer does not support MPLS, so that is most likely not a part of the lab requirements...

[paul driver]

Hello
No argument here just a discussion but I do think you’re going off track.

I initially highlighted that in a provided solution it shown two directly connected rtrs pointing default static routes to each other which is not viable for obvious reasons, However if you believe it is and the OP is happy with that solution so be it, I just wanted to make sure you were both aware of the problems that can arise in having such routing in place.

Lastly MPLS has nothing to do with it, I only mentioned this in response to yourself stating you've never seen an ISP peering with a customer using OSPF also for OP stating it would be unusual for a customer to peer with an ISP via OSPF.

[keesepema]

Hello George,

You are right, it would be kind of problematic if all customer connections would end up with ospf elections I think.

The static route to the ISP network is in my opnion the right way to solve connectivity to the outside world not ospf.

[paul driver]

Hello 

---

@keesepema wrote:

it would be kind of problematic if all customer connections would end up with ospf elections I think.

FYI, when large customers have ISP mpls based service, its not uncommon for their own CE rtr to peer to a ISP PE rtr via an IGP such as ospf.