Project

General

Profile

Actions

Task #1396

closed

Identify local endpoint of multicast face

Added by Alex Afanasyev almost 11 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Faces
Target version:
Start date:
03/28/2014
Due date:
% Done:

100%

Estimated time:
7.00 h

Description

Develop a method to display the local endpoint of UDP and Ethernet multicast face,
so that user can distinguish among multicast faces in nfd-status output.


Related issues 1 (0 open1 closed)

Has duplicate NFD - Bug #1430: nfd-status: Failed to present faces and FIB entriesClosed03/31/2014

Actions
Actions #1

Updated by Junxiao Shi almost 11 years ago

I suggest encoding the local address in "username" part of FaceUri:

udp4://192.0.2.1@224.0.23.170:56363
ether://eth1@33:33:01:01:01:01

and deleting the definition for "udp-mcast" and "ether-mcast" schemes in FaceMgmt.

Actions #2

Updated by Davide Pesavento over 10 years ago

Junxiao's suggestion sounds good to me, although we're kind of abusing the URI syntax.

Actions #3

Updated by Junxiao Shi over 10 years ago

  • Subject changed from UDP Multicast face may need additional identification to Identify local endpoint of multicast face
  • Description updated (diff)
  • Start date deleted (03/23/2014)

20140326 conference call decides to give every Face two FaceUris: one for local endpoint, the other for remote endpoint.

This solves the multicast identification problem, and can also distinguish two UDP tunnels from same remote host into two local IPs.

Further questions:


Accepted UNIX stream face does not have a meaningful remote endpoint.

struct sockaddr_un from accept(2) is same as local endpoint, so it's unsuitable as remote FaceUri.

What shall we put as remote FaceUri?

  • empty
  • fd://7, the file descriptor
  • unix:///var/run/nfd.sock, duplicate the local endpoint

Ethernet local endpoint is identified by device name.

Should we define another FaceUri scheme to represent device name, or should we use local MAC address?

  • ether-device://eth1
  • ether://<local-MAC>
Actions #4

Updated by Davide Pesavento over 10 years ago

Junxiao Shi wrote:

Accepted UNIX stream face does not have a meaningful remote endpoint.

struct sockaddr_un from accept(2) is same as local endpoint, so it's unsuitable as remote FaceUri.

What shall we put as remote FaceUri?

'ss -px' can display some information about the peer of a Unix domain socket connection, I don't know where it gets that info from though... it might be some Linux-specific kernel structures...

In my opinion using the fd is sufficient for our purposes (and still gives useful info for debugging e.g. through strace)

Ethernet local endpoint is identified by device name.

Should we define another FaceUri scheme to represent device name, or should we use local MAC address?

Using the local MAC address is ambiguous if virtual interfaces are present. The device name is the only unique identification as far as I know.

Actions #5

Updated by Junxiao Shi over 10 years ago

We have a machine that looks like:

shijunxiao@hostname:~$ ip link
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:25:90:xx:xx:xx brd ff:ff:ff:ff:ff:ff
shijunxiao@hostname:~$ ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:25:90:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 128.196.xx.xx/xx brd 128.196.xx.xx scope global eth0
    inet 10.192.xx.xx/xx brd 10.192.xx.xx scope global eth0:1
shijunxiao@hostname:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:25:90:xx:xx:xx  
          inet addr:128.196.xx.xx  Bcast:128.196.xx.xx  Mask:255.255.xx.xx

eth0:1    Link encap:Ethernet  HWaddr 00:25:90:xx:xx:xx  
          inet addr:10.192.xx.xx  Bcast:10.192.xx.xx  Mask:255.255.xx.xx

ifconfig shows same MAC address on eth0 and eth0:1.

Does virtual interface refer to "eth0:1" of this machine?

If so, we shouldn't even allow Ethernet communication on "eth0:1",
because it would show up as same source MAC address on the receiving end, and cause problem with NDNLP (after adding fragmentation).


If virtual interface refers to something else, please cite a document.

Actions #6

Updated by Davide Pesavento over 10 years ago

Junxiao Shi wrote:

Does virtual interface refer to "eth0:1" of this machine?

Technically those are aliases [1], and while they can be called "virtual" because they don't correspond to any physical interface, I wasn't referring to them. Sorry for being too vague.

What I was talking about was mainly the 802.1q and 802.1ad VLAN interfaces [2], that have the same mac address but different interface names (usually eth0.${vlan_id}).

There are also other types of virtual interfaces (veth, macvlan, bonding, ...) but those have different mac addresses too, so the uniqueness issue doesn't exist there.

[1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/alias.txt

[2] https://wiki.archlinux.org/index.php/VLAN

Actions #7

Updated by Alex Afanasyev over 10 years ago

I would also use device name to identify local Ethernet endpoint (dev:// or what you have mentioned before during the call).

Actions #8

Updated by Davide Pesavento over 10 years ago

Davide Pesavento wrote:

'ss -px' can display some information about the peer of a Unix domain socket connection, I don't know where it gets that info from though... it might be some Linux-specific kernel structures...

A ucred structure (containing pid, uid, gid) for the peer process connected to a local socket can be obtained via getsockopt(fd, SOL_SOCKET, SO_PEERCRED, ...) on Linux. Unfortunately on Mac OS X only the uid and gid are available, via getpeereid(3).

Actions #9

Updated by Junxiao Shi over 10 years ago

  • Status changed from New to In Progress
  • Assignee set to Junxiao Shi
  • Start date set to 03/28/2014

To keep it simple, I’ll use device name for Ethernet local, and file descriptor for UNIX remote.

Actions #10

Updated by Junxiao Shi over 10 years ago

  • % Done changed from 0 to 10

FaceMgmt is updated as follows:

  • define fd and dev schemes
  • show a table for schemes used for different underlying protocols
  • FaceStatus block has a new LocalUri field
Actions #11

Updated by Junxiao Shi over 10 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 10 to 30
  • Estimated time set to 6.00 h

Id8ad36c9874c968f779fcc5a2c210d39162e0a69

add LocalUri field to FaceStatus and FaceEventNotification

Shall I add FaceFlags field to FaceStatus structure as well?

Actions #12

Updated by Alex Afanasyev over 10 years ago

Yes. That would make sense. Steve was suggesting to make a nested TLV (FaceInfo), but this is probably overkill here, since it is used in just two places

Actions #13

Updated by Junxiao Shi over 10 years ago

FaceStatus block has FaceFlags field added.

Actions #14

Updated by Junxiao Shi over 10 years ago

  • Status changed from Code review to In Progress

Next change:

  • declare const FaceUri& Face::getLocalUri() const
  • update face constructors, channels, and factory as needed to supply value for localUri
  • rename Face::getUri to Face::getRemoteUri, deprecate Face::getUri
Actions #15

Updated by Junxiao Shi over 10 years ago

  • Has duplicate Bug #1430: nfd-status: Failed to present faces and FIB entries added
Actions #16

Updated by Junxiao Shi over 10 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 30 to 50
  • Estimated time changed from 6.00 h to 7.00 h

I6680eb2013c335a14c9fa76b965c2d1e63202334

I realize that FaceUri needs to recognize fd, ether, dev schemes before the features in note-14 can be implemented.

Actions #17

Updated by Junxiao Shi over 10 years ago

  • Status changed from Code review to In Progress

Next change is described in note-14

Actions #18

Updated by Junxiao Shi over 10 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 50 to 70

Icf02ae0a4136b6da3f6388cdce2f861bec44e940

  • Face::getLocalUri() gives a FaceUri representing local endpoint
  • Face::getRemoteUri() gives a FaceUri representing remote endpoint
  • Face::getUri() is a deprecated alias of Face::getRemoteUri()

Next change:

  • FaceManager should put both remoteUri and localUri into FaceStatus block
  • nfd-status should display both remoteUri and localUri
  • remove Face::getUri()
Actions #19

Updated by Junxiao Shi over 10 years ago

  • Status changed from Code review to In Progress
Actions #20

Updated by Junxiao Shi over 10 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 70 to 100

Code changes are complete.

shijunxiao@m0212:~/NFD$ build/bin/nfd-status -f
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 6d} out={1i 0d}}
  faceid=2 remote=udp4://224.0.23.170:56363 local=udp4://192.168.254.15:56363 counters={in={0i 0d} out={0i 0d}}
  faceid=3 remote=udp4://224.0.23.170:56363 local=udp4://192.168.26.12:56363 counters={in={0i 0d} out={0i 0d}}
  faceid=4 remote=ether://01:00:5e:00:17:aa local=dev://eth0 counters={in={0i 0d} out={0i 0d}}
  faceid=5 remote=ether://01:00:5e:00:17:aa local=dev://eth1 counters={in={0i 0d} out={0i 0d}}
  faceid=6 remote=fd://20 local=unix:///run/nfd.sock counters={in={1i 0d} out={0i 0d}}
Actions #21

Updated by Junxiao Shi over 10 years ago

  • Status changed from Code review to Closed
Actions

Also available in: Atom PDF