Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!ox.com!math.fu-berlin.de!unidui!unido!laura!deins.Informatik.Uni-Dortmund.DE!rv
From: rv@deins.Informatik.Uni-Dortmund.DE (Ruediger Volk)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Multiple Interface Addresses
Message-ID: <3180@laura.UUCP>
Date: 13 Apr 91 22:10:04 GMT
References: <1991Apr12.121846.20016@nrcnet0.nrc.ca>
Sender: news@laura.UUCP
Reply-To: rv@deins.Informatik.Uni-Dortmund.DE (Ruediger Volk)
Organization: University of Dortmund, Germany
Lines: 32

In article <1991Apr12.121846.20016@nrcnet0.nrc.ca>, RRH@VM.NRC.CA writes:
|> J. Bashinski  mentions a technique for having multiple addresses on  one
|> port by using secondary options. i.e
|> 
|>     interface ethernet 0
|>     ip address 131.108.1.1  255.255.255.0
|>     ip address 131.108.2.1  255.255.255.0  secondary
|>     ip address 131.108.3.1  255.255.255.0  secondary
|> 
|> We have been using the following technique (cause at time there was no
|> secondary option).
|> 
|>     ip route 131.108.2.1 ethernet 0
|>     ip route 131.108.3.1 ethernet 0
|> 
|> It does the job  but which technique is better ?
The interface routes (the last alternative) are a quite old feature, so
I guess the secondary addresses are "better" :-)
In fact I have changed some interface routes to secondary addresses in my
configuration (though not on Ethernet but on X.25 interfaces); being able
to define an address for the router itself on the additional network is
useful - though it's still not perfect: the router does not use the
secondary address when sending packets out - which inhibits the use
of routing protocols on networks joined over secondary address assignments
(probably not so much a problem with LAN interfaces - but we are missing
this for our X.25 configuration; well, probably the best way to tackle
this specific problem could be using a different address binding 
architecture for the RFC877 encapsulation).

Ruediger Volk

rv@Informatik.Uni-Dortmund.DE