The IP Over NBMA (ION) Archive

["M.J. Robinson" <92mjr1@eng.cam.ac.uk>]

Hi Yiqun,
	Thanks for your thought provoking email.

> I just started reading/understanding NHRP. I got a question regarding the
> solutions for removing Domino Effect described in 6.4 of the draft. 
> 
> 6.4 of the draft describes four solutions. Here are my doubts:
> 
> 1. The first solution restricts the transit routers not to send a request. My
> doubt is that in a case where there are NHRP capables routers as well as
> non-NHRP speaking routes, and the first (or the first few) routers do not
> speak NHRP, the Next Hop Resolution Requests will never get sent; isn't it
> true?

	It depends how this solution is implemented. I think it means
"allow router to be configured such that it never _sends_ NHRP Requests
(but otherwise processes NHRP packets)". I don't think it's a neat
solution as you have extra configuration to do. 

> 2. The second solution requires that an NHRP station send the Next Hop
> Resolution Request before the data packets. In cases where NHRP speaking
> routes are also NHSs along the routed path of both the request packets and
> the data packets, the solution would require the routers process the request
> packets first and in realtime, which I see would cause excessive delay in
> forwarding the data packets. I do not see a good reason that NHRP PDUs should
> be processed in realtime

	Could work, but not on all hardware. I think this option might be 
useless for this reason - if we can't guarantee that all NHRP Requests 
precede the data packets which generate them, this solution won't work.

> 3. The third solution requires that a router generates Next Hop Resolution
> requests for packets from non-NBMA interfaces only. I see this solution has
> the same problem with the first one.

	This is my prefered solution, as it requires no extra
configuration. I think some extra text may be needed in the draft to
clarify things. I'll attempt to explain my ideas for applying it to your
scenario. I'll refer to Figure 1 in my conference style paper (available
from the ion FTP server (ftp://ftp.nexen.com/pub/ion/) as
Robinson-conf.pdf, .ps, and .doc. ). 

	Imagine that non-NHRP capable routers are in OSPF Area 1 only 
(i.e. H, G, I etc., but _not_ A,B). ABRs (A,B,M,N) and routers in Area 2 
(including O) are NHRP capable.

	Typically the ABRs will have a single physical link into the 
network (as portrayed in the right-hand diagram). Hence the three links 
into each ABR are configured as _logical_ subinterfaces (each with their 
own IP and E164 (or whatever) address). For each of these subinterfaces, 
NHRP can be enabled or disabled (and typically an NHRP network number 
specified also).

	In our case, router A's subinterface in Area 1 would have NHRP
disabled, while its subinterface in Area 0 would have NHRP enabled. 
Likewise for router B. (Typically, the NHRP network number would be the
same for all routers belonging to the same company within a specific NBMA
network.) Routers M and N would have NHRP configured on all 
sub-interfaces (with the same NHRP network number).

	Hence, if we send data traffic from network 1 to network 2, 
router H is unable to establish a shortcut to O (since H doen't run 
NHRP). However, once traffic reaches A (or B) it passes in through a 
sub-interface with a different (no) NHRP network number to that which it 
exits from. Hence it A can send an NHRP Request and establish a short-cut 
to O without being subject to the Domino Effect. By contrast, any data 
packets sent via the hop-by-hop route which reach router M (or N) will 
enter and exit via (different) sub-interfaces with the _same_ NHRP network 
number. Hence these routers should not generate NHRP Requests for the 
destination.

> 4. Rate limiting. I think this may be the only solution that will work.
	Please could someone explain what they had in mind. This one 
seems like a red-herring to me. Since rate limiting is on a per-router 
(rather than per-network) basis, this will not stop M sending an NHRP 
request just because A has sent one. Perhaps the idea was that M would be 
trying to establish shortcuts elsewhere and so this would use all the 
available rate (though this doesn't seem to get us very far).

	I hope that this describes the situation correctly. If I've 
misinterpreted anything in the draft, then please let me know.

	Matthew.