From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Tue Oct 30 2007 - 12:11:14 ART
Hey CCIEin2006,
To answer your follow-up, it is the RID (and yes, your ASCII art is once
again on target). I actually had planned to post some 'sh ip ospf database'
stuff but the e-mail was busy enough as it was and also I actually changed
R5's RID midway through testing, and it would have confused things
considerably (and it was getting too late to reproduce all of my output with
the new RID consistent across it all). Right now I have manually assigned
R5 a RID of 10.0.55.1/32 (because I had to troubleshoot the VL at one point,
and having the RID be outside of 10.0.50.0/24 seemed important at one
point). Here is the output w/ the VL via A1:
R4(config-router)#do sh ip ospf data
OSPF Router with ID (10.0.45.4) (Process ID 100)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.0.14.1 10.0.14.1 1726 0x80000013 0x006815 2
10.0.23.2 10.0.23.2 1659 0x80000012 0x00CF84 2
10.0.36.3 10.0.36.3 1679 0x80000013 0x0050B3 2
10.0.45.4 10.0.45.4 14 0x80000013 0x00EEF5 2
10.0.55.1 10.0.55.1 1 (DNA) 0x80000016 0x001906 1
10.0.56.6 10.0.56.6 61 0x80000014 0x00D94F 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.0.12.2 10.0.23.2 1659 0x8000000F 0x00BDF6
10.0.14.1 10.0.14.1 1726 0x8000000E 0x005C4A
10.0.23.3 10.0.36.3 1679 0x8000000F 0x00DBA6
10.0.36.3 10.0.36.3 1678 0x8000000E 0x00351C
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.0.45.0 10.0.45.4 970 0x8000000E 0x005765
10.0.45.0 10.0.55.1 40 (DNA) 0x8000000F 0x002193
10.0.50.0 10.0.55.1 40 (DNA) 0x8000000F 0x00E9C5
10.0.56.0 10.0.55.1 40 (DNA) 0x8000000F 0x00A702
10.0.56.0 10.0.56.6 1510 0x8000000E 0x008420
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
10.0.45.4 10.0.45.4 16 0x80000016 0x007DAE 1
10.0.55.1 10.0.55.1 17 0x80000016 0x000716 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.0.45.4 10.0.45.4 972 0x80000010 0x0086B0
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.0.12.0 10.0.45.4 972 0x80000010 0x00C911
10.0.14.0 10.0.45.4 972 0x80000010 0x00A930
10.0.23.0 10.0.45.4 972 0x80000010 0x005A74
10.0.36.0 10.0.45.4 973 0x80000010 0x00D4EB
10.0.50.0 10.0.55.1 52 0x80000010 0x00E7C6
10.0.56.0 10.0.55.1 52 0x80000010 0x00A503
And now the output with the VL via A2:
R4#sh ip ospf data
OSPF Router with ID (10.0.45.4) (Process ID 100)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.0.14.1 10.0.14.1 1541 0x80000013 0x006815 2
10.0.23.2 10.0.23.2 1474 0x80000012 0x00CF84 2
10.0.36.3 10.0.36.3 1494 0x80000013 0x0050B3 2
10.0.45.4 10.0.45.4 1783 0x80000012 0x00AEC6 1
10.0.55.1 10.0.55.1 5 (DNA) 0x80000006 0x0040D6 1
10.0.56.6 10.0.56.6 1565 0x80000013 0x000C81 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.0.12.2 10.0.23.2 1474 0x8000000F 0x00BDF6
10.0.14.1 10.0.14.1 1541 0x8000000E 0x005C4A
10.0.23.3 10.0.36.3 1493 0x8000000F 0x00DBA6
10.0.36.3 10.0.36.3 1493 0x8000000E 0x00351C
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.0.45.0 10.0.45.4 785 0x8000000E 0x005765
10.0.45.0 10.0.55.1 134 (DNA) 0x80000001 0x003D85
10.0.50.0 10.0.55.1 134 (DNA) 0x80000001 0x0006B7
10.0.56.0 10.0.55.1 134 (DNA) 0x80000001 0x00C3F3
10.0.56.0 10.0.56.6 1324 0x8000000E 0x008420
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
10.0.45.4 10.0.45.4 1785 0x80000015 0x0073BD 1
10.0.55.1 10.0.55.1 1920 0x80000012 0x000322 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.0.45.4 10.0.45.4 786 0x80000010 0x0086B0
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.0.12.0 10.0.45.4 786 0x80000010 0x00C911
10.0.12.0 10.0.55.1 1920 0x8000000D 0x00AF25
10.0.14.0 10.0.45.4 786 0x80000010 0x00A930
10.0.14.0 10.0.55.1 1920 0x8000000D 0x00A32E
10.0.23.0 10.0.45.4 786 0x80000010 0x005A74
10.0.23.0 10.0.55.1 1920 0x8000000D 0x002C9E
10.0.36.0 10.0.45.4 786 0x80000010 0x00D4EB
10.0.36.0 10.0.55.1 1920 0x8000000D 0x00922C
10.0.50.0 10.0.45.4 1785 0x8000000D 0x00545F
10.0.50.0 10.0.55.1 1920 0x8000000E 0x00EBC4
10.0.56.0 10.0.45.4 1785 0x8000000F 0x0004A8
10.0.56.0 10.0.55.1 1920 0x8000000E 0x00A901
At first, there doesn't appear to be any real difference. But we need to
remember that the A0 topology is different in each case. Thus, if I do a
'sh ip route 10.0.50.0' in each scenario, my next hop changes to be either
10.0.45.5 in the first case, or 10.0.14.1 in the second. This is just your
everyday A0 database synchronization (the "Neighboring Router ID" seen in
the output of 'sh ip ospf database router 10.0.55.1' changes to reflect
either 10.0.45.5 or 10.0.56.6, depending on whether it's being learned via
the A1 VL directly or via the A2->R6->backbone VL, respectively). Another
thing I read on CCO (not the DocCD) was that any A1 router in the R4<->R5
path would actually see 10.0.50.0 as being via R5 when the VL terminates at
R4. In other words, it would not send traffic to R4, as you might assume if
you are under the impression that payload traffic is actually tunneled by
R4. Since A3 payload is routed natively through A1, it would create a loop
for any router along that path to send to R4, only to have R4 send it back
towards R5 un-tunneled!
I was glad to do this, as I think I now have a better grasp on VLs.
However, I still need to return to Narbik's post regarding the transit
thing. Possibly more from me on that following today's little project for a
paying client (although they're already an hour late in calling (as usual),
grrr).
Regards,
Scott
From: CCIEin2006 [mailto:ciscocciein2006@gmail.com]
Sent: Tuesday, October 30, 2007 8:30 AM
To: Scott Vermillion
Cc: Narbik Kocharians; Cisco certification
Subject: Re: Why must all areas connect to Area 0?
Great detective work Scott! I guess if I'm ever going to get my number I
need to get off my arse and start labbing these up myself...
Just to confirm your results.
In the first case where the VL is between R4 and R5 you essentialy have
this:
A3
|
R4-A1-R5-A2-R6
| \ / |
A0 A0 A0
| |
R1-A0-R2-A0-R3
Where R5 is injecting the A2 adn A3 routes via the VL to R4.
In the second case where the VL is between R5 and R6 you have this:
A3
|
R4-A1-R5-A2-R6
| \ / |
A0 A0 A0
| |
R1-A0-R2-A0-R3
Where R5 is injecting the A2 and A3 routes via the VL to R6.
Now my followup question...what does the OSPF database show as the
forwarding address in each of these cases? Is it the router-id of R5 or the
ethernet interface of R5? If it uses the ethernet address does it choose the
ethernet address that is the outgoing interface to reach its virtual link
neighbor?
Thanks again.
On 10/30/07, Scott Vermillion <scott_ccie_list@it-ag.com> wrote:
Hey CCIEin2006,
LOL, I got caught up in one of those domestic "some assembly required"
projects after dinner and here I am all these hours later. So it took me
until now to come back to this. After drafting my response, I realized it
was mere opinion, so I tore down what I was working on and built the exact
topology you describe below. Thus, I am now going through and updating
certain areas of the below message with hard results. If at times this
sounds a little strange, bear in mind it was written once as an "I think"
and then re-written as an "I know" (and BTW, I my opinions generally turned
out to be fact ;~) ).
.......
I love these discussions because they reveal to me how much I don't know
about something I previously thought I knew quite well. I've always felt I
was strong on OSPF, but perhaps not so much.
As far as I can tell, the below topology is broken. You've got R5 attached
to A1 and A2. Note that this makes R5 an ABR wannabe, yet it has no Area 0
connectivity. Sans Area 0 connectivity, it cannot become a true ABR. Thus,
R5 will not somehow be blissfully advertising its A2 topology to R4 and its
A1 topology to R6. In order to advertise a network in one area (A2 in this
case) into another area (A1 in this case), R5 would be required to have a
connection to the backbone, as that's how it would originate its Network
Summary LSAs to be flooded to other ABRs of other areas. In your below
topology, R5 will be able to successfully establish adjacencies with both R4
and R6 (to my surprise, I wasn't really sure what was going to happen
there), but again, it will not somehow be sharing the A2 topology with R4.
It can only do that by way of introducing Type 3 LSAs into the backbone, and
sans a VL, it obviously can't do that. And trying to anticipate another
possible question you might have, what R6 is introducing into the backbone
regarding A2 would not allow R4 to somehow know that R5 is on a physically
shorter path to A2; this is all distance vector stuff once we go inter-area,
so R6 is simply saying "to get to so-and-so, route to me" ("Advertising
Router" field in the Type 3 LSA).
But I understand the spirit of your question, so let's assume just for the
sake of argument that there's yet a third R5 interface and yet another area,
say A3, "lollipopped" off of R5. Again, in such a case, you need a virtual
link to the backbone via either A1 or A2. This changes the *OSPF* topology
to something different than what the physical topology would suggest.
Assuming the VL was through A1 to R4...
According to Doyle Vol I (pg 374 of second printing), "the virtual link is a
tunnel through which packets may be routed on the optimal path from one
endpoint to the other." However, he also states elsewhere in the book (or
perhaps I read it on the DocCD) that only OSPF packets are tunneled; traffic
is sent "natively" (hence the restriction that a transit area cannot be a
stub area, as routers in these have no knowledge of how to route external
traffic). In this case, R4 would shoot traffic bound for A3 "down the VL"
(again, it's my understanding that it will actually be sent natively through
the transit area) directly to R5. Now the question of traffic bound for A2
is interesting, because we basically have both R5 and R6 "attached" to the
backbone and introducing Type 3 LSAs for these networks. So here again, R4
sends traffic down the VL directly to R5, one of two ABRs for A2. Now, were
you to establish the VL via R6...
Then R4 would in fact route traffic to both A2 and A3 via the longer A0
path, as R5 would be introducing Type 3 LSAs for A2 and A3 into this OSPF
topology from the VL into A0 via R6 and then across to R4 (and R5 would also
send an A0 router LSA in this same way, etc). While R4 will definitely know
it can reach R5 via A1, it will basically see a "distance vector" route to
those A2 and A3 networks via A0 (where they were learned from). I think
this all makes sense from a loop avoidance standpoint, as this essentially
is distance vector behavior once we go inter-area. We only know that to
reach a given destination outside of our area, we follow a particular
vector; we have no direct knowledge of the topology beyond. Thus, we need a
"root" in this here spanning tree of sorts, and that will always necessarily
be Area 0.
Now for some lab results! My addressing scheme follows the IEWB (and
presumably other vendor's) scheme of blending the router numbers together.
Thus, the link between R1 and R2 will have addresses 10.0.12.1 and
10.0.12.2, respectively. So on and so on. Remember that my topology is
yours below plus that extra A3 hanging off of R5 (and I just randomly gave
that the 10.0.50.0 network). So this is with the VL via A1:
R4#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static
route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 7 subnets
C 10.0.14.0 is directly connected, FastEthernet0/0
O 10.0.12.0 [110/2] via 10.0.14.1, 00:00:14, FastEthernet0/0
O 10.0.23.0 [110/3] via 10.0.14.1, 00:00:14, FastEthernet0/0
C 10.0.45.0 is directly connected, FastEthernet0/1
O 10.0.36.0 [110/4] via 10.0.14.1, 00:00:14, FastEthernet0/0
O IA 10.0.56.0 [110/2] via 10.0.45.5, 00:00:14, FastEthernet0/1
O IA 10.0.50.0 [110/2] via 10.0.45.5, 00:00:14, FastEthernet0/1
R4#trace 10.0.50.1
Type escape sequence to abort.
Tracing the route to 10.0.50.1
1 10.0.45.5 8 msec * 28 msec
R4#trace 10.0.56.6
Type escape sequence to abort.
Tracing the route to 10.0.56.6
1 10.0.45.5 12 msec 20 msec 20 msec
2 10.0.56.6 60 msec * 56 msec
So you can see here that R4 is, not all that surprisingly, routing through
A1 to get to A50. Also note that it is following this same path to get to
A2. Now for the VL via A2:
R4# sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static
route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 7 subnets
C 10.0.14.0 is directly connected, FastEthernet0/0
O 10.0.12.0 [110/2] via 10.0.14.1, 00:21:16, FastEthernet0/0
O 10.0.23.0 [110/3] via 10.0.14.1, 00:21:16, FastEthernet0/0
C 10.0.45.0 is directly connected, FastEthernet0/1
O 10.0.36.0 [110/4] via 10.0.14.1, 00:21:16, FastEthernet0/0
O IA 10.0.56.0 [110/5] via 10.0.14.1, 00:21:16, FastEthernet0/0
O IA 10.0.50.0 [110/6] via 10.0.14.1, 00:21:16, FastEthernet0/0
R4#trace 10.0.50.1
Type escape sequence to abort.
Tracing the route to 10.0.50.1
1 10.0.14.1 8 msec 12 msec 8 msec
2 10.0.12.2 8 msec 16 msec 16 msec
3 10.0.23.3 20 msec 24 msec 32 msec
4 10.0.36.6 60 msec 44 msec 48 msec
5 10.0.56.5 84 msec * 64 msec
R4#trace 10.0.56.6 <http://10.0.56.6>
Type escape sequence to abort.
Tracing the route to 10.0.56.6
1 10.0.14.1 8 msec 20 msec 20 msec
2 10.0.12.2 <http://10.0.12.2> 16 msec 56 msec 12 msec
3 10.0.23.3 48 msec 56 msec 60 msec
4 10.0.36.6 80 msec * 84 msec
We now see R4 following the circuitous route via A0 to get to A2 and A50.
OK, it's just hours from show time for an important client tomorrow (this
morning at this point), gotta run...
Regards,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
CCIEin2006
Sent: Monday, October 29, 2007 5:19 PM
To: Scott Vermillion
Cc: Narbik Kocharians; Cisco certification
Subject: Re: Why must all areas connect to Area 0?
You're right,
That was a bad example because R2 and R3 were in same area. Here is more
what I intended:
R4-A1-R5-A2-R6
| |
A0 A0
| |
R1-A0-R2-A0-R3
For R4 to get to the segment between R5 and R6, will it take the shorter
path through area 1 and area 2 or will it take the longer path through area
0?
P.S. - I hate virtual links too - they're like the duct tape of OSPF. You
never have these problems with EIGRP :-)
In this setup will R2 use
On 10/29/07, Scott Vermillion < scott_ccie_list@it-ag.com> wrote:
>
> Hi CCIEin2006,
>
>
>
> The ASCII art worked out great.
>
>
>
> Narbik has me questioning myself at this point (which is a good thing),
> since I don't really know what that transit thing is all about. But
> generically speaking, the "rules" of OSPF state that your R2 and R3 ABRs
> would need at least one connection to the backbone, so from that
> perspective, I think that yes, you are correct that you would need a
virtual
> links to maintain a "proper" OSPF design. Having said that, assuming that
> the basic hello parameters matched up between R2 and R3 for Area 3, it
seems
> that they would attempt to form an adjacency. But in attempting to
> synchronize their databases, I would expect some trouble (sans the
> aforementioned virtual links). They are ABRs, yet they have no Area 0
> connectivity. Now that you've got me thinking about this, it's something
> I'm interested to see the debug of in the lab. However, I have several
more
> hours of work to do in the lab I'm presently building, so I can't try it
> until later this evening.
>
>
>
> It just dawned on me that I may still be missing your question. Are you
> asking how traffic would flow if you **did** build the virtual links?
> Would a packet entering into R2 bound for a network attached to R3 transit
> A1 and A2 or would it directly transit A3? If that's the question, I
think
> it simply transits A3, as your OSPF topology at that point does not mirror
> the topology as drawn below. At that point you basically have A0 in the
> center, to which R1 is attached and is acting as ABR for A1 and A2, and
you
> also have R2 and R3 "attached" to the backbone, both serving as ABR for A3
> only. In that case the traffic in question would not be inter-area
traffic
> at all; it would be intra-area A3-only traffic. Seemingly?
>
> "Have I ever mentioned that virtual links are my least favorite aspect of
> OSPF?!"
>
> Narbik's link was to the command reference; perhaps I can find more
> information about this on the Config Guide side of the house once I've
> wrapped up what I'm working on at the moment. Some context and picture
> would likely be illuminating
>
>
>
> Regards,
>
> Scott
>
>
>
>
>
>
>
> *From:* CCIEin2006 [mailto: <mailto:ciscocciein2006@gmail.com>
ciscocciein2006@gmail.com]
> *Sent:* Monday, October 29, 2007 2:14 PM
> *To:* Scott Vermillion
> *Cc:* Narbik Kocharians; Cisco certification
> *Subject:* Re: Why must all areas connect to Area 0?
>
>
>
> Here's a scenario for you to try Scott (hope the ASCII art comes out
> clearly):
>
>
>
> R2--A3--R3
> \ /
> A1 A2
>
> \ /
>
> R1
>
> |
>
> A0
>
>
> R1 is connected to Area 0 and connects to R2 and R3 via area 1 and 2
> respectively.
>
> R2 and R3 have a direct connection to each other via area 3.
>
>
>
> 1. I am assuming for this to work I would need a virtual link between
> R1 and R2 and another virtual link between R1 and R3 - is that correct?
>
>
>
> 2. Considering transit capability is enabled by default, would R2 and R3
> sent traffic directly to each other via area 3?
>
>
> Thanks in advance.
>
>
>
> On 10/29/07, *Scott Vermillion* <scott_ccie_list@it-ag.com
<mailto:scott_ccie_list@it-ag.com> > wrote:
>
> Hey Narbik,
>
>
>
> Don't educate me too much before your upcoming bootcamp! But I couldn't
> really decipher the context of this:
>
>
>
> "OSPF area capability transit is enabled by default, allowing the OSPF
> Area Border Router to install better-cost routes to the backbone area
> through the transit area instead of the virtual links. If you want to
retain
> a traffic pattern through the virtual-link path, you can disable
capability
> transit by entering the *no capability transit* command. If paths through
> the transit area are discovered, they are most likely to be more optimal
> paths, or at least equal to, the virtual-link path. To reenable capability
> transit, enter the *capability transit* command."
>
>
>
> Have I ever mentioned that virtual links are my least favorite aspect of
> OSPF?!
>
>
>
> I just happen to have an active OSPF component in the lab I'm currently
> working if anyone has suggestions as to how to see this in action (and
come
> to understand how it applies to the discussion at hand I'm near 100%
sure
> Narbik is suggesting I'm incorrect in my below statement, but it's not
> exactly jumping out at me)
>
>
>
> Regards,
>
> Scott
>
>
>
>
>
> *From:* Narbik Kocharians [mailto:narbikk@gmail.com ]
> *Sent:* Monday, October 29, 2007 1:38 PM
> *To:* Scott Vermillion
> *Cc:* CCIEin2006; Cisco certification
>
>
> *Subject:* Re: Why must all areas connect to Area 0?
>
>
>
> Look at the "capability transit" command
>
>
>
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hirp_r
/
rte_osph.htm#wp999437
>
>
>
>
> On 10/29/07, *Scott Vermillion* < scott_ccie_list@it-ag.com
<mailto:scott_ccie_list@it-ag.com> > wrote:
>
> It must flow to Area 0. You cannot build a virtual link directly between
> Areas 1 and 2; all virtual links either connect two pieces of Area0 or
> they
> connect a non-0 area to Area 0. In other words, all virtual links involve
>
> Area 0!
>
> -----Original Message-----
> From: nobody@groupstudy.com <mailto:nobody@groupstudy.com> [mailto:
nobody@groupstudy.com] On Behalf Of
> CCIEin2006
> Sent: Monday, October 29, 2007 12:42 PM
> To: Cisco certification
> Subject: Re: Why must all areas connect to Area 0?
>
> So in this scenario
>
> Area1-Area2
> \ /
> Area0
>
> Area 1 and 2 are directly connected. Would the data need to flow to area0
> or
> can the traffic flow directly?
>
> What if we configured a virtual link between them?
>
> On 10/29/07, CCIEin2006 < ciscocciein2006@gmail.com> wrote:
> >
> > Hi folks,
> >
> > I was reading over Jeff Doyle's blog and came across his favorite
> > interview question:
> > Why does OSPF require all traffic between non-backbone areas to pass
> > through a backbone area (area 0)?
> >
> > Answer:
> > Because inter-area OSPF is distance vector, it is vulnerable to routing
> > loops. It avoids loops by mandating a loop-free inter-area topology, in
> > which traffic from one area can only reach another area through area 0.
> >
> > Can someone elaborate on that answer a little bit? Exactly how does
> having
> > a connection to Area0 prevent routing loops? Is it similar to spanning
> tree
> > in the area 0 is the root of the spanning tree?
> >
> > Also this answer does not take into consideration redistribution from
> > another routing protocol right?
> >
> > Thank You
> >
> > Here is the article:
> > http://www.networkworld.com/community/node/19293
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
> --
> Narbik Kocharians
> CCIE# 12410 (R&S, SP, Security)
> CCSI# 30832
> www.Net-WorkBooks.com <http://www.net-workbooks.com/>
This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:19 ART