I didn't know about the v-bit. Thanks for that info. (I thought it was used
to block bad stuff on TVs. ;-)
Regarding the network mask not having to match on point-to-point networks,
I tried it and it works. I guess the mask doesn't really matter on
point-to-point networks (although I agree it's not good practice for it not
to match). The network could use unnumbered and then the mask is undefined
and should be ignored, but it seems to be ignored even when the interfaces
have addresses.
Here's some output:
Boston#show ip ospf int s0
Serial0 is up, line protocol is up
Internet Address 192.168.40.1 255.255.255.0, Area 2
Process ID 100, Router ID 192.168.40.1, Network Type POINT_TO_POINT,
Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 0:00:07
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.10.0.2
Boston#show ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
10.10.0.2 1 FULL/ - 0:00:36 192.168.40.2 Serial0
Boston#telnet 10.10.0.2
Trying 10.10.0.2 ... Open
User Access Verification
Password:
charlotte>en
Password:
charlotte#show ip ospf int s0
Serial0 is up, line protocol is up
Internet Address 192.168.40.2 255.255.255.128, Area 2
Process ID 100, Router ID 10.10.0.2, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 0:00:09
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.40.1
charlotte#show ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
172.16.50.1 1 FULL/DR 0:00:37 10.10.0.1 Ethernet0
192.168.40.1 1 FULL/ - 0:00:35 192.168.40.1 Serial0
charlotte#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate
default
Gateway of last resort is not set
10.0.0.0 255.255.255.0 is subnetted, 1 subnets
C 10.10.0.0 is directly connected, Ethernet0
192.168.40.0 is variably subnetted, 2 subnets, 2 masks
O 192.168.40.0 255.255.255.0
[110/128] via 192.168.40.1, 00:06:05, Serial0
C 192.168.40.0 255.255.255.128 is directly connected, Serial0
O 192.168.30.0 [110/74] via 192.168.40.1, 00:06:05, Serial0
172.16.0.0 255.255.255.0 is subnetted, 2 subnets
O IA 172.16.50.0 [110/20] via 10.10.0.1, 00:06:05, Ethernet0
O IA 172.16.20.0 [110/16] via 10.10.0.1, 00:06:05, Ethernet0
charlotte#
Priscilla
At 05:53 PM 4/16/02, Chuck wrote:
>masks do not need to match on a virtual link for obvious reasons, those
>being that one cannot be certain of the end points. I suppose that in
>practical terms, one should always use /30's on serial links, and thus the
>end point masks would always match, but who can ever tell? I suppose it is
>possible that one end of a virtual link could be an ethernet or a token ring
>interface, and the distant end a serial interface, and thus it would be
>likely that masks do not match. ( and yes I know that in the case of Cisco,
>anyway, that the RID is the end point, and RID's don't have masks anyway. )
>BTW, a virtual link hello has the v-bit set - it is that which determines
>that the packet is for purposes of a virtual link.
>
>the point to point link masks not having to match is interesting. one of
>these days I'll have to set something up in the lab, just to see. not
>generally being one to deliberately setting things up incorrectly, I
>sometimes miss out on these kinds of curiousities.
>
>Chuck
>
>
>
>""Priscilla Oppenheimer"" wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > With regards to the items below, I would say that Cisco follows the RFC,
> > but just describes the issues a little differently. See comments below.
> >
> > At 04:28 PM 4/16/02, Kane, Christopher A. wrote:
> >
> > >It's within the Hello protocol that there are certain criteria that must
>be
> > >met. ACCORDING TO CISCO they are: Hello/Dead Interval, Area ID, Stub
Flag
> > >and Authentication [method and password]. So, I wanted to see what RFC
>2328
> > >had to say about it. I also checked John T. Moy's book, Anatomy of an
> > >Internet Routing Protocol. In both of those sources I find that the
> > >following must match: Network mask, HelloInterval and RouterDeadInterval
>and
> > >the E-bit of the Options Field. The exception being the Network mask
> > >(depending on the Network Type in use).
> > >
> > >RFC states:
> > >HelloInterval
> >
> > Cisco says this must agree also.
> >
> > >RouterDeadInterval
> >
> > Cisco says this must agree also.
> >
> > >Network Mask
> >
> > The RFC says to ignore this on point-to-point networks and on virtual
> > links. Maybe Cisco just doesn't mention it because it's not a rule that
> > always applies.
> >
> > >E-bit of Options Field (Area capable of processing AS-external-LSAs)
> >
> > That's what Cisco calls the stub flag I bet.
> >
> >
> > >Cisco implementation:
> > >Hello/Dead Interval
> > >Area ID
> >
> > The RFC covers this too, but in the general discussion, not just in the
> > discussion of Hellos. The Area ID in an OSPF packet must match the area
of
> > the receiving interface (except in the case of virtual links, in which
>case
> > it must indicate the backbone).
> >
> > >Stub Flag
> > >Authentication Method/password
> >
> > The RFC says this must agree on every OSPF packet. It just doesn't
> > specifically mention that it must agree on Hello packets.
> >
> >
> > >I realize vendors have the choice of how closely they follow an RFC.
> >
> > If the RFC says "must" then a vendor must do what it says. It's only when
> > it says "should" or in grey areas where the authors didn't make something
> > clear that you run into problems.
> >
> > > I'm
> > >just trying to make sure I understand the protocol for what it is and
for
> > >how Cisco deploys it. Can someone experienced with this protocol check
my
> > >understanding?
> > >
> > >-chris
> > ________________________
> >
> > Priscilla Oppenheimer
> > http://www.priscilla.com
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=41672&t=41647
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
