Tom Martin wrote:
> Robert,
>
> I believe that your diagram should reflect R1's serial interface to R2
> as s0/1 instead of s0/0. This caused me some confusion in trying to
> figure out the configs. Actually, there is still some confusion given
Sorry for that - this was copy-pasting error (there's a whole bunch of
other stuff running on the routers, I had to filter these out). The
addressess are unique, obviously - if they were'nt then the router would
drop (as unroutable) the packet with src_IP equal to IP of one of its
interfaces - so the RIP update would have got no chance to enter the RIP
process.
> You make a strong argument that a more logical interpretation would be
> to use the local IP address 172.16.66.1/25 to interpret the route since
> it is the only IP address that is on the same subnet as the sending
> router (since the other IPs configured on the link should, based on
> normal IP rules, require another router to communicate with the sender).
> All documentation I've come across and configuration I have done
> indicates that the receiving router validates the update based on major
> network only, and then uses the mask of the locally configured address
> of that network to interpret the incoming networks. So, technically,
> interpreting the route as 172.16.77.0/29 isn't "wrong" -- it's just one
> of 3 possible ways of interpreting the advertised network.
That's correct - all choices, according to many written sources, are
perfectly correct. But the router has to break a tie - in this case
longest subnet mask was chosen. I'm still curious if this behaviour is
defined somewhere or this is Cisco-feature IOS-dependent one.
For reference: below is an algorithm, hopefully complete, for classfull
processing of RIP updates compiled by me from various sources and
documents including Doyle and Zinin. I had to add 'longest' to
'apply_mask_of_incoming_interface' based on results of testing this issue.
Receiving (update):
if (major net of update the same as of incoming interface ?)
{
NO:
if (any subnets of major net of update already exist in route
table known from other interfaces ?)
{
YES: discard( update );
exit();
NO: apply_classfull_mask( update );
populate_rt( update );
exit();
}
YES:
if (there are any bits in host portion)
{
NO: apply_longest_mask_of_incoming_interface( update );
populate_rt( update );
exit();
YES: apply_32_mask( update );
populate_rt( update );
exit();
}
}
Sending (update):
if (subnet of update in the same major net as outgoing interface)
{
YES: if (subnet mask is the same as subnet mask of sending
interface ?)
{
NO: if (the update is a host route ?)
{
YES: send( update );
exit();
NO: discard( update );
exit();
}
YES: send( update );
exit();
}
NO: summarize_classfull( update );
send( update );
exit();
}
>
> I'm curious as to whether your configuration works at all given the
> next-hop address (172.16.66.1) is also a valid IP address on R2. Are
> you able to ping 172.16.200.1 from R2? It seems to me that R2 should be
It will drop packet as unroutable.
robert,
--
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=57192&t=57049
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
