From: darbyweaver@yahoo.com
Date: Thu May 18 2006 - 22:50:37 ART
Hey,
This is a belated answer to the question that Gustavo has asked. However,
If you read the thread long enough you get to the point:
Basically, Gustavo wants to form adjancy with OSPF over a Frame Circuit. Many options are removed. Thus, we have to read into the question a bit deeper:
So what this really looks like is this:
Hub and Spoke Frame Network - Hub has multipoint sub-interfaces and the 2 spokes have physical interfaces.
He is not allowed to use Neigbor Commands on the spokes (R1 and R2).
He is not allowed to use "ip ospf priority 0".
He is not allowed to use: "ip ospf network *" (from what I gather).
"The issue is that they are not allowing me to change anything at
interface level on the spokes."
"I'm thinking that this is one of the "tricky" IGP questions."
Basically, my solution to the problem would be to manipulate the router-id to the highest possible 32-bit value or 255.255.255.255 on the hub.
This would allow the hub to become the DR and would allow adjanceny to form.
One of the people who responded to Gustave mentions this as well.
A classic case in point. The lab appears close to one of the vendor labs but is "self-described" as a "tricky" question.
And a time-waster for the unitiated.
One fine example of my point. Clearly an interpretation issue here...
:)
=============================================================================
I'm wondering if and how this exercise is doable.
I'd like to have your opinion.
Hub and spoke network. Hub (R5) has a multipoint Serial subinterface.
Both spokes use their main interface.
We cannot use any neighbour commands nor any interface level commands on
R1 and R2 (spokes).
We are to configure OSPF on this frame-relay network.
If we were to configure Non-broadcast network, we would need at least to
configure neighbour on hub, and ip ospf priority 0 on the spoke
interfaces----> failing restrictions.
If we were to configure any point-to-point or point-to-multipoint
command that would make us configure network type on the ospf interface,
we would fail the restriction.
If we were to configure broadcast network on hub and change timers on
hub in order to match the spoke timers... It would not establish
adjacency, besides the fact that we would have to use neighbour
commands...
Unless I use tunnelling or ppp over FR I really do not see how to
accomplish this.
Are there any suggestions?
Have you tried point-to-multipoint non-broadcast? See if you establish adjacency after that...I think the key here is that you are using physical interfaces and you cannot adjust anything on the spokes. PTMP-NB should do the trick unless there's something I'm missing here.
Can't you use the non-broadcast and set the priority higher on the hub to
make it highly likely to be the DR?
The issue is that they are not allowing me to change anything at
interface level on the spokes. So, to change from NBMA to p2MP(-NB) I
would need to do that. (I will not try P2MP-NB, because you need to
specify neighbors, which I can't)
If you are suggesting to put P2MP on Hub and let spokes on NBMA, I am in
process of trying it.
For what I can see the adjacency is established, but there is no route
exchange.
I'm still at a dead end :(
How about setting the net type to non-broadcast on the hub and giving it a
239.x.x.x or highest possible router-id ?
Sounds like a tunnel to me, but without labbing it up and testing it,
can not say. I am in the middle of labbing something else up and will
see if I can throw some opsf over the frame and get it to work with the
restrictions you are saying...
Hub is MP interface
Spokes are Physical
No Neighbor No ip ospf network commands
I will let you know if I come up with anything, but my gut is saying
tunnel
Yep, my gut too.
Just one correction to what you said.
No neighbor command, but only on the spokes you cannot do interface
level commands.
solution guide shows neighbor statements and PTMP-NB for the solution
By default point-to-multipoint subif's are already non-broadcast and
coincidently the hub router's id is higher than the spokes. The problem
is that you need to elect a BDR also, unless you set the spoke's
priority to 0, which you cannot do because it would mean setting an
interface level command (ip ospf priority 0)
I'm sorry, I didn't say that the IEWB version was 3.0
That is in solution for 2.0 version. But as you can easily see they are
using neighbour commands and interface-level commands, also.
I'm thinking that this is one of the "tricky" IGP questions
Ok, doing an ip ospf net point-to-multipoint on the hub gets the
nieghbors to come up, changed the ip ospf priorty on the spokes to 0 and
that made the hub the DR. Not seeing routes go across though, wich is a
concern....
So that does not work...
On the hub, I am allowed to change the network type...so I change that
to broadcast. I then change the timers on the hub to match hellos @ 30
and dead at 120...
All works, up and up , neighbors copmplete and I can ping a loop back
interface of one spoke from the other.
Does this break any rules?
Only the fact that you have ip ospf priority 0 on the spokes. Which is
an interface level command, and breaks the rules.
Other by that you are fine... (but no points for the section :(( )
So why do you NEED to put priority 0 on the spokes?
Put a higher priority on the hub to make sure it'll be the DR. In a
hub-spoke network, we always want to see the hub as the DR and it makes life
easier if the spokes are all priority 0 but realistically if the hub is out
of the picture, nobody can talk to anyone anyway.
Broadcast network type would seem to be the available solution given all the
things you weren't allowed to do.
Disclaimer: I haven't seen the lab here at all, so I'm merely reading parts
of the discussion here!
The solution is to set the network type to broadcast on R5 (the
hub) and change its hello and dead timers to match that of the
non-broadcast network type of R1 and R2. You don't need to adjust the
priority values at all since R5 already has the higher router ID. Look
back in the solutions guide of lab 1 or 2 (not sure which) and look the
explanation of the network types. The network types don't have to match
they just have to be compatible.
Ok, I assume that life will be easier with ip ospf priority 0, but then
we will have a BDR just lying there, but then again, no problem.
I repeated the test of HUB broadcast and spoke NBMA, and whole damn
thing came up! Adj, routes etc... and fulfilling the restrictions.
(It's like when you have a problem... you call the technician (Scott,
Brian) and the problem goes away)
I have not seen this lab either, but couldn't we also set the hub router-id to
the highest value to insure it provide further assurance that it is the DR
(set at 255.255.255.255)? Just a thought.
You can't set at:
255.255.255.255
0.0.0.0
0.0.0.1
Other than those you should be fine.
Are we sure on that one....I have it set on the config below and everything is
working nicely. I thought that the router-id is not really an IP address
anyway.....
R1......
router ospf 1
router-id 255.255.255.255
log-adjacency-changes
network 172.16.123.0 0.0.0.255 area 0
neighbor 172.16.123.2
neighbor 172.16.123.3
!
R1#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/DROTHER 00:01:34 172.16.123.2
Serial0/0.123
172.16.30.3 0 FULL/DROTHER 00:01:53 172.16.123.3
Serial0/0.123
R1#
at the remotes.....
R2#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
255.255.255.255 1 FULL/DR 00:01:40 172.16.123.1 Serial0
R2#
Any reason why this works with the router-id of 255.255.255.255?
Dave
Mmmm... No, just something I'd read someplace on Cisco docs and believed
it! Many things don't like "all 1's or all 0's" :)
The 0.0.0.0 is in the spec, since it's reserved for indicating either no
need for DR or one not elected yet. The other two I just always believed
from long, long ago! :)
Besides, all you'd need to do is set the router-id to 224.0.0.0 and it would
be higher than anything the other routers would have as IP addresses ever.
Scott
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:21 ART