From: Connary, Julie Ann (jconnary@xxxxxxxxx)
Date: Sat May 05 2001 - 09:42:28 GMT-3
>Date: Sat, 05 May 2001 08:42:07 -0400
>To: Mas Kato <tealp729@home.com>
>From: "Connary, Julie Ann" <jconnary@cisco.com>
>Subject: RE: originating an ospf default route
>
>yes - if you go to the RFC - 23238 it talks about route servers being when
>the forwarding
>address is 0.0.0.0 and if you are on a multipoint lan - than it it suppose
>to set it to what the real next hop is. I'm assuming this is a Cisco
>configuration trick - but
>have been unable to find any concrete documentation on it.
>
>Julie Ann
>
>At 05:51 PM 5/4/2001 -0700, you wrote:
>>Yikes! Julie Ann, I'm with you regarding the wildcard mask--I mean,
>>we're talking Cisco OSPF 101 here.
>>
>>-Did the Type 5 LSAs stabilize this way?
>>
>>Mas
>>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>>Connary, Julie Ann
>>Sent: Friday, May 04, 2001 6:31 AM
>>To: Sanjeewa Alahakone
>>Cc: ccielab@groupstudy.com
>>Subject: RE: originating an ospf default route
>>
>>
>>Sanjeewa
>>
>>Right now it is 0.0.0.255 on both R2 and R5.
>>
>>After I changed it so that it is 0.0.0.0 (i.e network 137.20.20.2
>>0.0.0.0
>>area 0) the results are:
>>That this totally changes the behavior of how the external links are
>>advertised and what forward address is used.
>>
>>Now my ip ospf database external 0.0.0.0 looks like:
>>
>>r5#show ip ospf database external 0.0.0.0
>>
>> OSPF Router with ID (172.168.200.1) (Process ID 1)
>>
>>
>> Type-5 AS External Link States
>>
>> Routing Bit Set on this LSA
>> LS age: 70
>> Options: (No TOS-capability, DC)
>> LS Type: AS External Link
>> Link State ID: 0.0.0.0 (External Network Number )
>> Advertising Router: 200.200.200.1
>> LS Seq Number: 80000001
>> Checksum: 0x9D27
>> Length: 36
>> Network Mask: /0
>> Metric Type: 1 (Comparable directly to link state metric)
>> TOS: 0
>> Metric: 20
>> Forward Address: 0.0.0.0
>> External Route Tag: 1
>>
>>Why does that make a difference? I thought that the inverse mask on the
>>network statement only decided which interfaces to run OSPF on - now
>>here
>>we are seeing it is having an effect on how external routes are
>>advertised.
>>Any pointers to documentation on this?
>>
>>Julie Ann
>>
>>At 11:11 PM 5/4/2001 +1000, you wrote:
>> >Julie
>> >How is your OSPF inverse mask 0.0.0.(255-mask) or 0.0.0.0
>> >Just try and let me know :)
>> >Rgds
>> >Sanjeewa
>> >
>> >-----Original Message-----
>> >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>> >Connary, Julie Ann
>> >Sent: Friday, 4 May 2001 9:10 PM
>> >To: Mas Kato
>> >Cc: ccielab@groupstudy.com
>> >Subject: RE: originating an ospf default route
>> >
>> >
>> >Mas,
>> >
>> >I just realized that the lab used 137.20.20.1 on r2 and 137.20.20.2 on
>>the
>> >defualt route - I used
>> >137.20.20.2 on r2 and 137.20.20.3 as the next hop for the default
>>route.
>> >
>> >So that was my bad - but the question still applies - another person
>> >suggested no icmp redirect.
>> >
>> >Julie ann
>> >
>> >At 06:55 PM 5/3/2001 -0700, you wrote:
>> > >Julie Ann,
>> > >
>> > >I haven't done that lab yet, but after a quick glance, I'm a little
>> > >confused trying to reconcile what Task One, step 1 says (great start,
>> > >eh?), what Task One, step 4 says and the addressing you're using.
>> > >
>> > >But it sounds like the bottom-line is the solution specifies that the
>> > >advertised next-hop is r2's own Ethernet and not the next-hop
>>configured
>> > >in r2's static route? Could it be a typo? Because it looks like the
>> > >forwarding address is working as it should, so to force the solution
>>it
>> > >needs to be zeroed out...
>> > >
>> > >I found this on CCO: http://www.cisco.com/warp/customer/104/10.html
>> > >
>> > >What if you change the OSPF network type on r2's and r5's Ethernets
>>to
>> > >point-to-multipoint?
>> > >
>> > >Regards,
>> > >
>> > >Mas Kato
>> > >
>> > >
>> > >-----Original Message-----
>> > >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf
>>Of
>> > >Connary, Julie Ann
>> > >Sent: Thursday, May 03, 2001 5:12 PM
>> > >To: ccielab@groupstudy.com
>> > >Subject: originating an ospf default route
>> > >
>> > >
>> > >Hi,
>> > >
>> > >working a lab that has the following:
>> > >
>> > >
>> > >r2------ethernet ---r5-----
>> > >
>> > >r2's e0 = 137.20.20.2
>> > >r5's e0 = 137.20.20.10
>> > >r2 has an ip route 0.0.0.0 0.0.0.0 137.20.20.3 (another router on the
>> > >ethernet.)
>> > >r2 has an ip ospf default information-originate always metric-type 1
>> > >statement.
>> > >
>> > >r5 sees this default route as:
>> > >
>> > >O*E1 0.0.0.0/0 [110/21] via 137.20.20.3, 00:01:40, Ethernet0
>> > >
>> > >this is ccbootcamp lab 5. However - in the routing tables provided R5
>> > >should
>> > >see this as
>> > >
>> > >O*E1 0.0.0.0/0 [110/21] via 137.20.20.2, 00:02:40, Ethernet0
>> > >
>> > >If I look at the database I see:
>> > >
>> > >OSPF Router with ID (172.168.200.1) (Process ID 1)
>> > >
>> > >
>> > > Type-5 AS External Link States
>> > >
>> > > Routing Bit Set on this LSA
>> > > LS age: 143
>> > > Options: (No TOS-capability, DC)
>> > > LS Type: AS External Link
>> > > Link State ID: 0.0.0.0 (External Network Number )
>> > > Advertising Router: 200.200.200.1
>> > > LS Seq Number: 80000006
>> > > Checksum: 0x9C6E
>> > > Length: 36
>> > > Network Mask: /0
>> > > Metric Type: 1 (Comparable directly to link state metric)
>> > > TOS: 0
>> > > Metric: 20
>> > > Forward Address: 137.20.20.3
>> > > External Route Tag: 1
>> > >
>> > >So my question is - how in the answers does the forwarding address
>> > >become
>> > >router 2 (137.20.20.2) and not 137.20.20.3?
>> > >Is there a trick to this that I am missing? Or should OSPF when it
>> > >originates a default route within the same area not change the
>> > >forwarding address?
>> > >
>> > >Thanks,
>> > >
>> > >Julie Ann
>> > >
>> > >p.s. I also got the ospf-demand circuit to work in 5b by making sure
>> > >that
>> > >my ISDN interface was not being redistributed
>> > >back into ospf from igrp and having LSA type 5's keep the circuit up.
>> > >The
>> > >lab says that ospf demand circuit does not
>> > >work for this topology - but mine worked fine.
>> > >
>> >
>> >-----------------------------------------------------------------------
>>-
>> > > Julie Ann Connary
>> > > | | Network Consulting
>>Engineer
>> > > ||| ||| Federal Support Program
>> > > .|||||. .|||||. 13635 Dulles Technology
>> > >Drive,
>> > >Herndon VA 20171
>> > > .:|||||||||:.:|||||||||:. Pager: 1-888-642-0551
>> > > c i s c o S y s t e m s Email: jconnary@cisco.com
>> > >
>> >
>> >-----------------------------------------------------------------------
>>-
>> > >**Please read:http://www.groupstudy.com/list/posting.html
>> >-----------------------------------------------------------------------
>>-
>> > Julie Ann Connary
>> > | | Network Consulting Engineer
>> > ||| ||| Federal Support Program
>> > .|||||. .|||||. 13635 Dulles Technology
>>Drive,
>> >Herndon VA 20171
>> > .:|||||||||:.:|||||||||:. Pager: 1-888-642-0551
>> > c i s c o S y s t e m s Email: jconnary@cisco.com
>> >
>> >-----------------------------------------------------------------------
>>-
>> >**Please read:http://www.groupstudy.com/list/posting.html
>>------------------------------------------------------------------------
>> Julie Ann Connary
>> | | Network Consulting Engineer
>> ||| ||| Federal Support Program
>> .|||||. .|||||. 13635 Dulles Technology
>>Drive,
>>Herndon VA 20171
>> .:|||||||||:.:|||||||||:. Pager: 1-888-642-0551
>> c i s c o S y s t e m s Email: jconnary@cisco.com
>>
>>------------------------------------------------------------------------
>>**Please read:http://www.groupstudy.com/list/posting.html
------------------------------------------------------------------------
Julie Ann Connary
| | Network Consulting Engineer
||| ||| Federal Support Program
.|||||. .|||||. 13635 Dulles Technology Drive,
Herndon VA 20171
.:|||||||||:.:|||||||||:. Pager: 1-888-642-0551
c i s c o S y s t e m s Email: jconnary@cisco.com
------------------------------------------------------------------------
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:30:34 GMT-3