kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (06/15/88)
I have a question concerning the behaviour of the Multimax and broadcast RIP packets. I understand the way the Multimax fails to understand subnets and conforms to old ideas of what broadcast IP addresses look like. I don't understand why the Multimax responds to broadcast packets it receives even when ip_forwarding is turned off. We have a cisco gateway that sends RIP broadcast packets on a net with two Multimaxen. The cisco people set the TTL to be "one" and set the "Don't fragment" flag. I think this makes sense as these packets should not be forwarded and a small TTL and DF set should stop any misbehaving router from forwarding these packets. Our Sun routers and Proteon routers have no trouble with these settings and can read the cisco RIP updates with no problem. No other hosts on the net have any trouble. But the Multimaxen have a problem. They send icmp Time Exceeded error messages back to the cisco complaining about these rip broadcasts. RFC 1009 says there are two reasons that a Time Exceeded message could be sent by a router: the TTL field has gone to zero or there was not enough time to reassemble the fragments of a packet. Why is the Multimax complaining? Must I put up with this because that's how 4.2bsd IP code works? Is this another of the set of problems with subnets and broadcast-fill-patterns and ip_forwarding- set-on-nonrouters that comes with old IP code? When will these problems be fixed? Ok, I've got my Kevlar vest on, so let me have it... Kent England, Boston U