RAF@NIHCU.BITNET ("Roger Fajman") (05/12/89)
My question is the route that packets will follow in this situation:
Ethernet A (full RIP)
-----------------------------
| |
| |
|-----| |-----|
--| |-- --| |-- T1 C
--| 1 |-- --| 2 |--
|-----| |-----|
| |
| |
-----------------------------
Ethernet B (default routes)
The idea is that there are 2 or more routers (Proteon p4200 and/or
cisco AGS) connected to 2 Ethernets. Each router also has some T1
lines. The routers exchange full RIP routing information on Ethernet
A. They send only default routes on Ethernet B, which has workstations,
PCs, and other machines on it.
The machines on Ethernet B get their default route by either having the
IP address of a single router in their configuration (e.g., PCs), or by
listening to the default RIP routes (e.g., Unix workstations). Either
way, each machine uses one and only one of the routers as its default.
Now suppose that a machine on Ethernet B is using Router 1 as its
default and sends a packet that must go out T1 line C. Will Router 1
give the sending machine a redirect to Router 2? My understanding is
that a redirect is normally sent only if the packet has to be sent out
the same interface that it arrived on. This would not be the case here
since Router 1 will send the packet to Router 2 via Ethernet A, while
it came in from Ethernet B.
When a packet comes back in response, it will arrive via Router 2.
Will the receiving machine then update its ARP cache to point to Router
2 instead of Router 1?
If I configure the machine on Ethernet B and the routers to use proxy
ARP, I presume that both routers would answer and it would be
unpredictable as to which router would be used.
If I were to change RIP to OSPFIGP (when that becomes available) would
the answers be any different?
Thanks for thinking about this.medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (05/12/89)
Roger, No redirects will be sent by the routers to the hosts since the next hop will not be on the same net (ethernet B). The ARP's that will occur won't change the next hop. With some effort, and possibly breaking the hosts view of what the real subnet mask is on the B cable, proxy arp might work, but I think it's a gross hack in this case and you'd be better off without it. When OSPF comes along, it's not really any different, but you can instead run full OSPF routing on Ethernet B, and if you do that, you'll get the redirects as you want. This isn't a big deal, since most of the time you go to a 2 net structure like you describe is to reduce broadcast traffic on a LAN with hosts on it, or because you worry about some host there injecting foul routing information in the system. OSPF addresses these problems by Multicasting on broadcast LAN's, like Ethernet, and thus hosts won't hear it unless they are a part of that multicast group. Also, misconfigured hosts won't be sending back ICMP noise at the routers since they won't be hearing the multicasts. It also means that even if they run gated or RIP, they still won't be having to digest full routing info. That way you can use RIP on the cable to lead hosts to a default router, and run OSPF between the routers with full routing info flowing via multicasts... Even if a 'enemy' OSPF router were present on that cable, he still wouldn't be able to inject unwanted routing info into the system because OSPF supports authentication across all router adjacencies. Thus the 'enemy' router won't be believed by router 1 or router 2. And thus you won't have coincidentally colocated routers fouling your routing domain. If you are worried about loading on ethernet B, OSPF will also allow you to load balance across ethernet A and B (equal cost multipath support is built in to the protocol, though a particular router implementation (e.g. BSD Unix) may not implement it). If you are load balancing across A and B, then one of the next hops will be on the same net, and the routers should issue redirects as appropriate... OSPF is most topologies will generate a lot less routing traffic than RIP anyway. Even if you don't like SPF routing algorithms, OSPF's multicasting and router authentication are really nice things to have. It's too bad it's taken this long for a standard IP routing protocol to incorporate these features. The technology to do it has been with us for some time. Better late than never though! Thanks, Milo
jnc@proteon.com (J. Noel Chiappa) (05/17/89)
This is a bit of a tricky subject. The specs as written say that a Redirect is only sent when the next hop is on the same net, not if there is a 'better' first hop. To make your case even more plain, assume that network A is something high speed like an FDDI backbone, so that it makes sense for the preferred path from Router 1 to Router 2 to be network A. RFC-1009 states that: "A gateway will generate an ICMP Redirect if and only if ... the next-hop gateway is on the same (sub-)network as the source host." The ICMP RFC (RFC 792) says more or less the same thing: "If [the next-hop gateway] and the [source host] are on the same network, a Redirect message is sent". However, the real intent of the Redirect was to handle cases "when the gateway can direct the host to send traffic on a shorter route", to use the RFC-792 language. As I recall (and my memory of this is dim, since it was 10 years ago now that we did ICMP :-), the algorithm specified above was added to provide a concrete example of what to do. It was definitely pointed out at the time that cases like the one you pointed out existed, but I don't think we were trying to outlaw that. One problem was that all the existing 'gateways' at that time had routing tables which couldn't *tell* you things like 'Oh, even though some other gateway is the best next hop for you, and on a different net, there's this gateway on the source host's net that would be a better first hop for it'. The case you listed is fairly simple, but suppose your Router 2 is actually several routers, one connected to network B, one connected tot he serial link to the destination, and one connected to A, connected in a row by links of various kinds. It might be legit for 1's best route to C to be over network A. Fixing this kind of thing in general for Vector Distance algorithms have required a separate routing table be kept per interface, using only routing info coming in through that interface. Doing it in Link State algorithms is also some work; you basically have to calculate separate trees with each attached network as the source node, and see if the first hop to a given destination is through you or not. Also, one nice thing about the way the spec is currently done is that it's cheap to do the Redirect test; you only need to check more thoroughly those packets which are being sent out the same interface they came in on, which should happen rarely and be fast to do. However, the next revision of the Router RFC might want to state that you can provide a Redirect to a host on the same net as the router if the best first hop for the final destination is not this router but another one on the same net, and give the more restrictive wording as the default algorithm. Noel
stev@VAX.FTP.COM (05/17/89)
*From: jnc@proteon.com (J. Noel Chiappa) * RFC-1009 states that: "A gateway will generate an ICMP Redirect if *and only if ... the next-hop gateway is on the same (sub-)network as the *source host." The ICMP RFC (RFC 792) says more or less the same thing: "If *[the next-hop gateway] and the [source host] are on the same network, a *Redirect message is sent". * Noel it all depends on how you interpret the line above. it doesnt say something to the effect of "using the same interface", it says "is on the same subnet". both routers *are* on the same subnet as the host, regardless of the routing of packets between the two routers. the routers *should* send the ICMP redirect. now, this may be hard for the router in question to know (that the second router is also on the subnet that the host is on), but this is something that needs to be dealt with in the routing protocols. this may, ofcourse, not be in keeping with the "spirit" of the above lines, but seems to me to be a reasonable interpretation. so i must be missing something . . . . . . stev knowles stev@ftp.com ftp softwar