arp table - same mac address shows two ip addresses

arp table - same mac address shows two ip addresses

[Leroy Tennison]

KDEuMi4zLjQgaXMgYW4gYXJiaXRyYXJ5IHJlcGxhY2VtZW50IGJ1dCBkb2Vzbid0IGFmZmVjdCB0
aGUgYmFzaWMgaXNzdWUpICBXaGF0IGlzIGNhdXNpbmcgdGhpcz8gIFRoZSBzeXN0ZW1zIGluIHF1
ZXN0aW9uIGhhdmUgb25seSBvbmUgaW50ZXJmYWNlIHBlciBzdWJuZXQgYnV0IGJvdGggc3lzdGVt
cyBoYXZlIG11bHRpcGxlIE5JQ3Mgd2hpY2ggYXJlIG9uIHRoZSBzYW1lIHN1Ym5ldHMuICBXaGF0
IEkgbWVhbiBpcyB0aGlzOiAgb24gYm90aCBzeXN0ZW1zIE5JQzEgY29ubmVjdHMgdG8gc3VibmV0
IDEsIE5JQzIgdG8gc3VibmV0IDIgYW5kIHNvIG9uIGZvciBmaXZlIE5JQ3MgYW5kIGRpZmZlcmVu
dCBzdWJuZXRzLiAgVGhlIHN1Ym5ldHMgZG8gaGF2ZSBkaWZmZXJlbnQgSVAgcmFuZ2VzIChubyBv
dmVybGFwKS4gIDEwLjIyMi4xMDkuMyBkb2VzIGhhcHBlbiB0byBiZSBvbiB0aGUgc2FtZSBzeXN0
ZW0gYXMgMS4yLjMuNCBidXQgaXQgZG9lc24ndCBoYXZlIHRoZSBzYW1lIG1hYyBhZGRyZXNzIGFu
ZCBpdCBpcyBhIHBoeXNpY2FsIGludGVyZmFjZS4NCg0KQWRkcmVzcyAgICAgICAgICAgICBIV1R5
cGUgICBIV0FkZHJlc3MgICAgICAgICAgIEZsYWdzICBNYXNrICAgSWZhY2UNCjEwLjIyMi4xMDku
MyAgICAgZXRoZXIgICAgICAgICAgYmM6MzA6NWI6YTY6YzQ6YmYgIEMgICAgICAgICAgICAgICAg
ICAgIGV0aDkNCi4NCi4NCi4NCjEuMi4zLjQgICAgICAgICAgICAgICBldGhlciAgICAgICAgIGJj
OjMwOjViOmE2OmM0OmJmICBDICAgICAgICAgICAgICAgICAgICBldGg5DQoNCg0KTGVyb3kgVGVu
bmlzb24NCk5ldHdvcmsgSW5mb3JtYXRpb24vQ3liZXIgU2VjdXJpdHkgU3BlY2lhbGlzdA0KRTog
bGVyb3lAZGF0YXZvaWNlaW50LmNvbQ0KMjIyMCBCdXNoIERyDQpNY0tpbm5leSwgVGV4YXMNCjc1
MDcwDQp3d3cuZGF0YXZvaWNlaW50LmNvbQ0KVFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzZW50IG9u
IGJlaGFsZg0Kb2YgYSBjb21wYW55IHRoYXQgaXMgcGFydCBvZiB0aGUgSGFycmlzIE9wZXJhdGlu
ZyBHcm91cCBvZg0KQ29uc3RlbGxhdGlvbiBTb2Z0d2FyZSBJbmMuIFRoZXNlIGNvbXBhbmllcyBh
cmUgbGlzdGVkDQpoZXJlDQouDQpJZiB5b3UgcHJlZmVyIG5vdCB0byBiZSBjb250YWN0ZWQgYnkg
SGFycmlzDQpPcGVyYXRpbmcgR3JvdXANCnBsZWFzZSBub3RpZnkgdXMNCi4NClRoaXMgbWVzc2Fn
ZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgdGhlDQppbmRpdmlkdWFsIG9yIGVudGl0eSB0
byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIFRoaXMgY29tbXVuaWNhdGlvbg0KbWF5IGNvbnRhaW4g
aW5mb3JtYXRpb24gdGhhdCBpcyBwcm9wcmlldGFyeSwgcHJpdmlsZWdlZCBvcg0KY29uZmlkZW50
aWFsIG9yIG90aGVyd2lzZSBsZWdhbGx5IGV4ZW1wdCBmcm9tIGRpc2Nsb3N1cmUuIElmIHlvdSBh
cmUNCm5vdCB0aGUgbmFtZWQgYWRkcmVzc2VlLCB5b3UgYXJlIG5vdCBhdXRob3JpemVkIHRvIHJl
YWQsIHByaW50LA0KcmV0YWluLCBjb3B5IG9yIGRpc3NlbWluYXRlIHRoaXMgbWVzc2FnZSBvciBh
bnkgcGFydCBvZiBpdC4gSWYgeW91DQpoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJv
ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl
bGV0ZSBhbGwgY29waWVzIG9mIHRoZQ0KbWVzc2FnZS4NCg0K

Re: arp table - same mac address shows two ip addresses

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On 10/16/2018 04:31 PM, Leroy Tennison wrote:
> (1.2.3.4 is an arbitrary replacement but doesn't affect the basic issue) 
> What is causing this?  The systems in question have only one interface per 
> subnet but both systems have multiple NICs which are on the same subnets. 
> What I mean is this:  on both systems NIC1 connects to subnet 1, NIC2 to 
> subnet 2 and so on for five NICs and different subnets.  The subnets do 
> have different IP ranges (no overlap).  10.222.109.3 does happen to be 
> on the same system as 1.2.3.4 but it doesn't have the same mac address 
> and it is a physical interface.

I can't tell for sure.  Are the NICs connected to the same L2 network 
segment / broadcast domain?

This almost sounds as if NIC1 is responding to ARP requests for NIC{2..5}.

> Address        HWType   HWAddress           Flags   Mask   Iface
> 10.222.109.3   ether    bc:30:5b:a6:c4:bf   C              eth9
> 1.2.3.4        ether    bc:30:5b:a6:c4:bf   C              eth9

Unfortunately this doesn't clearly indicate if the NICs are using the 
same L2 network segment / broadcast domain or not.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: arp table - same mac address shows two ip addresses

[Erik Auerswald]

Hi,

On Tue, Oct 16, 2018 at 05:00:37PM -0600, Grant Taylor wrote:
> On 10/16/2018 04:31 PM, Leroy Tennison wrote:
> >(1.2.3.4 is an arbitrary replacement but doesn't affect the basic
> >issue) What is causing this?  The systems in question have only
> >one interface per subnet but both systems have multiple NICs which
> >are on the same subnets. What I mean is this:  on both systems
> >NIC1 connects to subnet 1, NIC2 to subnet 2 and so on for five
> >NICs and different subnets.  The subnets do have different IP
> >ranges (no overlap).  10.222.109.3 does happen to be on the same
> >system as 1.2.3.4 but it doesn't have the same mac address and it
> >is a physical interface.
> 
> I can't tell for sure.  Are the NICs connected to the same L2
> network segment / broadcast domain?
> 
> This almost sounds as if NIC1 is responding to ARP requests for NIC{2..5}.

Linux may do that...

> >Address        HWType   HWAddress           Flags   Mask   Iface
> >10.222.109.3   ether    bc:30:5b:a6:c4:bf   C              eth9
> >1.2.3.4        ether    bc:30:5b:a6:c4:bf   C              eth9
> 
> Unfortunately this doesn't clearly indicate if the NICs are using
> the same L2 network segment / broadcast domain or not.

...especially if the NICs are in different broadcast domains (VLANs).

I am not saying that is the case here, just that it might be the case.
That would be an instance of the "weak host model" problem (see RFC 1122,
section 3.3.4.2, "Weak ES Model"). The problem is primarily that some
expectations about network separation are not fulfilled by the end-system.

Thanks,
Erik
-- 
It's impossible to learn very much by simply sitting in a lecture,
or even by simply doing problems that are assigned.
                        -- Richard P. Feynman

Re: arp table - same mac address shows two ip addresses

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

On 10/17/2018 02:43 AM, Erik Auerswald wrote:
> Linux may do that...
> 
> ...especially if the NICs are in different broadcast domains (VLANs).

I was thinking that it would happen if the NICs were in the /same/ 
broadcast domain.  I.e. NIC1 heard saw an ARP for NIC3's IP before NIC3 
saw it.  Thus NIC1 and NIC3 (and likely the others) were in the same 
broadcast domain.

I can't think of another reason why NICs would see ARP requests for IPs 
bound to other NICs if they weren't in a common broadcast domain.  - 
Sure there are other things, but that would usually involve issues on 
the sending side or magic smoke in the middle.

> I am not saying that is the case here, just that it might be the case.

If the NICs are connected to a common broadcast domain, then I think 
chances are good that it's the "weak host model" problem.

> That would be an instance of the "weak host model" problem (see RFC 1122, 
> section 3.3.4.2, "Weak ES Model"). The problem is primarily that some 
> expectations about network separation are not fulfilled by the end-system.

(I need to brush up on RFC 1122 § 3.3.4.2.  Thank you for the reference 
point.)

I don't know that it's that end systems don't / can't fulfill the 
network separation.  I think that Linux can be configured to (better) 
fulfill it via Kernel tunables and / or a combination of ARPTables / 
IPTables.

I recently read that IPs are supposed to belong to hosts, not individual 
NICs there on, in TCP/IP Illustrated - Volume 1 - Second Edition.  This 
jives with what I've commonly experienced.

I think part of the problem is a disconnect in what people expect and 
what TCP/IP specifications state.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: arp table - same mac address shows two ip addresses

[Erik Auerswald]

Hi,

On Wed, Oct 17, 2018 at 10:49:53AM -0600, Grant Taylor wrote:
> On 10/17/2018 02:43 AM, Erik Auerswald wrote:
> >Linux may do that...
> >
> >...especially if the NICs are in different broadcast domains (VLANs).
> 
> I was thinking that it would happen if the NICs were in the /same/
> broadcast domain.  I.e. NIC1 heard saw an ARP for NIC3's IP before
> NIC3 saw it.  Thus NIC1 and NIC3 (and likely the others) were in the
> same broadcast domain.
> 
> I can't think of another reason why NICs would see ARP requests for
> IPs bound to other NICs if they weren't in a common broadcast
> domain.  - Sure there are other things, but that would usually
> involve issues on the sending side or magic smoke in the middle.

One example I experienced are misconfigured end-systems using IP addresses
from network A in the broadcast domain of network B. The gateway for both
networks was based on the Linux kernel. Misconfigured hosts were able to
reach their gateway without problems (the ARP request was answered from the
"wrong" interface, any interface accepts any IP destined for the host).

> >I am not saying that is the case here, just that it might be the case.
> 
> If the NICs are connected to a common broadcast domain, then I think
> chances are good that it's the "weak host model" problem.
> 
> >That would be an instance of the "weak host model" problem (see
> >RFC 1122, section 3.3.4.2, "Weak ES Model"). The problem is
> >primarily that some expectations about network separation are not
> >fulfilled by the end-system.
> 
> (I need to brush up on RFC 1122 § 3.3.4.2.  Thank you for the
> reference point.)
> 
> I don't know that it's that end systems don't / can't fulfill the
> network separation.  I think that Linux can be configured to
> (better) fulfill it via Kernel tunables and / or a combination of
> ARPTables / IPTables.

AFAIK one can configure ARP to separate more, but not competely. Using
bridges is said to allow for more separation, but I have not yet tested
this.

> I recently read that IPs are supposed to belong to hosts, not
> individual NICs there on, in TCP/IP Illustrated - Volume 1 - Second
> Edition.  This jives with what I've commonly experienced.

For version 4, but this changes with version 6. ;-)

> I think part of the problem is a disconnect in what people expect
> and what TCP/IP specifications state.

I'd say the same. But part of the problem is that the weak host model
is a bit more surprising than the strong host model. In my experience
this is especially true when a weak host is used as a router.

Thanks,
Erik
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
                        -- Brian W. Kernighan

Re: arp table - same mac address shows two ip addresses

[Leroy Tennison]

RXJpayBBdWVyc3dhbGQgd3JvdGUgIk9uZSBleGFtcGxlIEkgZXhwZXJpZW5jZWQgYXJlIG1pc2Nv
bmZpZ3VyZWQgZW5kLXN5c3RlbXMgLi4uIiAtIENvdWxkIHlvdSBleHBsYWluIHRoaXMgYSBsaXR0
bGUgbW9yZSB0aG9yb3VnaGx5PyAgQXJlIHlvdSBzYXlpbmcgdGhhdCwgZ2l2ZW4gYSBzeXN0ZW0g
d2l0aCAxNzIuMTYuMzAuMSBhZGRyZXNzIG9uIG5ldHdvcmsgQSBhbmQgMTAuMjAuMzAuMSBhZGRy
ZXNzIG9uIG5ldHdvcmsgQiB0aGF0IGFuIGFwcGxpY2F0aW9uIGlzIHNlbmRpbmcgdG8gdGhlIEEg
bmV0d29yayB1c2luZyB0aGUgMTAuLi4gYWRkcmVzcyByYXRoZXIgdGhhbiB0aGUgMTcyLi4uIGFk
ZHJlc3M/ICBJZiBzbyB3YXMgdGhlIGFwcGxpY2F0aW9uIGNvbmZpZ3VyZWQgdG8gdXNlIGEgcGFy
dGljdWxhciBJUCBhZGRyZXNzPw0KDQpZb3UgYWxzbyB3cm90ZSAiVGhlIGdhdGV3YXkgZm9yIGJv
dGggbmV0d29ya3Mgd2FzIGJhc2VkIG9uIHRoZSBMaW51eCBrZXJuZWwuIiAgQ291bGQgeW91IGJl
IGEgbGl0dGxlIG1vcmUgc3BlY2lmaWM/ICBXZXJlIG11bHRpcGxlIHJvdXRpbmcgdGFibGVzIGJl
aW5nIHVzZWQgYWxvbmcgd2l0aCAnaXAgcnVsZScgZW50cmllcyBvciB3YXMgaXQgYSAibmV4dGhv
cCB3aXRoIHdlaWdodHMiIHNpdHVhdGlvbiBvciBzb21ldGhpbmcgZWxzZT8NCg0KSSdtIGp1c3Qg
dHJ5aW5nIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSBzaXR1YXRpb25zIHlvdSBlbmNvdW50ZXJl
ZCBzbyBJIGNhbiByZWNvZ25pemUgdGhlbSBpbiB0aGUgZnV0dXJlLg0KDQoNCg0KTGVyb3kgVGVu
bmlzb24NCk5ldHdvcmsgSW5mb3JtYXRpb24vQ3liZXIgU2VjdXJpdHkgU3BlY2lhbGlzdA0KRTog
bGVyb3lAZGF0YXZvaWNlaW50LmNvbQ0KMjIyMCBCdXNoIERyDQpNY0tpbm5leSwgVGV4YXMNCjc1
MDcwDQp3d3cuZGF0YXZvaWNlaW50LmNvbQ0KVFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzZW50IG9u
IGJlaGFsZg0Kb2YgYSBjb21wYW55IHRoYXQgaXMgcGFydCBvZiB0aGUgSGFycmlzIE9wZXJhdGlu
ZyBHcm91cCBvZg0KQ29uc3RlbGxhdGlvbiBTb2Z0d2FyZSBJbmMuIFRoZXNlIGNvbXBhbmllcyBh
cmUgbGlzdGVkDQpoZXJlDQouDQpJZiB5b3UgcHJlZmVyIG5vdCB0byBiZSBjb250YWN0ZWQgYnkg
SGFycmlzDQpPcGVyYXRpbmcgR3JvdXANCnBsZWFzZSBub3RpZnkgdXMNCi4NClRoaXMgbWVzc2Fn
ZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgdGhlDQppbmRpdmlkdWFsIG9yIGVudGl0eSB0
byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIFRoaXMgY29tbXVuaWNhdGlvbg0KbWF5IGNvbnRhaW4g
aW5mb3JtYXRpb24gdGhhdCBpcyBwcm9wcmlldGFyeSwgcHJpdmlsZWdlZCBvcg0KY29uZmlkZW50
aWFsIG9yIG90aGVyd2lzZSBsZWdhbGx5IGV4ZW1wdCBmcm9tIGRpc2Nsb3N1cmUuIElmIHlvdSBh
cmUNCm5vdCB0aGUgbmFtZWQgYWRkcmVzc2VlLCB5b3UgYXJlIG5vdCBhdXRob3JpemVkIHRvIHJl
YWQsIHByaW50LA0KcmV0YWluLCBjb3B5IG9yIGRpc3NlbWluYXRlIHRoaXMgbWVzc2FnZSBvciBh
bnkgcGFydCBvZiBpdC4gSWYgeW91DQpoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJv
ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRl
bGV0ZSBhbGwgY29waWVzIG9mIHRoZQ0KbWVzc2FnZS4NCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KRnJvbTogbGFydGMtb3duZXJAdmdlci5rZXJuZWwub3JnIDxs
YXJ0Yy1vd25lckB2Z2VyLmtlcm5lbC5vcmc+IG9uIGJlaGFsZiBvZiBFcmlrIEF1ZXJzd2FsZCA8
YXVlcnN3YWxAdW5peC1hZy51bmkta2wuZGU+DQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxOCwg
MjAxOCAyOjEwIEFNDQpUbzogbGFydGNAdmdlci5rZXJuZWwub3JnDQpDYzogR3JhbnQgVGF5bG9y
DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBhcnAgdGFibGUgLSBzYW1lIG1hYyBhZGRyZXNzIHNo
b3dzIHR3byBpcCBhZGRyZXNzZXMNCg0KSGksDQoNCk9uIFdlZCwgT2N0IDE3LCAyMDE4IGF0IDEw
OjQ5OjUzQU0gLTA2MDAsIEdyYW50IFRheWxvciB3cm90ZToNCj4gT24gMTAvMTcvMjAxOCAwMjo0
MyBBTSwgRXJpayBBdWVyc3dhbGQgd3JvdGU6DQo+ID5MaW51eCBtYXkgZG8gdGhhdC4uLg0KPiA+
DQo+ID4uLi5lc3BlY2lhbGx5IGlmIHRoZSBOSUNzIGFyZSBpbiBkaWZmZXJlbnQgYnJvYWRjYXN0
IGRvbWFpbnMgKFZMQU5zKS4NCj4NCj4gSSB3YXMgdGhpbmtpbmcgdGhhdCBpdCB3b3VsZCBoYXBw
ZW4gaWYgdGhlIE5JQ3Mgd2VyZSBpbiB0aGUgL3NhbWUvDQo+IGJyb2FkY2FzdCBkb21haW4uICBJ
LmUuIE5JQzEgaGVhcmQgc2F3IGFuIEFSUCBmb3IgTklDMydzIElQIGJlZm9yZQ0KPiBOSUMzIHNh
dyBpdC4gIFRodXMgTklDMSBhbmQgTklDMyAoYW5kIGxpa2VseSB0aGUgb3RoZXJzKSB3ZXJlIGlu
IHRoZQ0KPiBzYW1lIGJyb2FkY2FzdCBkb21haW4uDQo+DQo+IEkgY2FuJ3QgdGhpbmsgb2YgYW5v
dGhlciByZWFzb24gd2h5IE5JQ3Mgd291bGQgc2VlIEFSUCByZXF1ZXN0cyBmb3INCj4gSVBzIGJv
dW5kIHRvIG90aGVyIE5JQ3MgaWYgdGhleSB3ZXJlbid0IGluIGEgY29tbW9uIGJyb2FkY2FzdA0K
PiBkb21haW4uICAtIFN1cmUgdGhlcmUgYXJlIG90aGVyIHRoaW5ncywgYnV0IHRoYXQgd291bGQg
dXN1YWxseQ0KPiBpbnZvbHZlIGlzc3VlcyBvbiB0aGUgc2VuZGluZyBzaWRlIG9yIG1hZ2ljIHNt
b2tlIGluIHRoZSBtaWRkbGUuDQoNCk9uZSBleGFtcGxlIEkgZXhwZXJpZW5jZWQgYXJlIG1pc2Nv
bmZpZ3VyZWQgZW5kLXN5c3RlbXMgdXNpbmcgSVAgYWRkcmVzc2VzDQpmcm9tIG5ldHdvcmsgQSBp
biB0aGUgYnJvYWRjYXN0IGRvbWFpbiBvZiBuZXR3b3JrIEIuIFRoZSBnYXRld2F5IGZvciBib3Ro
DQpuZXR3b3JrcyB3YXMgYmFzZWQgb24gdGhlIExpbnV4IGtlcm5lbC4gTWlzY29uZmlndXJlZCBo
b3N0cyB3ZXJlIGFibGUgdG8NCnJlYWNoIHRoZWlyIGdhdGV3YXkgd2l0aG91dCBwcm9ibGVtcyAo
dGhlIEFSUCByZXF1ZXN0IHdhcyBhbnN3ZXJlZCBmcm9tIHRoZQ0KIndyb25nIiBpbnRlcmZhY2Us
IGFueSBpbnRlcmZhY2UgYWNjZXB0cyBhbnkgSVAgZGVzdGluZWQgZm9yIHRoZSBob3N0KS4NCg0K
PiA+SSBhbSBub3Qgc2F5aW5nIHRoYXQgaXMgdGhlIGNhc2UgaGVyZSwganVzdCB0aGF0IGl0IG1p
Z2h0IGJlIHRoZSBjYXNlLg0KPg0KPiBJZiB0aGUgTklDcyBhcmUgY29ubmVjdGVkIHRvIGEgY29t
bW9uIGJyb2FkY2FzdCBkb21haW4sIHRoZW4gSSB0aGluaw0KPiBjaGFuY2VzIGFyZSBnb29kIHRo
YXQgaXQncyB0aGUgIndlYWsgaG9zdCBtb2RlbCIgcHJvYmxlbS4NCj4NCj4gPlRoYXQgd291bGQg
YmUgYW4gaW5zdGFuY2Ugb2YgdGhlICJ3ZWFrIGhvc3QgbW9kZWwiIHByb2JsZW0gKHNlZQ0KPiA+
UkZDIDExMjIsIHNlY3Rpb24gMy4zLjQuMiwgIldlYWsgRVMgTW9kZWwiKS4gVGhlIHByb2JsZW0g
aXMNCj4gPnByaW1hcmlseSB0aGF0IHNvbWUgZXhwZWN0YXRpb25zIGFib3V0IG5ldHdvcmsgc2Vw
YXJhdGlvbiBhcmUgbm90DQo+ID5mdWxmaWxsZWQgYnkgdGhlIGVuZC1zeXN0ZW0uDQo+DQo+IChJ
IG5lZWQgdG8gYnJ1c2ggdXAgb24gUkZDIDExMjIgwqcgMy4zLjQuMi4gIFRoYW5rIHlvdSBmb3Ig
dGhlDQo+IHJlZmVyZW5jZSBwb2ludC4pDQo+DQo+IEkgZG9uJ3Qga25vdyB0aGF0IGl0J3MgdGhh
dCBlbmQgc3lzdGVtcyBkb24ndCAvIGNhbid0IGZ1bGZpbGwgdGhlDQo+IG5ldHdvcmsgc2VwYXJh
dGlvbi4gIEkgdGhpbmsgdGhhdCBMaW51eCBjYW4gYmUgY29uZmlndXJlZCB0bw0KPiAoYmV0dGVy
KSBmdWxmaWxsIGl0IHZpYSBLZXJuZWwgdHVuYWJsZXMgYW5kIC8gb3IgYSBjb21iaW5hdGlvbiBv
Zg0KPiBBUlBUYWJsZXMgLyBJUFRhYmxlcy4NCg0KQUZBSUsgb25lIGNhbiBjb25maWd1cmUgQVJQ
IHRvIHNlcGFyYXRlIG1vcmUsIGJ1dCBub3QgY29tcGV0ZWx5LiBVc2luZw0KYnJpZGdlcyBpcyBz
YWlkIHRvIGFsbG93IGZvciBtb3JlIHNlcGFyYXRpb24sIGJ1dCBJIGhhdmUgbm90IHlldCB0ZXN0
ZWQNCnRoaXMuDQoNCj4gSSByZWNlbnRseSByZWFkIHRoYXQgSVBzIGFyZSBzdXBwb3NlZCB0byBi
ZWxvbmcgdG8gaG9zdHMsIG5vdA0KPiBpbmRpdmlkdWFsIE5JQ3MgdGhlcmUgb24sIGluIFRDUC9J
UCBJbGx1c3RyYXRlZCAtIFZvbHVtZSAxIC0gU2Vjb25kDQo+IEVkaXRpb24uICBUaGlzIGppdmVz
IHdpdGggd2hhdCBJJ3ZlIGNvbW1vbmx5IGV4cGVyaWVuY2VkLg0KDQpGb3IgdmVyc2lvbiA0LCBi
dXQgdGhpcyBjaGFuZ2VzIHdpdGggdmVyc2lvbiA2LiA7LSkNCg0KPiBJIHRoaW5rIHBhcnQgb2Yg
dGhlIHByb2JsZW0gaXMgYSBkaXNjb25uZWN0IGluIHdoYXQgcGVvcGxlIGV4cGVjdA0KPiBhbmQg
d2hhdCBUQ1AvSVAgc3BlY2lmaWNhdGlvbnMgc3RhdGUuDQoNCkknZCBzYXkgdGhlIHNhbWUuIEJ1
dCBwYXJ0IG9mIHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIHdlYWsgaG9zdCBtb2RlbA0KaXMgYSBi
aXQgbW9yZSBzdXJwcmlzaW5nIHRoYW4gdGhlIHN0cm9uZyBob3N0IG1vZGVsLiBJbiBteSBleHBl
cmllbmNlDQp0aGlzIGlzIGVzcGVjaWFsbHkgdHJ1ZSB3aGVuIGEgd2VhayBob3N0IGlzIHVzZWQg
YXMgYSByb3V0ZXIuDQoNClRoYW5rcywNCkVyaWsNCi0tDQpEZWJ1Z2dpbmcgaXMgdHdpY2UgYXMg
aGFyZCBhcyB3cml0aW5nIHRoZSBjb2RlIGluIHRoZSBmaXJzdCBwbGFjZS4NClRoZXJlZm9yZSwg
aWYgeW91IHdyaXRlIHRoZSBjb2RlIGFzIGNsZXZlcmx5IGFzIHBvc3NpYmxlLCB5b3UgYXJlLA0K
YnkgZGVmaW5pdGlvbiwgbm90IHNtYXJ0IGVub3VnaCB0byBkZWJ1ZyBpdC4NCiAgICAgICAgICAg
ICAgICAgICAgICAgIC0tIEJyaWFuIFcuIEtlcm5pZ2hhbg0K

Re: arp table - same mac address shows two ip addresses

[Erik Auerswald]

Hi Leroy,

On Thu, Oct 18, 2018 at 02:05:20PM +0000, Leroy Tennison wrote:
> Erik Auerswald wrote "One example I experienced are misconfigured end-systems ..." - Could you explain this a little more thoroughly?  Are you saying that, given a system with 172.16.30.1 address on network A and 10.20.30.1 address on network B that an application is sending to the A network using the 10... address rather than the 172... address?  If so was the application configured to use a particular IP address?

What I meant was a host configured for network A but connected to
network B:

ES 10.20.30.47/24 <-----> GW Iface 172.16.30.1/24

The gateway (GW) did have the IP address 10.20.30.1/24 on another
interface, and the end-system (ES) used that IP address as its default
gateway. ES and GW could ping each other. The GW was a PC with Linux
kernel and GNU userland. Thus the "application" on the multi-NIC PC
was Linux.

> You also wrote "The gateway for both networks was based on the Linux kernel."  Could you be a little more specific?  Were multiple routing tables being used along with 'ip rule' entries or was it a "nexthop with weights" situation or something else?

Just one routing table. A PC with several NICs, GNU/Linux, and
ipforwarding acting as a "router".

> I'm just trying to better understand the situations you encountered so I can recognize them in the future.

In the above mentioned situation, of which I have forgotten most of
the details, end-systems that should no longer have been able to reach
their old Linux-based default gateway, because IP addresses and VLANs
were changed, but the end-systems used the pre-change configuration,
still had full network connectivity.

When using Linux on a PC with several NICs, expect the unexpected. ;)

Thanks,
Erik
-- 
Do things that have never been done before.
                        -- Russell Kirsch

Re: arp table - same mac address shows two ip addresses

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

On 10/18/2018 01:10 AM, Erik Auerswald wrote:
> Hi,

Hi,

> One example I experienced are misconfigured end-systems using IP addresses 
> from network A in the broadcast domain of network B. The gateway for both 
> networks was based on the Linux kernel. Misconfigured hosts were able 
> to reach their gateway without problems (the ARP request was answered 
> from the "wrong" interface, any interface accepts any IP destined for 
> the host).

I feel like there are details pertinent to the conversation that I'm not 
privy to.  Including shared or separate broadcast domains, routing, IP 
addressing scheme, etc.  Most of which would need to be known from both 
ends of the communications to be able to even speculate.

> AFAIK one can configure ARP to separate more, but not competely. Using 
> bridges is said to allow for more separation, but I have not yet tested 
> this.


I'm going to be doing some testing in this area, partially around this 
conversation and other very similar conversations.

> For version 4, but this changes with version 6. ;-)

Would you please elaborate?

I've not run across anything indicating such.  I've not gotten far 
enough in the reading that I'm doing to delve this deep into IPv6 yet.

> I'd say the same. But part of the problem is that the weak host model 
> is a bit more surprising than the strong host model. In my experience 
> this is especially true when a weak host is used as a router.

I assume that the weak host (end system) model is easier to code for, 
thus more likely to be used on single homed hosts (end systems) a they 
are the vast majority compared to multi-homed hosts (E.S.).

> Thanks,

Thank you!  Good discussion that is banging some of my brain cells together.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: arp table - same mac address shows two ip addresses

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

On 10/18/2018 09:12 AM, Erik Auerswald wrote:
> What I meant was a host configured for network A but connected to 
> network B:
> 
> ES 10.20.30.47/24 <-----> GW Iface 172.16.30.1/24
> 
> The gateway (GW) did have the IP address 10.20.30.1/24 on another 
> interface, and the end-system (ES) used that IP address as its default 
> gateway. ES and GW could ping each other. The GW was a PC with Linux 
> kernel and GNU userland. Thus the "application" on the multi-NIC PC 
> was Linux.
> 
> Just one routing table. A PC with several NICs, GNU/Linux, and 
> ipforwarding acting as a "router".
> 
> In the above mentioned situation, of which I have forgotten most of 
> the details, end-systems that should no longer have been able to reach 
> their old Linux-based default gateway, because IP addresses and VLANs 
> were changed, but the end-systems used the pre-change configuration, 
> still had full network connectivity.

I'll admit that such is a non-intuitive behavior.

However I've learned that such is the expected behavior of a "weak end 
system", which Linux does by default.  I say "by default" because I 
think it's possible to change Linux's behavior.

> When using Linux on a PC with several NICs, expect the unexpected. ;)

Or, change the default so that you get different results.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: arp table - same mac address shows two ip addresses

[Erik Auerswald]

Hi,

On Thu, Oct 18, 2018 at 09:16:12AM -0600, Grant Taylor wrote:
> On 10/18/2018 01:10 AM, Erik Auerswald wrote:
> 
> >One example I experienced are misconfigured end-systems using IP
> >addresses from network A in the broadcast domain of network B. The
> >gateway for both networks was based on the Linux kernel.
> >Misconfigured hosts were able to reach their gateway without
> >problems (the ARP request was answered from the "wrong" interface,
> >any interface accepts any IP destined for the host).
> 
> I feel like there are details pertinent to the conversation that I'm
> not privy to.  Including shared or separate broadcast domains,
> routing, IP addressing scheme, etc.  Most of which would need to be
> known from both ends of the communications to be able to even
> speculate.

The original question was a bit scarce on details, thus I substituted
pertinent experience of my own. This is not necessarily easy to follow. ;)

> >AFAIK one can configure ARP to separate more, but not competely.
> >Using bridges is said to allow for more separation, but I have not
> >yet tested this.
> 
> I'm going to be doing some testing in this area, partially around
> this conversation and other very similar conversations.

Please tell us about your results.

> >For version 4, but this changes with version 6. ;-)
> 
> Would you please elaborate?

In IPv6, addresses are assigned to interfaces. This is obvious with
link-local addresses, but true for differently scoped addresses as
well. I am sorry, but I do not know the RFC off the top of my head.

OK, had to search...

RFC 8200, Internet Protocol, Version 6 (IPv6) Specification, section 2:

    "interface    a node's attachment to a link."
    "address      an IPv6-layer identifier for an interface or a set of
                  interfaces."

RFC 4291, IP Version 6 Addressing Architecture, section 2.1:

    "IPv6 addresses of all types are assigned to interfaces, not nodes."

> I've not run across anything indicating such.  I've not gotten far
> enough in the reading that I'm doing to delve this deep into IPv6
> yet.

IPv6 is an interesting rabbit hole to dive into. ;)

> >I'd say the same. But part of the problem is that the weak host
> >model is a bit more surprising than the strong host model. In my
> >experience this is especially true when a weak host is used as a
> >router.
> 
> I assume that the weak host (end system) model is easier to code
> for, thus more likely to be used on single homed hosts (end systems)
> a they are the vast majority compared to multi-homed hosts (E.S.).

They might even be a bit simpler to use without a 100% correct networking
configuration. ;)

> Thank you!  Good discussion that is banging some of my brain cells together.

Likewise. :)

Thanks,
Erik
-- 
I think of math as a splendid way to learn to think straight.
                        -- Bjarne Stroustrup

Re: arp table - same mac address shows two ip addresses

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

On 10/18/2018 10:19 AM, Erik Auerswald wrote:
> Hi,

Hi,

> The original question was a bit scarce on details, thus I substituted 
> pertinent experience of my own. This is not necessarily easy to follow. ;)

Fair enough.

> Please tell us about your results.

Will do.

My intention is to create the following configuration using network 
namespaces:

(A)---1---(B)---2---(C)

Where A, B, and C are the test network namespaces and 1 and 2 are vEth 
pairs between them.

I was originally going to start with one test, see if A could 
communicate with B via 2.B.

After your earlier email about hosts moving from one physical network to 
another, I'm going to see if 1 can be configured with 2.A and 
communicate with 2.B via the 1 network.

I'll share the commands I use to create the lab topology and subsequent 
commands to test.

> In IPv6, addresses are assigned to interfaces. This is obvious with 
> link-local addresses, but true for differently scoped addresses as 
> well. I am sorry, but I do not know the RFC off the top of my head.

Fair enough.

> OK, had to search...

;-)

Thank you.

> RFC 8200, Internet Protocol, Version 6 (IPv6) Specification, section 2:
> 
>      "interface    a node's attachment to a link."
>      "address      an IPv6-layer identifier for an interface or a set of
>                    interfaces."
> 
> RFC 4291, IP Version 6 Addressing Architecture, section 2.1:
> 
>      "IPv6 addresses of all types are assigned to interfaces, not nodes."

That is quite succinct.  I'm glad that's codified.

> IPv6 is an interesting rabbit hole to dive into. ;)

Yep.

I've done a fair bit with IPv6 at a shallow level.  I'm now going to be 
reading more and getting into a deeper level.

> They might even be a bit simpler to use without a 100% correct networking 
> configuration. ;)

I think that a single homed machine with a single IPv4 address (ignoring 
loopback) is quite simple.  Even if it has a routing table with more 
than a default gateway.

> Likewise. :)

:-)



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: arp table - same mac address shows two ip addresses

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]

On 10/18/2018 10:45 AM, Grant Taylor wrote:
> My intention is to create the following configuration using network 
> namespaces:
> 
> (A)---1---(B)---2---(C)
> 
> Where A, B, and C are the test network namespaces and 1 and 2 are vEth 
> pairs between them.
> 
> I was originally going to start with one test, see if A could 
> communicate with B via 2.B.

I can get ARP to respond.  But I've not gotten ICMP to function yet.  It 
looks like it may be, funny enough, an ARP issue.  B has two ARP entries 
for A's IP, one from the what it learned from A's ARP request and an 
incomplete entry.  I've not done any more investigation to see if I can 
make this work.  Yet.  }:-)

> After your earlier email about hosts moving from one physical network to 
> another, I'm going to see if 1 can be configured with 2.A and 
> communicate with 2.B via the 1 network.

I think I'm going to need to reconfigure the network a bit to have B 
function as a router with A being on the wrong interface.  Probably 
something like this:

(A)---1---(B)---2---(C)
            |
            3
            |
           (D)

Such that A looks like it moved from the 3 network to the 1 network. 
With C being something on the other side of "the router", B.

> I'll share the commands I use to create the lab topology and subsequent 
> commands to test.

Here are the commands that I used:

ip netns add a
ip netns add b
ip netns add c
ip link add name a type veth peer name b
ip link set dev a netns b
ip link set dev b netns a
ip link add name b type veth peer name c
ip link set dev b netns c
ip link set dev c netns b

ip netns exec a ip link set dev b up
ip netns exec b ip link set dev a up
ip netns exec b ip link set dev c up
ip netns exec c ip link set dev b up
ip netns exec a ip addr add 192.0.2.1/24 dev b
ip netns exec b ip addr add 192.0.2.2/24 dev a
ip netns exec b ip addr add 198.51.100.2/24 dev c
ip netns exec c ip addr add 198.51.100.3/24 dev b
ip netns exec a ip addr add 198.51.100.1/24 dev b

Note:  These commands are a reconstruction for others, I actually have 
aliases and scripts that do much of this behind the scenes for me.  Let 
me know if you can't reproduce something.

Initially, B wouldn't respond to ARP requests from A for 198.51.100.2 
when I tried to ping it.  I found that I had to reset rp_filter to it's 
default value of 0.  —  I keep rp_filter set to 1 on my machines.

Once I had the network namespace TCP/IP stacks set to defaults, B did in 
fact respond to A's ARP request for an IP on the 2nd network.

I've not done any testing beyond that yet.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: arp table - same mac address shows two ip addresses

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

On 10/18/2018 05:38 PM, Grant Taylor wrote:
> I can get ARP to respond.  But I've not gotten ICMP to function yet.  It 
> looks like it may be, funny enough, an ARP issue.  B has two ARP entries 
> for A's IP, one from the what it learned from A's ARP request and an 
> incomplete entry.  I've not done any more investigation to see if I can 
> make this work.  Yet.  }:-)

Okay.  I've done some more investigating and I think it is more of a 
routing issue than /just/ an ARP issue.  In short, the kernel doesn't 
quite know what to do with the traffic destined to one subnet with an 
ARP entry for a different interface than the subnet is on.

> I think I'm going to need to reconfigure the network a bit to have B 
> function as a router with A being on the wrong interface.  Probably 
> something like this:
> 
> (A)---1---(B)---2---(C)
>             |
>             3
>             |
>            (D)
> 
> Such that A looks like it moved from the 3 network to the 1 network. 
> With C being something on the other side of "the router", B.

This wasn't enough.

> Once I had the network namespace TCP/IP stacks set to defaults, B did in 
> fact respond to A's ARP request for an IP on the 2nd network.

rp_filter (Reverse Path Filtering) seems to also protect ARP.

The biggest issue that I can see with arp_filter is that it may disclose 
information about other interfaces on a router.  Where as if arp_filter 
is enabled, then the information won't be leaked.

rp_filter vs arp_filter  rp_filter will only protect incorrect routed 
paths.  arp_filter will protect disclosure / leakage from correct routed 
paths.

I plan on starting to keep arp_filter enabled in addition to rp_filter 
on my machines.  At least until I have a reason not to do so.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: arp table - same mac address shows two ip addresses

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

On 10/17/2018 02:43 AM, Erik Auerswald wrote:
> That would be an instance of the "weak host model" problem (see RFC 1122, 
> section 3.3.4.2, "Weak ES Model").

I read that Mac OS X and Windows Vista (and later) use the strong host 
model by default.

TCP/IP Illustrated - Volume 1 - Second Edition § 5.6.1 on page 222.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: arp table - same mac address shows two ip addresses

[dryden]

[-- Attachment #1.1: Type: text/plain, Size: 1524 bytes --]

On 2018-10-16 22:31, Leroy Tennison wrote:
> (1.2.3.4 is an arbitrary replacement but doesn't affect the basic issue)  What is causing this?  The systems in question have only one interface per subnet but both systems have multiple NICs which are on the same subnets.  What I mean is this:  on both systems NIC1 connects to subnet 1, NIC2 to subnet 2 and so on for five NICs and different subnets.  The subnets do have different IP ranges (no overlap).  10.222.109.3 does happen to be on the same system as 1.2.3.4 but it doesn't have the same mac address and it is a physical interface.
> 
> Address             HWType   HWAddress           Flags  Mask   Iface
> 10.222.109.3     ether          bc:30:5b:a6:c4:bf  C                    eth9
> .
> .
> .
> 1.2.3.4               ether         bc:30:5b:a6:c4:bf  C                    eth9

On Linux (and many other OSes with IPv4 capability) an IPv4 unicast
address belongs to the entire host, not a specific network interface.
With "typical" settings, the kernel will willingly send ICMP redirects.
If it's annoying to see the addresses from "foreign" addresses show in
the MAC table, consider disabling send and receive of redirects on both
systems.

sysctl:
  net.ipv4.conf.*.accept_redirects
  net.ipv4.conf.*.send_redirects

Probably shouldn't do this if either of the hosts forwards IP packets
though [1], particularly if packets IP forward more than once.

[1] Usual caveat here: if you "know what you're doing" then disregard
this sentence.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: arp table - same mac address shows two ip addresses

[dryden]

[-- Attachment #1.1: Type: text/plain, Size: 2018 bytes --]

On 2018-10-21 22:16, dryden@sky-haven.net wrote:
> On 2018-10-16 22:31, Leroy Tennison wrote:
>> (1.2.3.4 is an arbitrary replacement but doesn't affect the basic issue)  What is causing this?  The systems in question have only one interface per subnet but both systems have multiple NICs which are on the same subnets.  What I mean is this:  on both systems NIC1 connects to subnet 1, NIC2 to subnet 2 and so on for five NICs and different subnets.  The subnets do have different IP ranges (no overlap).  10.222.109.3 does happen to be on the same system as 1.2.3.4 but it doesn't have the same mac address and it is a physical interface.
>>
>> Address             HWType   HWAddress           Flags  Mask   Iface
>> 10.222.109.3     ether          bc:30:5b:a6:c4:bf  C                    eth9
>> .
>> .
>> .
>> 1.2.3.4               ether         bc:30:5b:a6:c4:bf  C                    eth9
> 
> On Linux (and many other OSes with IPv4 capability) an IPv4 unicast
> address belongs to the entire host, not a specific network interface.
> With "typical" settings, the kernel will willingly send ICMP redirects.
> If it's annoying to see the addresses from "foreign" addresses show in
> the MAC table, consider disabling send and receive of redirects on both
> systems.
> 
> sysctl:
>   net.ipv4.conf.*.accept_redirects
>   net.ipv4.conf.*.send_redirects
> 
> Probably shouldn't do this if either of the hosts forwards IP packets
> though [1], particularly if packets IP forward more than once.
> 
> [1] Usual caveat here: if you "know what you're doing" then disregard
> this sentence.

... And as usual, while researching this, I found settings that might be
even more relevant to your situation:

...linux/Documentation/networking/ip-sysctl.txt:

- arp_announce
- arp_ignore

which may be more useful for keeping each host's neighbor table "clean"
of foreign addresses, and is probably safer than disabling ICMP redirects.

Cheers, and apologies for replying to my reply.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: arp table - same mac address shows two ip addresses

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On 10/21/2018 04:24 PM, dryden@sky-haven.net wrote:
> ... And as usual, while researching this, I found settings that might be
> even more relevant to your situation:
> 
> ...linux/Documentation/networking/ip-sysctl.txt:

There's LOTS of good information in that file.

> - arp_announce
> - arp_ignore

I am fond of arp_filter (1) and rp_filter (1).

It makes a host behave more like a strong end system (RFC 1122).

> which may be more useful for keeping each host's neighbor table "clean"
> of foreign addresses, and is probably safer than disabling ICMP redirects.

Agreed.

> Cheers, and apologies for replying to my reply.

Apology returned to sender as it was unnecessary.  ;-)



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]