That seems just as strange as what I am running into.
I am almost certain my issue has something to do with the Multilink
connections. Every debug I run shows matching costs. Even the debug I sent
eariler shows the same costs as when Multilink 1 took over when R6 went down.
I also simplified it. I got rid of the virtual link and move the 5.5.5.5
address into area 0.0.37.128. I also remove all redistribution. Here is what
you see with both Multilinks up and running:
Routing entry for 5.5.5.5/32
Known via "ospf 1", distance 110, metric 1191, type intra area
Last update from 143.43.65.5 on Multilink2, 00:00:05 ago
Routing Descriptor Blocks:
* 143.43.65.5, from 5.5.5.5, 00:00:05 ago, via Multilink2
Route metric is 1191, traffic share count is 1
Below is what it looks like on R2 when R6 is down
Routing entry for 5.5.5.5/32
Known via "ospf 1", distance 110, metric 1191, type intra area
Last update from 143.43.65.5 on Multilink1, 00:00:05 ago
Routing Descriptor Blocks:
* 143.43.65.5, from 5.5.5.5, 00:00:05 ago, via Multilink1
Route metric is 1191, traffic share count is 1
Routing entry for 143.43.65.5/32
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Multilink1
Route metric is 0, traffic share count is 1
Now I bring it back up and you see it returns
R2(config-if)#do sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "ospf 1", distance 110, metric 1191, type intra area
Last update from 143.43.65.5 on Multilink2, 00:00:22 ago
Routing Descriptor Blocks:
* 143.43.65.5, from 5.5.5.5, 00:00:22 ago, via Multilink2
Route metric is 1191, traffic share count is 1
R2(config-if)#
R2(config-if)#do sh ip route 143.43.65.5
Routing entry for 143.43.65.5/32
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Multilink1
Route metric is 0, traffic share count is 1
The router know 143.43.65.5 is on Multilink 1 but it keeps picking Multilink
to for other routes. There is nothink that directly connects these two. I
just looked through both routers from beinging to end and checked every frame
PVC to make sure there was nothing up that would link R5 and R6 directly.
Thanks for all of the help.
________________________________
From: ALL From_NJ [mailto:all.from.nj_at_gmail.com]
Sent: Tue 9/22/2009 10:50 PM
To: Rob Phillips
Subject: Re: OSPF Multilink routing issue
I did a quick lab test, not exactly the same. Here is what I did. 2 routers
configured, but several others existing in the network.
R3 w/ area 0 and area 1
R4 peers with R1 via area 1
R4 has an area 2 off of it. I configured a virtual link between R3 and R4,
and all is well in the rest of the network.
The virtual link assume the cost of the link plus 1. In my case I manually
set the cost to be 1000 and so the virtual link shows a cost of 1001.
When I perform a show ip route 4.4.4.4 from R3, it shows me a cost of 1001 and
this route is preferred.
Makes sense so far.
I then created a tunnel interface on both routers and configure OSPF for area
2. The auto generated cost for this is 11112. Clearly the earlier mentioned
path learned via the virtual link would be preferred.
Nope. The tunnel is preferred.
I cannot find the documentation to prove this (anyone?), however it appears
that a physical interface will always be preferred over via virtual link.
If I shut down the tunnel, the route is re-learned via the virtual link and
this becomes the preferred path.
In your case, my guess is that something similar is happening. As you can
see, the cost is better to go directly to R5, yet, the R2 still chooses the
path through R6. Does R2 have some sort of connectivity to R5's network
through R6?
HTH,
Andrew
PS - I still do not understand your topology and the other DLCIs / interfaces
... ;-) ... but no worries, I am learning from your routing issue. Thanks.
On Tue, Sep 22, 2009 at 10:48 PM, Rob Phillips <rrphillips_at_swankav.com>
wrote:
Thanks for the info. It has given me a few more ideas at things to look at.
Here are the answers to your questions so hopefully I can explain my setup
better.
Area 0 like I said is on loopback 1 on R2. R2, R5 and R6's Multilink Frame
relay is within area 0.0.37.128. Now the 5.5.5.5 address is on a loopback on
R5 and that loop back is in area 51. As such I need the virtual link to brink
both the Area 51 and also another area 50 is also on R5 into OSPF.
R2 is doing redistribution between both OSPF and EIGRP and just happens to be
the most central router of all of them within my layout.
The hard part is that 5.5.5.5 is just 1 hope away from R2. I event tested by
putting the 5.5.5.5 into area 0.0.37.128 as well but have the exact same
result.
The quick test I have done several times. If I shut down R6's serial
interface that links R6 to R2 then R2 starts routing correctly. As soon as I
re-enable it it switches back to wanting to use Multilink 2.
I have tried to figure out why it thinks it is the best path by every means I
can. I was ip routing debugs, ip os packet debugs, Ip os rib debug. Here is
the debug ip os SPF which shows it wanting to pick Multilink 2 as a better
path.
*Sep 22 19:40:44.195: %LINK-3-UPDOWN: Interface Multilink2, changed state to
down
*Sep 22 19:40:44.207: %LINK-3-UPDOWN: Interface Multilink2, changed state to
up
R2(config-if)#
*Sep 22 19:40:44.699: OSPF: Schedule SPF in area 0.0.37.128
Change in LS ID 2.2.2.2, LSA type R, spf-type Full
*Sep 22 19:40:44.699: OSPF: Schedule SPF in area 0
Change in LS ID 2.2.2.2, LSA type R, spf-type Full
R2(config-if)#
*Sep 22 19:40:45.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access6, changed state to down
*Sep 22 19:40:45.207: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Multilink2, changed state to up
R2(config-if)#
*Sep 22 19:40:47.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access6, changed state to up
R2(config-if)#
*Sep 22 19:40:49.027: OSPF: Detect change in LSA type 1, LSID 6.6.6.6, from
6.6.6.6 area 0.0.37.128
*Sep 22 19:40:49.027: OSPF: Schedule SPF in area 0.0.37.128
Change in LS ID 6.6.6.6, LSA type R, spf-type Full
*Sep 22 19:40:49.027: %OSPF-5-ADJCHG: Process 1, Nbr 6.6.6.6 on Multilink2
from LOADING to FULL, Loading Done
*Sep 22 19:40:49.699: OSPF: running SPF for area 0.0.37.128, SPF-type Full
*Sep 22 19:40:49.699: OSPF: Initializing to run spf
*Sep 22 19:40:49.699: OSPF - spf_intra() - rebuilding the tree
*Sep 22 19:40:49.699: It is a router LSA 2.2.2.2. Link Count 3. V-bit set
*Sep 22 19:40:49.699: Processing link 0, id 143.43.65.2, link data
255.255.255.255, type 3, cost 0
*Sep 22 19:40:49.699: OSPF: Add better path to LSA ID 143.43.65.2, gateway
143.43.65.2, dist 0
*Sep 22 19:40:49.699: OSPF: Add path: next-hop 143.43.65.2, interface
Multilink2
*Sep 22 19:40:49.699: Processing link 1, id 5.5.5.5, link data 143.43.65.2,
type 1, cost 1190
*Sep 22 19:40:4
R2(config-if)#9.699: OSPF: Add better path to LSA ID 5.5.5.5, gateway
143.43.65.5, dist 1190
*Sep 22 19:40:49.699: OSPF: putting LSA on the clist LSID 5.5.5.5, Type 1,
Adv Rtr. 5.5.5.5
*Sep 22 19:40:49.699: OSPF: Add path: next-hop 143.43.65.5, interface
Multilink2
________________________________
From: ALL From_NJ [mailto:all.from.nj_at_gmail.com]
Sent: Tue 9/22/2009 9:11 PM
To: Rob Phillips
Cc: ccielab_at_groupstudy.com
Subject: Re: OSPF Multilink routing issue
Not sure I fully understand your topology ... but on R2, OSPF thinks this is
an inter-area route that has been also been configured in EIGRP. Which router
is performing the redistribution for network 5.5.5.5?
I would start by looking at which router is originating this route into OSPF
and follow this through the network to see where it takes a suboptimal path.
Also, the metric is changing, so it must be a E1. To be honest, the outputs
you are including do not tell me much other than OSPF believes the route to R6
is the best route to take ...
BTW ... why do you have a virtual link configured between 2 and 5? Just
curious ... area 0 off of R2, and another area 0.0.37.128 is configured on
each router. Given what I see here, I do not know see why virtual links would
be configured.
A quick test is to shut down R6. Does the link to R5 become the preferred
path to the route - 5.5.5.5? If so, why did it now become the preferred path?
If after this test, OSPF still does not prefer the path directly to R5, then
it must think the updates from R5 are invalid and is rejecting these or it is
not getting any updates from R5 about network 5.5.5.5 ...
Sorry I cannot be more help ... perhaps another on this list has tried this
lab and knows what you are facing.
HTH,
Andrew Lee Lissitz
On Tue, Sep 22, 2009 at 8:49 PM, Rob Phillips <rrphillips_at_swankav.com>
wrote:
I have an issue that has been racking my brain and I just can not figure it
out.
I have 3 routers Using Multilink PPP. R6 ----- R2 ------ R5
When all links are up R2 believes any routes behind R5 are actually
reachable
through R6. The example below is a loopback on R5 (5.5.5.5). In all cases
it
knows that 143.43.65.5 is the next hop, however the router believes to get
to
143.43.65.5 is through Multilink 2 when it has to route. (aka pinging
143.43.65.5 works from R2, but every route in the routing table shows
143.43.65.5 via Multilink 2 when it should actually follow Multilink 1)
Area 0 is on a loopback on R2.
Any help would be great. I am pulling out the few hairs I have left on the
top of my head. I have tried every show command I and think of and even
started trying show commands I never heard off. Tried several different
debugs but nothing!
If I don't figure it out soon, my head may get so bare and shiney that
light
bouncing off of it may blind a proctor during my lab. How many points do
you
lose for that?
R2
interface Multilink1
ip address 143.43.65.2 255.255.255.0
ip ospf network point-to-multipoint
ip ospf hello-interval 10
ppp multilink
ppp multilink group 1
!
interface Multilink2
ip address 143.43.65.2 255.255.255.0
ip ospf network point-to-multipoint
ip ospf hello-interval 10
ppp multilink
ppp multilink group 2
interface Serial0/1/0
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 205 ppp Virtual-Template1
frame-relay interface-dlci 206 ppp Virtual-Template2
frame-relay interface-dlci 215 ppp Virtual-Template1
frame-relay interface-dlci 216 ppp Virtual-Template2
frame-relay interface-dlci 225 ppp Virtual-Template1
frame-relay interface-dlci 226 ppp Virtual-Template2
no frame-relay inverse-arp
!
interface Virtual-Template1
no ip address
ppp multilink
ppp multilink group 1
!
interface Virtual-Template2
no ip address
ppp multilink
ppp multilink group 2
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
area 0.0.37.128 virtual-link 5.5.5.5
redistribute eigrp 24 subnets
network 143.43.65.2 0.0.0.0 area 0.0.37.128
Routing entry for 5.5.5.5/32
Known via "ospf 1", distance 110, metric 1191, type inter area
Redistributing via eigrp 24
Advertised by eigrp 24 metric 1 1 1 1 1
Last update from 143.43.65.5 on Multilink2, 00:35:54 ago
Routing Descriptor Blocks:
* 143.43.65.5, from 5.5.5.5, 00:35:54 ago, via Multilink2
Route metric is 1191, traffic share count is 1
Neighbor ID Pri State Dead Time Address Interface
5.5.5.5 0 FULL/ - - 143.43.65.5 OSPF_VL0
6.6.6.6 0 FULL/ - 00:01:32 143.43.65.6
Multilink2
5.5.5.5 0 FULL/ - 00:01:48 143.43.65.5
Multilink1
R5
interface Multilink1
ip address 143.43.65.5 255.255.255.0
ip ospf network point-to-point
ppp multilink
ppp multilink group 1
interface Serial0/1/0
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 502 ppp Virtual-Template1
frame-relay interface-dlci 512 ppp Virtual-Template1
frame-relay interface-dlci 522 ppp Virtual-Template1
no frame-relay inverse-arp
interface Virtual-Template1
no ip address
ppp multilink
ppp multilink group 1
!
router ospf 1
router-id 5.5.5.5
log-adjacency-changes
area 0.0.37.128 virtual-link 2.2.2.2
network 143.43.65.5 0.0.0.0 area 0.0.37.128
!
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/ - - 143.43.65.2 OSPF_VL0
192.168.2.8 1 FULL/DR 00:00:38 143.43.200.2
FastEthernet0/0
2.2.2.2 0 FULL/ - 00:01:30 143.43.65.2
Multilink1
R6
interface Multilink2
ip address 143.43.65.6 255.255.255.0
ip ospf network point-to-point
ppp multilink
ppp multilink group 2.
interface Serial0/1/0
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
frame-relay interface-dlci 602 ppp Virtual-Template1
frame-relay interface-dlci 612 ppp Virtual-Template1
frame-relay interface-dlci 622 ppp Virtual-Template1
no frame-relay inverse-arp
interface Virtual-Template1
no ip address
ppp multilink
ppp multilink group 2
!
router ospf 1
router-id 6.6.6.6
log-adjacency-changes
network 143.43.65.6 0.0.0.0 area 0.0.37.128
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/ - 00:01:56 143.43.65.2
Multilink2
143.43.96.9 0 FULL/ - 00:00:39 143.43.96.9 MFR1.1
Known via "ospf 1", distance 110, metric 2381, type inter area
Last update from 143.43.65.2 on Multilink2, 00:44:10 ago
Routing Descriptor Blocks:
* 143.43.65.2, from 5.5.5.5, 00:44:10 ago, via Multilink2
Route metric is 2381, traffic share count is 1
Blogs and organic groups at http://www.ccie.net <http://www.ccie.net/>
_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html
--
Andrew Lee Lissitz
all.from.nj_at_gmail.com
-- Andrew Lee Lissitz all.from.nj_at_gmail.com Blogs and organic groups at http://www.ccie.netReceived on Tue Sep 22 2009 - 23:23:06 ART
This archive was generated by hypermail 2.2.0 : Sun Oct 04 2009 - 07:42:04 ART