""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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.
CL: DOH! of course! ( I gotta get outta sales and back into real networking ;-> ) CL: BTW, thanks much for the additional information, traces, etc. > > 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=41674&t=41647 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
