[c-nsp] Strict multihoming supported on a Cisco?

mezibra adel adel.mezibra-techlist at ip-generation.net
Wed Jul 28 17:14:55 EDT 2004


Hi, 

A "Cisco router" is by definition a router... not a simple host, and hence
does not have to comply with RFC1122.
However, to answer to your question, when IP routing is disabled (no ip
routing) the router will comply with the Host Requirements given in the
RFC1122.

Adel mezibra


-----Message d'origine-----
De : cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] De la part de Marcel Lammerse
Envoyé : mercredi 28 juillet 2004 22:52
À : cisco-nsp at puck.nether.net
Objet : [c-nsp] Strict multihoming supported on a Cisco?

Hi all,

an incoming ip packet, addressed to a Cisco router, will be forwarded 
to the destination address even if that address is not the ip address 
of the directly connected interface:

spectrum2#sh ip int brief
Interface              IP-Address      OK? Method Status Protocol
Ethernet0              192.168.2.1     YES NVRAM  up                    
up
Serial0                unassigned      YES NVRAM  up                    
up
Serial0.1              172.16.1.1      YES NVRAM  up                    
up
Serial0.100            212.189.28.2    YES NVRAM  up                    
up
Serial1                unassigned      YES NVRAM  administratively down 
down
spectrum2#

Testmachine has an ip of 192.168.2.2 and has its default gateway 
pointing to 192.168.2.1

[test at testmachine]$ ping 212.189.28.2
PING 212.189.28.2 (212.189.28.2) from 192.168.2.2 : 56(84) bytes of 
data.
64 bytes from 212.189.28.2: icmp_seq=1 ttl=255 time=6.20 ms
64 bytes from 212.189.28.2: icmp_seq=2 ttl=255 time=2.08 ms
64 bytes from 212.189.28.2: icmp_seq=3 ttl=255 time=2.09 ms

I've heard some security concerns about this. Is there a way of 
enforcing what is known as the Strong End-System Model (RFC1122) or 
strict multihoming behavior on a Cisco router? Or would that break 
routing functionality (and thus would explain why I haven't seen it 
anywhere in the manuals)?

 From the rfc:

There are two key requirement issues related to multihoming:

             (A)  A host MAY silently discard an incoming datagram whose
                  destination address does not correspond to the physical
                  interface through which it is received.

             (B)  A host MAY restrict itself to sending (non-source-
                  routed) IP datagrams only through the physical
                  interface that corresponds to the IP source address of
                  the datagrams.


             DISCUSSION:
                  Internet host implementors have used two different
                  conceptual models for multihoming, briefly summarized
                  in the following discussion.  This document takes no
                  stand on which model is preferred; each seems to have a
                  place.  This ambivalence is reflected in the issues (A)
                  and (B) being optional.

                  o    Strong ES Model

                       The Strong ES (End System, i.e., host) model
                       emphasizes the host/gateway (ES/IS) distinction,
                       and would therefore substitute MUST for MAY in
                       issues (A) and (B) above.  It tends to model a
                       multihomed host as a set of logical hosts within
                       the same physical host.

			 o    Weak ES Model

                       This view de-emphasizes the ES/IS distinction, and
                       would therefore substitute MUST NOT for MAY in
                       issues (A) and (B).  This model may be the more
                       natural one for hosts that wiretap gateway routing
                       protocols, and is necessary for hosts that have
                       embedded gateway functionality.

Regards,

Marcel

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004
 




More information about the cisco-nsp mailing list