Priscilla Oppenheimer wrote: > > Peter van Oene wrote: > > > > > > Nov 14 11:51:14.121 ESuT: OSPF: Rcv DBD from x.x.x.x on > > Channel6/0 seq > > > 0x3DCDF2DA opt 0x2 flag 0x7 len 32 mtu 0 state EXCHANGE > > > Nov 14 11:51:14.121 ESuT: OSPF: Send DBD to x.x.x.x on > > Channel6/0 seq > > > 0x3DCDF2DA opt 0x42 flag 0x2 len 1472 > > My money is on either the mtu mismatch (master seems confused > > here) or > > the multicast nature of dbd process cause folks to get > > confused. > > > > Bit 2 in options is the E bit where set (0x2) means stub and > > unset means > > normal area. > > After sending my message, I did some sniffing of books and RFCs > and packets with both EtherPeek and the NAI Sniffer and > discovered that the OSPF Options field has been in flux over > the years. > > As a former programmer, I would start with Bit 0. That's the > low-order bit in the 2^0 place. > > Doyle in Routing TCP/IP, and the NAI Sniffer, call Bit 0 the T > bit. Is is supposedly used to specify whether the router > supports routing based on the Type of Service bits. > > RFC 2328 says that bit is undefined, I was glad to see. > (Routing based on the TOS bits never panned out). > > Bit 1, or the bit in the 2^1 place, is the E bit. Both routers > in this scenario are setting it. > > > Both agree on the stubbiness of the area, so that > > should > > be fine. Bit 3 is the O bit and setting it refers to ones > > capability > > with opaque LSAs. > > Calling it Bit 3 is confusing. It's in the other nibble, for > one thing. > > It should be called Bit 6 and it is the Opaque (O) bit, per RFC > 2370, as you mentioned. The Sniffer got this right. Doyle and > EtherPeek don't mention it. > > This won't help JMcL (sorry) but here's how the option bits are > defined per RFC 2370: > > * | O | DC | EA | N/P | MC | E | * | > > E-bit > This bit describes the way AS-external-LSAs are flooded. > > MC-bit > This bit describes whether IP multicast datagrams are forwarded. > > N/P-bit > This bit describes the handling of Type-7 LSAs. > > DC-bit > This bit describes the router's handling of demand circuits. > > EA-bit > This bit describes the router's willingness to receive and > forward External-Attributes-LSAs. > > O-bit > This bit describes the router's willingness to receive and > forward Opaque-LSAs. > It does help, in that I can pretty much disregard the 0x42 options field as a problem. > > Sorry if this was a BIT to bit-picky. ;-) > > I agree with Peter that MTU seems the suspicious issue. Of > course, MTU should have different values depending on which > layer you are referring to and it's hard to know what one > specific configuration for a particular implementation (like on > the mainframe) expects, so this could certainly be an area for > concern. > > Let us know what you find out JMcL. Thanks. > Will do - I have passed on various suggestions to the mainframe guru who is dealing with it (including the possibility of it being a multipoint issue), but she is dealing with another couple of things as well so this probably won't get a quick resolution (it's not causing a problem until something else breaks ;-) I think it is probably not mismatched MTUs in the sense of a simple configuration incompatability, because there are working adjacencies which use the same value as the non-working ones (and the same value as on the router). But I think it probably is MTU somehow - perhaps a flow-on effect from another part of the config is affecting the value actually used.
JMcL > Priscilla > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=57489&t=57410 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
