|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Alex Zinin (azinin
NEXSI.COM)Date: Thu Feb 14 2002 - 22:30:33 CST
Sam,
> RFC2328 mentions that setting of E bit for non-stub areas and backbone is
> for informational purposes! I am wondering how is this ever used. I have
> seen implementations which do not strictly follow this. They do generate
> LSAs with E bit set in to stub areas and been in use for years and are known
> to be working fine. What potential damage could this cause, if at all it
> causes any?
> I also find that there is no mention of this option in RFC2328 from the
> usage perspective. Is it meant for other protocols or future usage much like
> tags? I would appreciate if someone had used this option and implemented
> anything would share it in this forum.
As you said yourself, setting the E-bit in the LSAs is for informational
purposes only and other routers do not check its value. There's no
magic about this and there's no potential damage that could be caused.
The fact that you see some implementations setting this bit
occasionally and still working fine is an evidence to this.
> Another question: Recent versions of cisco implementation do not bring up
> adjacency on point-2-point links if they do not share the same subnet even
> though RFC mentions that it is not a requirement. Can someone tell me if
> they know why?
It is not a vendor specific mailing list... anyways...
This has to do with how IOS treats p2p links historically.
Specifically, it expects them to be either unnumbered or assigned
a subnet, even as small as /30 (in fact as small as /31 after Russ'
change ;)... OSPF tries to enforce this by doing the subnet check
on p2p links as well, and in fact it helps catching misconfiguration
and miswiring problems (it's easier to catch a subnet mismatch through
debugs than to debug DBDs on crossed links).
Alex.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]