Service discovery across tunnel endpoints in an overlay network

Abstract

Embodiments of the present disclosure relate to service discovery across tunnel endpoints in overlay networks. In an example, a network device can receive, from a client device, a multicast query for a service advertised by a host device connected to another network device. The network device is configured as a first virtual tunnel endpoint (VTEP) in an overlay network, while the other network device is configured as a second VTEP. The network device can determine whether a hostname of the host device corresponding to a servicename in the multicast query exists in a resource record. In response to determining that the hostname exists in the resource record, the network device can identify an overlay network path corresponding to the hostname from the resource record. The network device can encapsulate the multicast query based on an overlay encapsulation protocol implemented at the first VTEP, and route the encapsulated multicast query to the host device via the overlay network path.

Description

BACKGROUND

[0001] A network can include resources connected by communication links, and can be used to connect people, provide services (e.g., internally and / or externally via the Internet and / or an intranet), and / or organize information, among other activities. A network can also include host devices (such as printers, scanners, fax machines, media streaming devices, networked projectors, surveillance systems, IP phones, etc.) that can host different service functionality that is accessed by client devices (such as computers, laptops, handheld devices, smartphones, etc.) in the network.

[0002] Service discovery includes the detection of host devices and services provided by these host devices on a computer network. Service discovery requires a common language and / or protocol to enable client devices to utilize services hosted by host devices without constant user intervention, and aims to reduce configuration efforts from users / network administrators. Service discovery also allows applications to access services provided by host devices on a local network. BRIEF DESCRIPTION OF DRAWINGS

[0003] For a more complete understanding of the present disclosure, reference is made to the following specific description of examples in conjunction with the accompanying drawings in which like reference characters indicate like structural elements in the various figures of the drawings, and in which:

[0004] Figure 1 schematically illustrates a network environment for service discovery for virtual tunnel end points (VTEPs) in a spanning overlay network, according to an example;

[0005] Figure 2 schematically illustrates another network environment for service discovery for VTEPs in a spanning overlay network, according to an example;

[0006] Figure 3 schematically illustrates another network environment for service discovery for VTEPs in a spanning overlay network, according to an example;

[0007] Figure 4 is a flowchart illustrating a method for service discovery for VTEPs in a spanning overlay network, according to an example;

[0008] Figure 5 is a flowchart illustrating another method for service discovery for VTEPs in a spanning overlay network, according to an example;

[0009] Figure 6 illustrates a computing device for implementing a method for service discovery for VTEPs in a spanning overlay network, according to an example; and

[0010] Figure 7An example of a encapsulated multicast service announcement originating from a host device, addressed to a client device is shown.

[0011] Certain examples have features that supplement or replace features illustrated in the above-described figures. For clarity certain labels can be omitted from certain figures. DETAILED DESCRIPTION

[0012] In this disclosure, the use of the terms "a," "one," or "the" is also intended to include plural forms unless the context clearly indicates otherwise. Furthermore, the use of the term "including," "containing," or "having" when used in this disclosure specifies the presence of stated elements but does not preclude the presence or addition of other elements.

[0013] As used herein, the term "Layer 2 (L2)" refers to the data link layer, i.e., the second layer in the seven-layer Open Systems Interconnection (OSI) reference model for network protocol design. The second layer is the protocol layer used to transfer data between adjacent network nodes within a wide area network or between nodes on the same local area network. The term "Layer 3 (L3)," also known as the network layer, is the third layer in the seven-layer OSI reference model for network protocol design. L3 is the protocol layer that provides the functional and procedural means of transferring data from a source host on one network to a destination host on a different network (as opposed to the data link layer, which connects hosts within the same network). L3 performs the network routing function and can also perform fragmentation and reassembly, as well as reporting delivery errors. The term "network virtualization technology" refers to a framework / protocol that overlays a virtualized L2 network on top of an L3 network by defining encapsulation mechanisms and control planes. The term "virtual tunnel" refers to a virtual communication link that carries encapsulated traffic between two nodes in an overlay network. The term "host device" refers to a computing entity that can be accessed by a client and can host different services (such as streaming and / or video services, cable and / or satellite television services, multimedia streaming services, printer services, etc.) for the client. The term "client device" refers to a computing entity that can discover and access services hosted by a host device. The term "multicast" refers to the transmission of data packets from one or more sources to a group of destination devices. The group can be defined by a single multicast IP address.

[0014] Further, the term "service discovery protocol" refers to a set of rules for advertising services hosted by host devices and discovering services by client devices through exchange of multicast IP packets. The term "subnet" refers to a logical subdivision of an IP network. Thus, a subnet is a network segment in layer three. The term "L2 overlay network" refers to an overlay network that allows host devices in the same subnet to send bridged or layer two traffic to each other. The L2 overlay network uses L2 virtual network instances (VNIs) to forward bridged traffic between two VTEPs in the network. The term "L2 virtual network instance (VNI)" refers to an identifier of a VTEP that connects to hosts / clients in the same subnet. The term "L3 overlay network" refers to an overlay network that allows host devices in different subnets to send L3 traffic or routed traffic to each other. The L3 overlay network uses L3 virtual network instances (VNIs) and virtual routers (i.e., virtual routing and forwarding (VRF) instances) to forward routed traffic between two VTEPs in the network. The term "L3 virtual network instance (VNI)" refers to an identifier of a VTEP that connects to hosts / clients in different subnets.

[0015] A computer network can include an overlay network and an underlay. An overlay network refers to a software-defined virtual network of nodes and / or logical links that is deployed over the physical network infrastructure of network devices. By implementing an overlay network, a layer two (L2) network can be stretched across a layer three (L3) network. The overlay network can be implemented using different network virtualization technologies that allow hardware network resources to be abstracted as software. The underlay refers to the physical network infrastructure of network devices over which the overlay network is implemented. Nodes in the overlay network are referred to as virtual tunnel end points (VTEPs). A VTEP can be a physical or virtual network device that performs encapsulation and decapsulation of packets that are transmitted through the overlay network. VTEPs can be connected to each other via virtual tunnels in the overlay network. The overlay network provides flexibility in packet forwarding, service addition, protocol implementation, and on-demand allocation of virtual network resources without modifying / reconfiguring the physical network infrastructure (i.e., underlay). Thus, overlay networks are primarily used in campus and enterprise networks.

[0016] Service discovery in a campus and enterprise network typically works by using a service discovery protocol, such as Multicast Domain Name System (mDNS), DNS Service Discovery (DNS-SD), Lightweight Service Discovery (LSD), and Multicast Source Discovery Protocol (MSDP). A service discovery protocol works by forwarding a multicast query from a client device to a host device and forwarding a multicast response from the host device back to the client device. In a network that implements an overlay network, a client device and a host device can connect to a VTEP. As long as both the client device and the host device connect to the same VTEP, a service advertised by the host device can be discovered by the client device. In this scenario, when the client device needs to resolve a host name, it sends a multicast query to its connected VTEP asking the host device with that host name to identify itself. The VTEP connected to the client device can flood the multicast query to all of its access ports. Thus, all host devices in the subnets of the client devices connected to the access ports of the VTEP can receive the multicast query. In response, the host device with the queried host name can multicast a message including its IP address. The VTEP can also flood the response from the host device to all of its access ports in the same subnet. Then, all other clients and hosts in the subnet can use the information to update their caches. Thus, the client device can resolve the IP address associated with the host device connected to the same VTEP and discover the service hosted by the host device. However, typically the client device can connect to one VTEP while the host device can connect to a different VTEP. In this scenario, in order for the client device to discover the service of the host device, a multicast query / response needs to be exchanged between two different VTEPs through the overlay network. However, VTEPs do not have the capability to route multicast query / responses through the overlay network to other VTEPs. Thus, when the client device and the host device connect to two different VTEPs in the overlay network, it can be challenging for the client device to discover the service advertised by the host device.

[0017] Furthermore, service discovery protocols typically use link-local addresses to send / receive multicast queries / responses. A link-local address is a network address that is unique within a single subnet, and thus a link-local address of a device can only be used for communication within the subnet to which the device connects. Since link-local addresses can not be unique outside of their subnet and multicast queries / responses are forwarded using these link-local addresses, by design, multicast queries / responses are not routed across different subnets. Since multicast queries / responses are not routed across subnets, a client connected to a VTEP in one subnet can not be able to discover the service of a host connected to a different VTEP in another subnet. Thus, service discovery across devices connected to different VTEPs in an overlay network involves additional challenges.

[0018] For service discovery across clients and hosts connected to different VTEPs in an overlay network, it can be useful to allow VTEPs to forward multicast queries / responses via the overlay network. However, in allowing multicast queries / responses to be forwarded via the overlay network, all VTEPs in the overlay network can be flooded by the multicast queries / responses. Flooding of multicast queries / responses at all VTEPs utilizes computing resources at the VTEPs and consumes data bandwidth of the overlay network. As the number of multicast queries / responses increases, the overlay network can experience bandwidth issues.

[0019] Further, service discovery is expected to be location specific. For example, a teacher in room 1 in a school campus can want to access a smartboard installed near him / her (e.g., within room 1), or an engineer in floor 1-3 in an office campus can want to access a printer installed near him (e.g., in the same building and same floor). Finding a smartboard in a different room or a printer in a different building can be irrelevant and useless to the teacher or engineer. Thus, discovery of services and / or host devices that are far away from the location of the client device can be irrelevant and thus useless to the user. With flooding of multicast queries / responses by all VTEPs in the overlay network, client devices connected to those VTEPs can send multicast queries to host devices that can not be near them and also receive multicast responses from those hosts. Such multicast responses from geographically remote host devices can be irrelevant and useless to the user of the client device. In a distributed network where bandwidth usage cost is high, transmitting such irrelevant queries and responses over the overlay network consumes data bandwidth and can be considered as additional bandwidth cost.

[0020] Examples disclosed herein allow multicast queries / responses to be selectively routed across VTEPs using overlay network paths between client devices requesting services and host devices providing services. Specifically, multicast queries from clients are forwarded via overlay network paths only to those VTEPs connected to host devices providing services, rather than flooding all VTEPs in the overlay network with the multicast queries. This allows clients connected to one VTEP to discover services provided by host devices connected to different VTEPs in the overlay network without flooding the VTEPs with service queries from the clients, thereby avoiding additional bandwidth consumption and additional computing resource usage in the overlay network.

[0021] Further, in examples, the overlay network path of the host device is identified based on a location tag indicative of a location of the client device. Specifically, the overlay network path to the host device having a location tag common to the location tag of the client device is identified. Thus, the multicast query from the client is routed along the overlay network path based on the location of the client device. Routing the multicast query along the overlay network path identified based on the location of the client device allows for location-specific discovery of the host devices and their services. Since the discovery of the host devices is location-specific, multicast responses from host devices that are geographically remote can not be forwarded to the client device, thereby reducing the transmission of irrelevant responses from host devices that are not in close proximity to the client device. This can prevent wasteful consumption of data bandwidth in the overlay network.

[0022] Accordingly, various examples disclosed herein relate to methods and systems for service discovery across VTEPs in an overlay network. In some examples, a first network device configured as a first VTEP in an overlay network receives a multicast query for a service from a client device connected to the network device. The multicast query includes a service name of the service being queried by the client device. The multicast query can indicate that the client device wants to access the service denoted by the service name. The service can be provided by a host device connected to a second network device configured as a second VTEP in the overlay network. The first network device can store a resource record including a list of host names, corresponding host IP addresses, corresponding service names, and corresponding overlay network paths of host devices connected to VTEPs in the overlay network. The overlay network path refers to reachability information of the host devices via the overlay network. In some examples, the reachability information can identify a virtual tunnel connecting two different VTEPs in the overlay network. The overlay network path can include an L2 virtual network instance (VNI) for forwarding traffic in an L2 overlay network or an L3 VNI for forwarding traffic in an L3 overlay network, and an IP address of the second VTEP to which the host device is connected.

[0023] The first network device can create a resource record based on the encapsulated multicast service announcements received from other VTEPs in the overlay network. In response to determining that a hostname corresponding to the service name exists in the resource record, the first network device identifies an overlay network path corresponding to the hostname from the resource record. The overlay network path indicates reachability information of a host device in the overlay network. Further, the first network device encapsulates the multicast query based on an overlay encapsulation protocol implemented at the first VTEP. The encapsulated multicast service query includes at least a portion of the overlay network path. The first network device (implementing the first VTEP) then routes the encapsulated multicast service query to the host device via the overlay network path such that the service is discoverable by the client device. Thus, a multicast query for the service from the client device (connected to a VTEP) can be sent to a selective VTEP (connected to a host providing the service) in the overlay network via the overlay network path. This allows service discovery across VTEPs in the overlay network while avoiding flooding of multicast queries / responses at the VTEPs, preventing additional bandwidth consumption and additional compute resource usage in the overlay network.

[0024] Reference Figures 1 to 6 The above-described systems and methods are further described. It is to be understood that the description and drawings are merely illustrative of the principles of the subject matter described herein and should not be interpreted in

[0025] Figure 1 A network environment 100 is schematically illustrated. In an example, the network environment 100 can be a computer network consisting of interconnected LANs within a limited geographical area. In one example, the network environment 100 can include a campus network. In some examples, the network environment 100 can be a wired network, a wireless network, or a combination thereof. The network environment 100 can be a private network or a shared network, representing an association of different types of networks using various protocols to communicate with each other, such as Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), and the like.

[0026] As Figure 1As shown, network environment 100 includes host device 102. A "host device" refers to a computing entity that can be accessed by clients and can provide clients with hosting various services (such as streaming broadcast and / or video services, cable and / or satellite television services, multimedia streaming services, printer services, etc.). Host device 102 is capable of advertising one or more services. In some examples, a service may refer to a specific functionality that host device 102 can provide by executing an application at host device 102. A host device may include a server that sends or receives data, services, or applications. Host device 102 may communicate with client devices or other host devices on network environment 100 via a physical link via a switch, or in some examples via a wireless communication link.

[0027] Network environment 100 also includes client device 104 that can communicate with host devices. A "client device" is a computing entity that can discover and access services hosted by the host device. Examples of client devices include computers, laptops, tablets, PDAs, and other computing devices that can be used to run applications to access various service functionalities provided by the host device. In network environment 100, client device 104 can access services hosted by host device 102. Although in Figure 1 The diagram shows a single host device 102 and a single client device 104, but in some examples, there may be multiple host devices and multiple client devices.

[0028] Network environment 100 includes network devices 106-1 and 106-2, collectively referred to as network device 106. Each network device 106 can be implemented as, but is not limited to, a switching unit, a switching router, a gateway, or any device capable of exchanging data packets, providing connectivity between hosts and clients in a computer network such as network environment 10. Figure 1 As shown, client device 104 is locally connected to network device 106-1. In some examples, client device 104 may be connected to the access port of network device 106-1 via an Ethernet cable. In some examples, client device 104 may be a wireless device that can connect to network device 106-1 via a wireless access point (not shown), that is, the client device can wirelessly connect to the wireless access point, and the wireless access point can in turn connect to the access port of network device 106-1. Figure 1 As shown, host device 102 is locally connected to network device 106-2. In some examples, host device 102 may be connected to the access port of network device 106-2 via an Ethernet cable.

[0029] Client device 104 can communicate with host device 102 via network devices 106. In some examples, network devices 106 can be connected via overlay network 108 extending therebetween. An "overlay network" refers to a software-defined virtual network of nodes and / or logical links that is deployed over the physical network infrastructure of network devices. An L2 network can be stretched across an L3 network by implementing an overlay network. An overlay network can be implemented using different network virtualization technologies that allow hardware network resources to be abstracted as software. Examples of different network virtualization technologies include Virtual Extensible Local Area Network (VXLAN), Generic Routing Encapsulation (GRE), and Network Virtualization using Generic Routing Encapsulation (NVGRE). As explained earlier, an overlay network can include VTEPs, which can be virtual or physical switch ports. VTEPs can encapsulate data packets entering the overlay network from a source device and decapsulate data packets as they exit the overlay network. Overlay network 108 can be deployed using a switch underlay, referred to as an underlay (not shown). In overlay network 108, network device 106-1 is configured as one VTEP and network device 106-2 is configured as another VTEP. In some examples, the VTEP implemented at network device 106-1 is referred to as a first VTEP or client-side VTEP and the VTEP implemented at network device 106-2 is referred to as a second VTEP or host-side VTEP. The VTEPs can connect to each other via virtual tunnels in overlay network 108.

[0030] In some examples, client device 104 and host device 102 can be in a single broadcast domain, i.e., they are part of a single virtual local area network (VLAN). In some examples, client device 104 and host device 102 are in different broadcast domains, i.e., they are part of different VLANs. In some examples, the first VTEP (configured at network device 106-1) and the second VTEP (configured at network device 106-2) are in a single overlay network segment identified by a common L2 VNI. An overlay network segment refers to a single L2 overlay network in which devices are configured in a single broadcast domain / subnet. In some examples, the first VTEP is in a first overlay network segment identified by a first L2 VNI and the second VTEP is in a second overlay network segment identified by a second L2 VNI. Thus, the first VTEP and the second VTEP are in two different L2 overlay networks and can communicate via an L3 VNI. In some examples, the first VTEP is in a first overlay network fabric and the second VTEP is in a second overlay network fabric. An overlay network fabric refers to an overlay network in which each VTEP is connected to another VTEP through a mesh connection, i.e., each VTEP in the overlay network is connected to every other VTEP via a virtual tunnel.

[0031] like Figure 1 As shown, network device 106-1 may include a processor 110 and a memory 112 that can be coupled to each other via a communication link (e.g., a bus). Processor 110 may include one or more central processing units (CPUs) or other suitable hardware processors(s), such as a network ASIC. Memory 112 may be a machine-readable storage medium capable of storing machine-readable instructions executable by processor 110. Memory 112 may include any suitable combination of volatile and / or non-volatile memory, such as random access memory (RAM), read-only memory (ROM), flash memory, and / or other suitable combinations of memory.

[0032] Memory 112 stores instructions to be executed by processor 152, including instructions for multicast query receiver 114, resource record manager 116, overlay path identifier 118, and query route manager 120.

[0033] Processor 110 can execute multicast query receiver 114 to receive multicast queries for a service from client device 104. In some examples, a multicast query refers to a service discovery protocol-based multicast IP packet originating from a client device attempting to access a specific service in the network. The multicast query may include the service name of the service the client device is attempting to access. Consider in... Figure 1 In the example, client device 104 attempts to access a service provided by host device 102. In some examples, the multicast query may be a service query based on the Multicast Domain Name System (mDNS) protocol. In some examples, the multicast query includes both SRV and TXT records in the mDNS. A service record (SRV record) is a specification in DNS that defines the hostname and port number of the host device providing the service queried by the client device. A TXT record is a specification in DNS that allows domain administrators to associate text values ​​(strings) with the domain name of a host device. In some examples, the service name of the service queried by client device 104 may be included in either an SRV or TXT record.

[0034] Upon receiving a multicast query for a service, processor 110 may execute resource record manager 116 to determine whether the hostname corresponding to the service name exists in the resource records of network device 106-1. Figure 1In the example of FIG. 1, the host name is the host name of the host device 102 that provides the service. In some examples, the resource record includes a list of host names of host devices connected to VTEPs in the overlay network 108, corresponding service names, corresponding IP addresses, and corresponding overlay network paths. In some examples, the resource record can also include a respective role tag and a location tag for each of the host devices. The role tag indicates a role-based access policy for the client device 104, and the location tag indicates a geographic region in which the client device 104 is located. The resource record can be created based on the multicast service announcements received from the host devices connected to the VTEPs in the overlay network 108.

[0035] In some examples, the processor 110 can execute the resource record manager 116 to determine whether the host name corresponds to the role tag and the location tag of the client device 104. The processor 110 can assign a role tag to the client device network 104 based on one of a port address via which the client device 104 connects to the network device 106-1, a MAC address of the client device 104, or based on authentication information of the client device 104. In some examples, the network device 106-1 can be configured such that access ports of the network device 106-1 are assigned to a particular role. Thus, based on the port via which the client device 104 connects to the network device 106-1, the processor 110 can assign a role tag to the client device. Similarly, a MAC address to role mapping can be configured in the network device 106-1. Using the MAC address to role mapping and the MAC address of the client device, the network device 106-1 can assign a role tag to the client device 104. In some examples, the assignment of the role tag to the client device 104 is performed by an authentication server, such as RADIUS. When the client device 104 connects to the network device 106-1 and provides its authentication credentials, then based on its authentication credentials, the authentication server can assign a role tag to the client device 104 and share the role tag with the network device 106-1. The network device 106-1 can apply access policies and permissions based on the assigned role tag.

[0036] The processor 110 can assign a location tag to the client device 104 either statically or based on a location of the wireless access point from which the multicast query is received. In identifying the role tag and the location tag, the processor 110 can execute the resource record manager 116 to check the resource record to determine whether the host name corresponds to the role tag and the location tag of the client device 104. That is, the resource record manager 116 can check whether the role tag and the location tag of the host device 102 match the role tag and the location tag of the client device 104 in addition to checking whether the queried service is provided by the host device 102.

[0037] In response to determining that the hostname corresponding to the service name, the role tag, and the location tag exists in the resource record, the processor 110 can execute the overlay path identifier 118 to identify an overlay network path corresponding to the hostname from the resource record. The overlay network path indicates reachability information of the host device 102 in the overlay network 108. In some examples, the overlay network path includes an L2 virtual network instance (VNI) for forwarding traffic in an L2 overlay network or an L3 VNI for forwarding traffic in an L3 overlay network, and an IP address of a destination VTEP connected to the host device (i.e., in this example, an IP address of the second VTEP connected to the host device 102). The L2 VNI refers to an identifier of a VTEP connected to a host / client in the same subnet. Thus, the L2 VNI is a particular overlay network segment that includes endpoints (VTEPs) within the same IP subnet. The L2 overlay network refers to an overlay network that allows host / client devices in the same subnet to send bridged or Layer 2 traffic to each other. In the L2 overlay network, the bridged traffic between two VTEPs can be forwarded using the L2 VNI. The L3 VNI refers to an identifier of a VTEP connected to a host / client in a different subnet. Thus, the L3 VNI is a particular overlay network segment that includes endpoints (VTEPs) in different IP subnets. The L3 overlay network refers to an overlay network that allows host / client devices in different subnets to send L3 traffic or routed traffic to each other. In the L3 overlay network, the routed traffic between two VTEPs can be forwarded using the L3 VNI and a virtual router (i.e., a virtual routing and forwarding (VRF) instance). The overlay network path provides a virtual communication link between a first VTEP (configured at the network device 106-1) connected to the client device 104 via the overlay network 108 and a second VTEP (configured at the network device 106-2) connected to the host device 102. In some examples, the virtual communication link can be a virtual tunnel connecting the first VTEP and the second VTEP.

[0038] Once the overlay network path is identified, the processor 110 can execute the query routing manager 120 to encapsulate the multicast query and route the encapsulated multicast query to the host device 102 via the overlay network path. In some examples, the query routing manager 120 can implement an overlay encapsulation protocol at the first VTEP to encapsulate the multicast query. An overlay encapsulation protocol, also referred to as a tunneling protocol, is a communication protocol in which logically independent functions in a network (overlay network) are abstracted from their underlying structure (substrate) by implementing a higher level object. Examples include GENEVE, GRE, SSH, VXLAN, and NVGRE. As a result of the encapsulation, one or more headers can be added to the multicast query. At least a portion of the overlay network path can be included in one of the headers. In some examples, the portion of the overlay network path included in the header includes an IP address of the second VTEP connected to the host device 102. In some examples, the encapsulation can be a VXLAN encapsulation of a media access control (MAC) frame within a user datagram protocol (UDP) datagram for transmission across an IP network. In some examples, the encapsulated multicast query can be routed via the overlay network path (i.e., the virtual tunnel identified by the L2 VNI and / or the L3 VNI and the IP address of the second VTEP). In routing along the overlay network path, the multicast query can reach the second VTEP and ultimately the host device 102. Upon receiving the multicast query, the host device 102 can send a response agreeing to provide the service along the same overlay network path. Thus, the client device 104 connected to the VTEP (the first VTEP in the overlay network 108) can discover and access the service advertised by the host device 102 connected to a different VTEP (i.e., the second VTEP in the overlay network 108) via the overlay network path. The identification of the overlay network path allows the multicast query to be routed in a specific route (i.e., from the client-side VTEP (the first VTEP) to the host-side VTEP (the second VTEP) via the virtual tunnel), which prevents the multicast query from unnecessarily flooding to other VTEPs in the overlay network, thereby preventing wasteful bandwidth consumption in the overlay network 108. Moreover, since the overlay network path is identified based on the matching of the location tag of the host device with the location tag of the client device in some examples, the multicast query is also routed along the overlay network path to the location-specific host device, thereby allowing the service discovery to be location-specific.

[0039] Figure 2A network environment 200 is schematically illustrated. In an example, the network environment 200 can be a computer network composed of interconnected LANs within a limited geographic area. In one example, the network environment 200 can comprise a campus network. In some examples, the network environment 200 can be a wired network, a wireless network, or a combination thereof. The network environment 200 can be a private network or a shared network, representing an association of different types of networks using various protocols to communicate with each other, such as Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), and the like.

[0040] As Figure 2 illustrated in FIG. 1, the network environment 200 includes a host device 202 and a client device 204 capable of communicating with the host device 202. The host device 202 can be similar to the host device 102, and the client device 204 can be similar to the client device 104. Although a single host device 202 and a single client device 204 are illustrated in FIG. 1, in some examples, multiple host devices and multiple client devices can be present in the network environment 200. Figure 2

[0041] The network environment 200 also includes network devices 206-1 and 206-2, collectively referred to as network devices 206. The network devices 206 can be similar to the network devices 106 of Figure 1 In some examples, the client device 204 can be connected to an access port of the network device 206-1 via an Ethernet cable. In some examples, the client device 204 can be a wireless device that can be connected to the network device 206-1 via a wireless access point (not shown), i.e., the client device can be wirelessly connected to the wireless access point, which in turn can be connected to an access port of the network device 206-1. As Figure 2 illustrated in FIG. 1, the host device 202 is locally connected to the network device 206-2. In some examples, the host device 202 can be connected to an access port of the network device 206-2 via an Ethernet cable.

[0042] ​Client device 204 can communicate with host device 202 via network devices 206. In some examples, network devices 206 can be connected via an overlay network 208 extending therebetween. As explained earlier, the overlay network can include VTEPs, which can be virtual or physical switch ports. The VTEPs can encapsulate data packets entering the overlay network from a source device and decapsulate the data packets as the data packets exit the overlay network. The overlay network 208 can be deployed using a switch underlay, referred to as an underlay (not shown). In the overlay network 208, network device 206-1 is configured as one VTEP and network device 206-2 is configured as another VTEP. In some examples, the VTEP implemented at network device 206-1 is referred to as a first VTEP or a client-side VTEP and the VTEP implemented at network device 206-2 is referred to as a second VTEP or a host-side VTEP. The VTEPs can be connected to each other via virtual tunnels in the overlay network 208.

[0043] In the above Figure 1 , functionality of the client-side VTEP is explained. Figure 2 The functionality of the host-side VTEP is highlighted. As shown in Figure 2 , network device 206-2 can include a processor 210 and a memory 212 that can be coupled to each other by a communication link (e.g., a bus). Processor 210 can be similar to processor 110 of Figure 1 and memory 212 can be similar to memory 112 of Figure 1 .

[0044] Memory 212 stores instructions to be executed by processor 210, including instructions for a multicast service announcement receiver 214, a service announcement manager 216, and an announcement route manager 218.

[0045] The processor 210 can execute the multicast service advertisement receiver 214 to receive a multicast service advertisement from the host device 202 connected to the network device 206-2. The multicast service advertisement includes a hostname of the host device 202 and a service name of a service advertised by the host device 202. The multicast service advertisement indicates an advertisement from the host device 202 of the service provided by the host device 202. In some examples, the multicast service advertisement is a multicast domain name system (mDNS) pointer (PTR) record with a time-to-live (TTL) of 1 second. The PTR record includes a name of a service that maps to a name of a particular instance of the service. The host device 202 can send the multicast service advertisement periodically or intermittently. In some examples, the network device 206-2 can also query the host device 202 for the multicast service advertisement. Each multicast service advertisement includes the hostname, the IP address of the host device 202, and the service name of the service provided by the host device 202.

[0046] Upon receiving the multicast service advertisement, the processor 110 can execute the service advertisement manager 216 to identify a set of overlay network paths that connect the second VTEP to other VTEPs in the overlay network 208. In examples, each overlay network path can include an L2 VNI / L3 VNI and an IP address of a remote VTEP associated with the L2 VNI / L3 VNI. Accordingly, the service advertisement manager 216 can search for VNIs configured in the second VTEP implemented in the network device 206-2. In some examples, the service advertisement manager 216 can inspect interfaces in the second VTEP to identify peer VTEPs of the second VTEP. In some examples, there can be multiple overlay network paths corresponding to a peer VTEP when two host devices are locally connected to the same peer VTEP. In such a case, one of the multiple overlay network paths is included in the set of overlay network paths. In other words, each of the set of overlay network paths is unique in the sense that each path provides reachability information between the second VTEP and a different VTEP. In some examples, the set of overlay network paths includes a first overlay network path and a second overlay network path. The first overlay network path includes a first L2 VNI / L3 VNI and an IP address of a first VTEP. The second overlay network path includes a second L2 VNI / L3 VNI and an IP address of a second VTEP. Figure 2 In examples, the first VTEP is configured as a peer VTEP of the second VTEP. Accordingly, the service advertisement manager 216 can also identify an overlay network path for the first VTEP. In some examples, the first VTEP and the second VTEP can be configured in a single overlay network segment. In some other examples, the first VTEP and the second VTEP can be configured in different overlay network segments.

[0047] The processor 210 can execute the service advertisement manager 216 to create a set of copies of the multicast service advertisement. Each of the copies of the multicast service advertisement is to be forwarded along a respective overlay network path from the set of overlay network paths. Accordingly, depending on the number of overlay network paths in the set, a number of copies of the multicast service advertisement can be created.

[0048] Further, the processor 210 can also execute the service advertisement manager 216 to encapsulate each of the copies of the service advertisement based on an overlay encapsulation protocol implemented at the second VTEP. In some examples, encapsulating each of the copies of the service advertisement includes performing a MAC-in-UDP encapsulation such that a header is added to each of the copies of the service advertisement. In some examples, the header includes at least a portion of the respective overlay network path along which it will be routed. In some examples, the original service advertisement can be an L2 frame with a VXLAN header added to it, which is then placed in a UDP-IP packet. In some examples, during encapsulating each of the copies of the service advertisement, the processor 110 can also associate a role tag and a location tag of the host device 202 with each of the encapsulated copies of the multicast service advertisement. The role tag indicates a role-based access policy of the host device 202, and the location tag indicates a geographical area in which the host device 202 is located.

[0049] The processor 210 can execute the advertisement routing manager 218 to route each encapsulated copy of the multicast service advertisement to each of the remote VTEPs via the respective overlay network path. Thus, each remote VTEP in the overlay network 208 can receive the service advertisement from the host device 202. Each remote VTEP can store the multicast service advertisement from different host devices, such as the host device 202, and the respective overlay network path via which it was received in a resource record. Thus, a resource record is created in each VTEP in the overlay network 208. The resource record can be used by the VTEP when retrieving a hostname associated with a service queried by a client device associated with the VTEP.

[0050] Figure 3 A network environment 300 for service discovery across VTEPs in an overlay network is schematically illustrated in accordance with an example. The network environment 300 includes a plurality of client devices 302-1 and 302-2 connected to different network devices. Figure 3 The client devices 302 depicted in FIG. 1 can represent examples of the client devices 104 described in FIG. 1. Figure 1 The client devices 302 depicted in FIG. 1 can represent examples of the client devices 104 described in FIG. 1. Figure 1 The network devices 304-1 through 304-5 depicted in FIG. 1 can represent examples of the network devices 106-1 or 106-2 described in FIG. 1. The network devices 304-1 through 304-5 can be collectively referred to as the network devices 304. As Figure 1 The network devices 304-1 through 304-5 depicted in FIG. 1 can represent examples of the network devices 106-1 or 106-2 described in FIG. 1. The network devices 304-1 through 304-5 can be collectively referred to as the network devices 304. As Figure 3As depicted in FIG. 3, client device 302-1 is connected to network device 304-1 and client device 302-2 is connected to network device 304-2. Client devices 302-1 and 302-2 can be connected to network devices 304-1 and 304-2, respectively, via an Ethernet cable connected to an access port of the network device.

[0051] Network environment 300 also includes a plurality of host devices 306-1 through 306-4 connected to different network devices. Host devices 306-1 through 306-4 can be collectively referred to as host devices 306. Figure 3 Host devices 306 depicted in FIG. 3 can represent Figure 1 Host devices 306 depicted in FIG. 3 can represent Figure 3 As depicted in FIG. 3, client device 302-1 is connected to network device 304-1 and client device 302-2 is connected to network device 304-2. Client devices 302-1 and 302-2 can be connected to network devices 304-1 and 304-2, respectively, via an Ethernet cable connected to an access port of the network device. Figure 1 Overlay network 308 depicted in FIG. 3 can represent Figure 3 In the description of FIG. 3, a function or step performed by a network device can alternatively be referred to as a function or step performed by a VTEP implemented at the network device. As can be noted, in the example of FIG. 3, client devices 302 and host devices 306 are connected to different VTEPs. For the purpose of describing Figure 3 In the description of FIG. 3, a function or step performed by a network device can alternatively be referred to as a function or step performed by a VTEP implemented at the network device. As can be noted, in the example of FIG. 3, client devices 302 and host devices 306 are connected to different VTEPs. For the purpose of describing Figure 3 For the purpose of describing

[0052] In some examples, the host device 306-1 can periodically or intermittently send a multicast service announcement to the network device 304-3. The multicast service announcement can include the host name (or, domain name, such as Local-print-Floorl) of the host device 306-1 and the service name of the service announced by the host device 306-1 (i.e., print serv). An example of the multicast service announcement can be an mDNS PTR record. In an example, the host device 306-1 can be a printer that announces a print service with the service name "print serv." The multicast service announcement received by the second VTEP is in the form of an L2 frame. Since the multicast service announcement is received from a locally connected host device 306-1, the multicast service announcement is not encapsulated. The second VTEP can receive the multicast service announcement via a switch interface. The switch interface refers to the physical interface of the VTEP used to support local endpoint communication in the local LAN network segment. The second VTEP also has an IP interface, which refers to the virtual interface of the VTEP used to communicate with other VTEPs via an IP network. Similarly, the host device 306-2 can also send a multicast service announcement to the second VTEP. In an example, the host device 306-2 can be a smart projector that announces a projector service with the service name "proj scrn." In some examples, the second VTEP can also send a request for a service announcement to the host device 306-1 / 306-2.

[0053] Upon receiving the multicast service announcement, the second VTEP can create a local host list. The local host list includes a list of service name, host IP address, and host name of the services provided by the host devices 306-1 and 306-2 locally connected to the second VTEP. Further, typically the host devices are static wired devices. Thus, when the devices are authenticated using an authentication server, such as RADIUS, an identifier of the location of such host devices can be statically entered. The second VTEP can convert this identifier to a location tag by hashing. The location tags of the host devices 306-1 and 306-2 can also be stored in the local host list. Further, the roles of the host devices 306-1 and 306-2 can be determined by the second VTEP. The role of a host device can define what type of traffic the host device can send / receive and to what other devices / users / roles the traffic can be sent. Thus, host devices grouped under a "guest role" can be accessed by client devices assigned under the same "guest role". Entities or devices classified under a single role are subject to similar access policies or permissions. Based on the roles assigned to the host devices 306-1 and 306-2, the second VTEP can assign a role tag to the host devices 306-1 and 306-2. The role tag can be an identifier indicating a particular role assigned to a group of devices or entities. The role tags of the host devices 306-1 and 306-2 can also be stored in the local host list. In an example, the local host list created in the second VTEP is as shown in "Table 1" below.

[0054] Table 1

[0055] Host IP Service Name Character Tags Location tags 1.1.1.2 / 24 "print serv 1" Visitors 101 1.1.1.3 / 24 "proj scrn" administrator 101

[0056] From the local host list in Table 1, it can be seen that the host device 306-1 has an IP address of 1.1.1.2 / 24, provides a print service "print servl", is assigned a "Guest" role, and has a location tag "101" indicating a particular location in the building / floor. The host device 306-2 has an IP address of 1.1.1.3 / 24, provides a screen projection service "projscrn", is assigned an "Admin" role, and has a location tag "101". Similarly, the VTEP3 and VTEP4 implemented in the network devices 304-4 and 304-5, respectively, can maintain respective local host lists with multicast service announcements from their respective locally connected host devices 306-3 and 306-4.

[0057] Further, the second VTEP is configured to identify a set of overlay network paths that connect the second VTEP to other VTEPs in the overlay network 308. In an example, the second VTEP can identify the L2 VNIs / L3 VNIs configured in the second VTEP and remote VTEPs that have the same L2 VNIs / L3 VNIs. By identifying the remote VTEPs that are part of the same L2 VNIs / L3 VNIs as configured in the second VTEP, the second VTEP is able to identify the set of overlay network paths that connect the second VTEP to other VTEPs in the overlay network 308. In an example, the second VTEP (VTEP2) can identify the IP addresses of VTEP1, VTEP3, VTEP4, and VTEP5 and the L2 VNIs / L3 VNIs that connect VTEP1 to each of these VTEPs.

[0058] The network device 304-3 can create a set of copies of the multicast service announcement. Each of the copies of the multicast service announcement is to be forwarded along a respective overlay network path of the set of network paths that overlays the respective overlay network path. Thus, the number of copies in the set is the same as the number of identified overlay network paths. The network device 304-3 can perform replication of the multicast service announcement to create the set of copies.

[0059] The network device 304-3 can also encapsulate each of the copies of the multicast service announcement based on the overlay encapsulation protocol implemented at the second VTEP. In an example, the encapsulation can be a VXLAN-based MAC-in-UDP encapsulation. The copies of the multicast service announcement, which are L2 frames, can be encapsulated within UDP datagrams. In some examples, the encapsulated copies of the multicast service announcement include an outer IP address that is an IP address of one of the VTEPs (VTEP1 / VTEP3 / VTEP4 / VTEP5) in the overlay network 308 and a VXLAN header that includes the L2 VNI / L3 VNI and a role tag of the host device (such as the host device 306-1) from which the multicast service announcement originated. Figure 7 An example of an encapsulated multicast service announcement originating from the host device 306-1, addressed to the client device 302-2 is shown.

[0060] An example "original L2 frame" can refer to a multicast service announcement. In some examples, the "original L2 frame" includes an mDNS L2 header, an mDNS IP header, and an mDNS payload. In an example, a "VXLAN header" is added to the "original L2 frame" by way of encapsulation. As can be seen, the "VXLAN header" includes a VNI that indicates the overlay network segment via which encapsulated copies of the multicast service announcement are to be forwarded. In addition, the role tag (i.e., "Guest") and location tag (i.e., "101") of the host device 306-1 are also included in the "VXLAN header." The "outer IP header" can include an "outer source IP," which is the IP address of the VTEP (in this case, VTEP2) that encapsulates the copies of the multicast service announcement. Similarly, the "outer IP header" also includes an "outer destination IP," which is the IP address of the VTEP (in this case, VTEP1) that decapsulates the copies of the multicast service announcement. The overlay network path between the second VTEP (VTEP2) and the first VTEP (VTEP1) can be indicated by the L2 VNI / L3 VNI configured in VTEP2 and VTEP1, as well as the IP address of the destination VTEP (i.e., VTEP1). As can be noted, a portion of the overlay network path between VTEP2 and VTEP1 (i.e., the IP address and VNI of VTEP1) is included in the encapsulated copies of the multicast service announcement. Similarly, each encapsulated copy of the multicast service announcement includes at least a portion of the respective overlay network path along which each encapsulated copy is to be routed. In this example, VTEP2 can create copies of the multicast service announcement, each of which can be routed to VTEP1, VTEP3, VTEP4, and VTEP5. In each encapsulated copy of the multicast service announcement to be forwarded to these VTEPs, a portion of the respective overlay network path can be included. In addition, as explained above, the network device 304-3 also associates the role tag and location tag of the host device 306-1 with each of the encapsulated copies of the multicast service announcement (e.g., within a reserved field of the VXLAN header of the encapsulated copies).

[0061] The network device 304-3 (implementing VTEP2) can then route each encapsulated copy of the multicast service announcement to each of the other VTEPs (i.e., VTEP1, VTEP3, VTEP4, and VTEP5) via the respective overlay network path. Since the copies of the multicast service announcement are routed to a particular VTEP via a particular overlay network path, these copies are not flooded in the L2 VNI of the source VTEP (in this example, VTEP2), thereby avoiding excessive bandwidth consumption in the overlay network 308.

[0062] In the above description, it is explained that network device 304-3 (implementing the second VTEP) routes encapsulated copies of the multicast service advertisement to other VTEPs in the overlay network 308. Similarly, network devices 304-4 and 304-5 can also send encapsulated multicast service advertisements to all other VTEPs. Consider the encapsulated multicast service advertisement received by VTEP1. Specifically, network device 304-2 (implementing VTEP1) can receive the encapsulated multicast service advertisement for host device 306-1 from VTEP2 via an overlay network path. As explained earlier, the encapsulated multicast service advertisement includes the host name, host IP address, service name, location tag, and role tag of host device 306-1.

[0063] Upon receiving the encapsulated multicast service advertisement, network device 304-2 can create a record entry associating the respective overlay network path with the service name and host name. In some examples, network device 304-2 can create the record entry with the host name, service name, and host IP assignment of the L2VNI / L3VNI and VTEP IP from which the encapsulated multicast service advertisement is received. The record entry is stored in a resource record that is maintained at the first VTEP. A “resource record” refers to a list of IP addresses of host devices that can be associated with respective host names, service names, role tags, overlay network paths, and location tags that can be stored within a VTEP in the overlay network. The first VTEP (VTEP1) can receive a copy of the multicast service advertisement from each of VTEP2, VTEP3, and VTEP4 that are locally connected to host devices 306-1, 306-2, 306-3, and 306-4. Based on all these encapsulated service advertisements from host devices 306, network device 304-2 can create a resource record. Thus, an example resource record created at the first VTEP is shown in “Table 2” below:

[0064] Table 2

[0065]

[0066] Network device 304-2 can receive a multicast query from client device 302-2 for a print service named “print serv” advertised by host devices such as host devices 306-1 and 306-3. The multicast query includes the service name of the service (print serv). Consider that client device 302-2 is associated with the “guest” role.

[0067] When the multicast query is received, network device 304-2 determines whether a hostname of a host device corresponding to the service name (print serv) exists in the resource record of network device 304-2 (an example of which is shown in Table 2). With reference to the example resource record of Table 2, network device 304-2 can determine that two host devices with hostnames of "Local-print-Floorl" and "Local-print-Floor2" are advertising a service named "print serv."

[0068] In some examples, network device 304-2 can also identify a role tag and a location tag of client device 302-2. As mentioned earlier, client device 302-2 is assigned a role tag of "Guest." The authentication server can assign the role tag to client device 302-2 based on the authentication credentials of client device 302-2. In some examples, the role tag can also be assigned on a per-port basis. That is, each access port of network device 304-2 can be assigned a particular role. Depending on which port is used to connect client device 302-2 to network device 304-2, the role tag can be assigned. In addition, location tag 101 can be assigned to client device 302-2 based on a static location assignment during authentication of client device 302-2.

[0069] In response to determining that a hostname corresponding to the service name (print serv) exists in the resource record, network device 304-2 can determine that the hostname in the resource record corresponds to the role tag and the location tag. With reference to the example resource record of Table 2, network device 304-2 can determine that the hostname "Local-print-Floorl" corresponds to the role tag "Guest" and the location tag "Floor 1." In addition, network device 304-2 can determine that the hostname "Local-print-Floor2" corresponds to the role tag "Guest" and the location tag "Floor 2." Figure 3In an example, network device 304-2 can determine that host device 306-1 with hostname "Local-print-Floorl" and host IP "1.1.1.2 / 24" has a role tag ("Guest") and a location tag ("101") that match those assigned to client device 302-2. Accordingly, network device 304-2 identifies that host device 306-1 corresponding to service name "print serv," location tag "101," and role tag "Guest" exists in the resource record (an example of which is shown in Table 2). It can be noted that although host device 306-3 with hostname "Local-print-Floor2" advertises the same service "print serv" that is queried by client device 302-2, host device 306-3 is associated with a role tag "Employee" and a location tag "105" that do not match the role tag "Guest" and the location tag "101" of client device 302-2. Accordingly, host device 306-3 is ignored by network device 340-2.

[0070] In response to determining that a hostname (Local-print-Floorl) corresponding to the matching service name "print serv," role tag "Guest," and location tag "101" exists in the resource record, network device 304-2 can identify from the resource record an overlay network path corresponding to the hostname (Local-print-Floorl). Accordingly, network device 304-2 can identify "L2VNI 100" and "<VTEP2 IP address>" as the overlay network path corresponding to the hostname "Local-print-Floorl" of host device 306-1. Network device 304-2 can also encapsulate the multicast query based on an overlay encapsulation protocol implemented at the first VTEP (i.e., VTEP1). In an example, the encapsulation can be a VXLAN-based MAC-in-UDP encapsulation. The encapsulated multicast query includes at least a portion of the overlay network path. For example, the encapsulated multicast query can include "L2VNI 100" within a VXLAN header and "<VTEP2 IP address>" as an outer destination IP included as part of an outer IP header. In response to determining that a hostname corresponding to the service name, role tag, and location tag does not exist in the resource record, network device 304-2 can drop / discard the multicast query.

[0071] Further, network device 304-2 can route the encapsulated multicast query to a host device (i.e., host device 306-1 in this example) via an overlay network path (i.e., via "L2 VNI 100" and "<VTEP2 IP address>"). Thus, the second VTEP (VTEP2) can receive the encapsulated multicast query originating from client device 302-2. The second VTEP (VTEP2) can decapsulate the multicast query and can send the decapsulated multicast query to host device 306-1. Host device 306-1, upon receiving the multicast query, can respond to such query. Thus, client device 302-2 connected to VTEP (VTEP1) can discover host device 306-1 connected to a different VTEP (VTEP2) via the overlay network path ("L2 VNI 100" and "<VTEP2 IP address>") identified in the resource record (of Table 2) maintained from the VTEP (VTEP1) locally connected to client device 302-2. The routing of the multicast query from the client device along the overlay network path allows the client device to discover the service advertised by the host device without flooding the multicast query to other VTEPs in the overlay network 308, thereby preventing bandwidth wastage. Further, since host device 306-1 has the role tag and location tag matching the role tag and location tag of client device 302-2, the routing of the multicast query via the overlay network path is also role-specific and location-specific.

[0072] Figure 4 is a flow diagram illustrating a method 400 for service discovery across VTEPs in an overlay network, according to an example. The method 400 can be performed on a network device, such as Figure 1 a network device 106-1 in a network environment 100 of FIG. 1. The network device can be configured as a VTEP in an overlay network. The overlay network includes other VTEPs, such as Figure 1 host devices 102, to which host devices can connect.

[0073] At block 402, the network device can receive a multicast query from a client device, such as Figure 1A client device of the client devices 104 receives a multicast query for a service. In some examples, the multicast query is a service discovery protocol based multicast IP packet originating from a client device attempting to access a particular service in the network. The multicast query can include a service name of the service that the client device is attempting to access. In some examples, the multicast query can be a service query based on the multicast domain name system (mDNS) protocol. In some examples, the multicast query includes SRV records and TXT records. A service record (SRV record) refers to a specification in DNS of data that defines the host name and port number of a host device providing a service queried by a client device. TXT refers to a specification in DNS of data that allows a domain administrator to associate a text value (string) with a domain name of a host device. In some examples, the service name of the service queried by the client device can be included in the SRV record or the TXT record.

[0074] Upon receiving the multicast query for the service, at block 404, the network device can determine whether a host name corresponding to the service name exists in a resource record of the network device. In some examples, the resource record includes a list of host names of host devices connected to VTEPs in the overlay network, corresponding service names, corresponding IP addresses, and corresponding overlay network paths. In some examples, the resource record can also include a respective role tag and a location tag for each of the host devices. The resource record can be created based on multicast service announcements received from the host devices connected to the VTEPs in the overlay network.

[0075] In some examples, the network device can determine whether the hostname corresponds to a role tag and a location tag of the client device. The role tag of the client device refers to a role-based access policy of the client device. The network device can assign a role tag to the client device based on one of a port address via which the client device connects to the network device, a MAC address of the client device, or based on authentication information of the client device. In some examples, the network device can be configured such that access ports of the network device are assigned to a particular role. Thus, based on the port via which the client device connects to the network device, the network device can assign a role tag to the client device. Similarly, a MAC address to role mapping can be configured in the network device. Using the MAC address to role mapping and the MAC address of the client device, the network device can assign a role tag to the client device. In some examples, the assignment of the role tag to the client device is performed by an authentication server, such as RADIUS. When the client device connects to the network device and provides its authentication credentials, then based on its authentication credentials, the authentication server can assign a role tag to the client device and share the role tag with the network device. The network device can apply access policies and permissions based on the assigned role tag. The network device can also assign a location tag to the client device either statically or based on the location of the wireless access point from which the multicast query is received. In identifying the role tag and the location tag assigned to the client device, the network device can check the resource record to determine whether the hostname corresponds to the role tag and the location tag of the client device. That is, the resource record manager can check whether the role tag and the location tag of the host device match the role tag and the location tag of the client device in addition to checking whether the queried service is provided by the host device.

[0076] In response to determining that the hostname corresponding to the service name exists in the resource record, at block 406, the network device can identify, from the resource record, an overlay network path corresponding to the hostname. The overlay network path indicates reachability information of the host device in the overlay network. In some examples, the overlay network path includes an L2 virtual network instance (VNI) for forwarding traffic in an L2 overlay network or an L3 VNI for forwarding traffic in an L3 overlay network, and an IP address of a destination VTEP connected to the host device. An L2 VNI refers to an identifier that includes a particular overlay network segment of endpoints (VTEPs) within the same IP subnet. The L2 VNI allows for forwarding bridged encapsulated traffic between two devices in the same subnet in an L2 overlay network. An L3 VNI refers to an identifier that includes a particular overlay network segment of endpoints (VTEPs) in different IP subnets. The L3 VNI, together with a virtual router (i.e., a virtual routing and forwarding (VRF) instance), allows for routing encapsulated traffic between two devices in different subnets in an L3 overlay network. The overlay network path provides a virtual communication link between a VTEP locally connected to the client device via the overlay network and another VTEP locally connected to the host device. In some examples, the virtual communication link can be a virtual tunnel connecting the two VTEPs.

[0077] Once the overlay network path is identified, at block 408, the network device can encapsulate the multicast query. In some examples, the network device can implement an overlay encapsulation protocol in its VTEP to encapsulate the multicast query. An overlay encapsulation protocol, also referred to as a tunneling protocol, is a communication protocol in which logically independent functions in a network (overlay network) are abstracted from their underlying structure (substrate) by implementing higher-level objects. Examples include GENEVE, GRE, SSH, VXLAN, and NVGRE. As a result of the encapsulation, one or more headers can be added to the multicast query. At least a portion of the overlay network path can be included in one of such headers. In some examples, the portion of the overlay network path included in the header includes an IP address of the VTEP connected to the host device. In some examples, the encapsulation can be a VXLAN encapsulation of a media access control (MAC) frame within a user datagram protocol (UDP) datagram for transmission across an IP network.

[0078] At block 410, the network device can route the encapsulated multicast query to the host device via an overlay network path. In some examples, the encapsulated multicast query can be routed via the overlay network path (i.e., the virtual tunnel identified by the L2 VNI and / or L3 VNI and the IP address of the VTEP connected to the host device). In routing along the overlay network path, the multicast query can reach the VTEP connected to the host device and ultimately the host device. Upon receiving the multicast query, the host device can send a response agreeing to provide the service along the same overlay network path. Thus, a client device connected to the VTEP can discover and access the service advertised by the host device connected to a different VTEP via the overlay network path. The identification of the overlay network path allows the multicast query to be routed in a specific route (i.e., from the client-side VTEP to the host-side VTEP (VTEP2) via the virtual tunnel defined by the overlay network path), which prevents the multicast query from being unnecessarily flooded to other VTEPs in the overlay network, thereby preventing wasted bandwidth consumption in the overlay network.

[0079] Figure 5 is a flow diagram illustrating a method 500 for service discovery across VTEPs in an overlay network, according to an example. The method 500 can be performed on a network device, such as the network device 106-1 in the network environment 100 of Figure 1 The network device can be configured as a VTEP in an overlay network, such as the overlay network 108 of Figure 1 A client device, such as the client device 104, can be locally connected to the VTEP. Thus, the steps of the method 500 can be performed by the client-side VTEP. The overlay network includes other VTEPs, such as the host devices 102, to which host devices can be connected. The overlay network can be similar to the overlay network 108 of Figure 1 Figure 1

[0080] At block 502, the network device can check whether a multicast query for a service is received. The network device can implement a VTEP connected to a client device. The service can be provided by a host device connected to another VTEP in an overlay network. In an example, the multicast query can be an mDNS SRV or TXT record including a service name of the service that the client device is querying.

[0081] ​​In response to determining that the multicast query was not received ("NO" branch from block 502), at block 504, the network device can continue its data forwarding operations. The data forwarding operations can refer to the usual operations of the network device for processing communications between different devices. In response to determining that the multicast query was received, at block 506, the network device can check whether the service name of the multicast query exists in the resource record. The resource record includes a list of hostnames connected to VTEPs in the overlay network, corresponding service names, and corresponding overlay network paths. In one example, the resource record can be similar to the resource record shown in "Table 2".

[0082] In response to determining that the service name does not exist in the resource record ("NO" branch from block 506), at block 508, the network switch can discard the multicast query. Discarding the multicast query refers to discarding the multicast query where the network device does not perform further operations for the multicast query. In response to determining that the service name exists in the resource record ("YES" branch from block 506), at block 510, the network switch can identify the hostname corresponding to the service name. The hostname indicates the host device that advertises the service with the service name. In some examples, the network device can also identify multiple hostnames corresponding to the service name. In case of multiple host devices connected to the overlay network providing the same service, then the network device can identify multiple hostnames corresponding to the service name.

[0083] At block 512, the network switch can check the resource record to find out which hostnames have location tags and role tags that match the location tag and the role tag of the client device. Since the client device is locally connected to the network switch, the role tag and the location of the client device can be identified by the network switch. In response to finding that the location tag and the role tag of the host device do not match the location tag and the role tag of the client device ("NO" branch from block 512), at block 508, the network switch can discard or drop the multicast query.

[0084] In response to finding that the location tag and the role tag of the host device do match the location tag and the role tag of the client device ("YES" branch from block 512), at block 514, the network switch can identify the overlay network path corresponding to the hostname from the resource record. The overlay network path indicates the reachability information of the host device in the overlay network.

[0085] At block 516, the network switch can encapsulate the multicast query using a tunneling protocol (e.g., VXLAN, GRE, or NVGRE). The encapsulated multicast query includes at least a portion of an overlay network path. At block 518, the encapsulated multicast query is forwarded along the overlay network path to a host device advertising the queried service. Thus, a client device connected to a VTEP in an overlay network can discover services of host devices connected to different VTEPs in the overlay network by routing a multicast query through the overlay network path.

[0086] Figure 6 FIG. 1 illustrates an example computing device 600 having a hardware processor 601 and accessible machine-readable instructions stored on a machine-readable medium 602 for implementing one example system, in accordance with one or more disclosed example implementations. In an example, the computing device 600 can be a network device, such as the network device 106 described above with reference to FIG. 1. Figure 1 Figure 6 FIG. 1 illustrates the computing device 600 configured to execute the instructions 604-612 described below. However, the computing device 600 can also be configured to execute the flow of other methods, techniques, functions, or processes described in the present disclosure, such as, for example, the method 400 of FIG. 4. Figure 4

[0087] A processing element such as the processor 601 can include one or more hardware processors each of which can have a single or multiple processor cores. In one embodiment, the processor 601 can include at least one shared cache that stores data (e.g., computational instructions) utilized by one or more other components of the processor 601. For example, the shared cache can be data stored in memory for faster access by the components of the processing elements that make up the processor 601. In one or more embodiments, the shared cache can include one or more mid-level caches (such as a second level (L2), a third level (L3), a fourth level (L4), or other level of cache), a last level cache (LLC), or a combination thereof. Examples of processors include, without limitation, central processing units (CPUs), microprocessors. Although not illustrated in FIG. 6, the processing elements that make up the processor 601 can also include one or more other types of hardware processing components, such as graphics processing units (GPUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and / or digital signal processors (DSPs). Figure 6

[0088] ​​​The processor 601 can be operatively and communicatively coupled to the memory. The memory can be a non-transitory computer-readable medium, such as a machine-readable storage medium 602, configured to store various types of data. For example, the memory can include one or more storage devices including non-volatile storage devices and / or volatile memory. Volatile memory, such as random access memory (RAM), can be any suitable non-persistent memory. Non-volatile storage devices can include one or more magnetic disk drives, optical disk drives, solid state drives (SSDs), tap drives, flash memory, read-only memory (ROM), and / or any other type of memory designed to maintain data for a period of time after a power down or shutdown operation. In certain aspects, if the allocated RAM is not large enough to hold all job data, the non-volatile storage devices can be used to store overflow data. The non-volatile storage devices can also be used to store programs that are loaded into the RAM when a selection is made to execute the programs.

[0089] Figure 6 The machine-readable storage medium 602 can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as program modules, data structures, program instructions, or other data. The machine-readable storage medium can be non-transitory, where the term “non-transitory” does not encompass transitory propagating signals.

[0090] The machine-readable medium 602 includes instructions 604 that, when executed by the processor 601, cause the network device to receive a multicast query for a service from a client device, such as the client device 104. Figure 1 The multicast query can include a service name of the service that the client device is attempting to access. In some examples, the multicast query can be a service query based on the multicast domain name system (mDNS) protocol. In some examples, the multicast query includes SRV records and TXT records. A service record (SRV record) refers to a specification in DNS that defines the host name and port number of a host device that provides a service queried by the client device. TXT refers to a specification in DNS that allows a domain administrator to associate a text value (string) with a domain name of a host device. In some examples, the service name of the service queried by the client device can be included in the SRV record or the TXT record.

[0091] Upon receiving the multicast query for the service, the machine-readable medium 602 includes instructions 606 that, when executed by the processor 601, cause the network device to determine whether a hostname corresponding to the service name exists in a resource record of the network device. In some examples, the resource record includes a list of hostnames of host devices connected to VTEPs in the overlay network, corresponding service names, corresponding IP addresses, and corresponding overlay network paths. In some examples, the resource record can also include a corresponding role tag and a location tag for each of the host devices. The resource record can be created based on multicast service announcements received from the host devices connected to the VTEPs in the overlay network.

[0092] In some examples, the network device can determine whether the hostname corresponds to a role tag and a location tag of the client device. The role tag of the client device refers to a role-based access policy of the client device. The network device can assign the role tag to the client device based on one of a port address via which the client device connects to the network device, a MAC address of the client device, or based on authentication information of the client device. In some examples, the network device can be configured such that access ports of the network device are assigned to particular roles. Thus, based on the port via which the client device connects to the network device, the network device can assign the role tag to the client device. Similarly, a MAC address to role mapping can be configured in the network device. Using the MAC address to role mapping and the MAC address of the client device, the network device can assign the role tag to the client device. In some examples, the assignment of the role tag to the client device is performed by an authentication server, such as RADIUS. When the client device connects to the network device and provides its authentication credentials, then based on its authentication credentials, the authentication server can assign a role tag to the client device and share the role tag with the network device. The network device can apply access policies and permissions based on the assigned role tag. The network device can also assign a location tag to the client device either statically or based on a location of the wireless access point from which the multicast query is received. In identifying the role tag and the location tag assigned to the client device, the network device can check the resource record to determine whether the hostname corresponds to the role tag and the location tag of the client device. That is, the resource record manager can check not only whether the queried service is provided by the host device, but also whether the role tag and the location tag of the host device match the role tag and the location tag of the client device.

[0093] In response to determining that the hostname corresponding to the service name exists in the resource record, the machine-readable medium 602 includes instructions 608 that, when executed by the processor 601, cause the network device to identify, from the resource record, an overlay network path corresponding to the hostname. The overlay network path indicates reachability information for a host device in the overlay network. In some examples, the overlay network path includes an L2 virtual network instance (VNI) for forwarding traffic in an L2 overlay network or an L3 VNI for forwarding traffic in an L3 overlay network, and an IP address of a destination VTEP connected to the host device. An L2 VNI refers to an identifier that includes a particular overlay network segment of endpoints (VTEPs) within the same IP subnet. The L2 VNI allows for forwarding bridged encapsulated traffic between two devices in the same subnet in an L2 overlay network. An L3 VNI refers to an identifier that includes a particular overlay network segment of endpoints (VTEPs) in different IP subnets. The L3 VNI, together with a virtual router (i.e., a virtual routing and forwarding (VRF) instance), allows for routing encapsulated traffic between two devices in different subnets in an L3 overlay network. The overlay network path provides a virtual communication link between a VTEP locally connected to the client device via the overlay network and another VTEP locally connected to the host device. In some examples, the virtual communication link can be a virtual tunnel connecting the two VTEPs.

[0094] Once the overlay network path is identified, the machine-readable medium 602 includes instructions 610 that, when executed by the processor 601, cause the network device to encapsulate the multicast query. In some examples, the network device can implement an overlay encapsulation protocol in its VTEP to encapsulate the multicast query. An overlay encapsulation protocol, also referred to as a tunneling protocol, is a communication protocol in which logically independent functions in a network (overlay network) are abstracted from their underlying structure (substrate) by implementing a higher-level object. Examples include GENEVE, GRE, SSH, VXLAN, and NVGRE. As a result of the encapsulation, one or more headers can be added to the multicast query. At least a portion of the overlay network path can be included in one of such headers. In some examples, the portion of the overlay network path included in the header includes an IP address of the VTEP connected to the host device. In some examples, the encapsulation can be a VXLAN encapsulation of a media access control (MAC) frame within a user datagram protocol (UDP) datagram for transmission across an IP network.

[0095] Further, the machine-readable medium 602 includes instructions 612 that, when executed by the processor 601, cause the network device to route the encapsulated multicast query to the host device via an overlay network path. In some examples, the encapsulated multicast query can be routed via the overlay network path (i.e., the virtual tunnel identified by the L2 VNI and / or L3 VNI and the IP address of the VTEP connected to the host device). In routing along the overlay network path, the multicast query can reach the VTEP connected to the host device and ultimately the host device. Upon receiving the multicast query, the host device can send a response agreeing to provide the service along the same overlay network path. Thus, a client device connected to the VTEP can discover and access the service advertised by the host device connected to a different VTEP via the overlay network path. The identification of the overlay network path allows the multicast query to be routed in a specific route (i.e., from the client-side VTEP to the host-side VTEP (VTEP2) via the virtual tunnel defined by the overlay network path), which prevents the multicast query from being unnecessarily flooded to other VTEPs in the overlay network, thereby preventing wasted bandwidth consumption in the overlay network.

[0096] A network device, as used in examples herein, is a device that receives network traffic and forwards network traffic to a destination. Some network devices perform packet services, such as application classification and deep packet inspection, on certain network traffic received at the network device. Some network devices monitor load parameters of various physical and logical resources of the network device and report load information to a network orchestrator or orchestrator. A switch is an example of a network device.

[0097] As used in examples herein, a switch forwards data (in control packets) between a sender device and a receiver device (or, multiple receiver devices) based on forwarding information (or, equivalently, "routing information") accessible by the switch. The forwarding information can include an entry that maps a network address (e.g., a MAC address or an IP address) and / or a port to a respective network path toward the receiving device(s).

[0098] Examples of client devices, as used herein, can include a laptop computer, a server, a web server, an authentication server, an authentication-authorization-accounting (AAA) server, a domain name system (DNS) server, a dynamic host configuration protocol (DHCP) server, an Internet protocol (IP) server, a virtual private network (VPN) server, a network policy server, a mainframe, a tablet computer, an e-reader, a netbook computer, a television and similar display (e.g., a smart television), a content receiver, a set-top box, a personal digital assistant (PDA), a mobile phone, a smart phone, a smart terminal, a dumb terminal, a virtual terminal, a video game console, a virtual assistant, an Internet of Things (IOT) device, and the like. A client device can also be referred to as a station (STA).

[0099] Certain terms have been used throughout this description and claims to refer to particular system components. As one skilled in the art will appreciate, different parties can refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In this disclosure and claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to... ” Also, the term “couple” is intended to mean either an indirect or direct wired or wireless connection. Accordingly, if a first device couples to a second device, that connection can be through a direct connection or through an indirect connection via other devices and connections. The recitation “based on” is intended to mean “based, at least in part, on.” Thus, if X is based on Y, X can be a function of Y and any number of other factors.

[0100] The above discussion is meant to be illustrative only. Many variations and modifications will become apparent to those skilled in the art upon reading the above disclosure. The appended claims are intended to cover all such variations and modifications.

Claims

1. A network device, comprising: processor; A non-transitory computer-readable storage medium storing instructions that, when executed by the processor, cause the processor to: A client device connected to the network device receives a multicast query for a service advertised by a host device connected to another network device, the network device being configured as a first Virtual Tunnel Endpoint (VTEP) in the overlay network, and the other network device being configured as a second VTEP in the overlay network, wherein the multicast query includes the service name of the service. Determine whether the host name corresponding to the service name of the host device exists in the resource record of the network device, wherein the resource record includes an entry that associates the host name of the VTEP to be connected to the overlay network with the corresponding service name and the corresponding overlay network path; In response to determining that the host name corresponding to the service name of the host device exists in the resource record, an overlay network path corresponding to the host name is identified from the resource record, the overlay network path indicating the reachability information of the host device in the overlay network; The multicast query is encapsulated based on an overlay encapsulation protocol implemented at the first VTEP, wherein the encapsulated multicast query includes at least a portion of the overlay network path; as well as The encapsulated multicast query is routed to the host device via the overlay network path, making the service discoverable by the client device.

2. The network device according to claim 1, wherein the overlay network path includes a second-layer L2 virtual network instance (VNI) or a third-layer L3 VNI, and the IP address of the second VTEP.

3. The network device of claim 1, wherein the multicast query is discarded in response to determining that the hostname does not exist in the resource record.

4. The network device according to claim 1, wherein the processor is further configured to: The host device receives an encapsulated multicast service announcement from the second VTEP via the overlay network path, wherein the encapsulated multicast service announcement includes the host device's hostname and service name; Create a record entry that associates the overlay network path with the service name and the hostname; as well as The record entry is stored in the resource record, which is maintained at the first VTEP.

5. The network device according to claim 1, wherein the processor is further configured to: Identify a role tag and a location tag for the client device, wherein the role tag indicates the role-based access policy of the client device, and the location tag indicates the geographical region where the client device is located; and Determine that the hostname in the resource record corresponds to the role tag and the location tag.

6. The network device of claim 1, wherein the client device and the host device are in a single broadcast domain.

7. The network device according to claim 1, wherein the client device and the host device are in different broadcast domains.

8. The network device of claim 1, wherein the first VTEP and the second VTEP are in a single overlay network segment identified by a common Layer 2 Virtual Network Identifier (VNI).

9. The network device of claim 1, wherein the first VTEP is in a first overlay network segment identified by a first L2 VNI, and the second VTEP is in a second overlay network segment identified by a second L2 VNI.

10. The network device of claim 1, wherein the first VTEP is in a first overlay network structure, and the second VTEP is in a second overlay network structure.

11. The network device of claim 1, wherein the overlay encapsulation protocol is one of Virtual Scalable Local Area Network (VXLAN), Geneve General Network Virtualization Encapsulation (GENEVE), or NVGRE Network Virtualization using General Routing Encapsulation (NVGRE).

12. The network device according to claim 1, wherein the multicast query is a multicast Domain Name System (mDNS) service query.

13. The network device according to claim 1, wherein the multicast query includes one of mDNS service record (SRV) and mDNS text record (TXT).

14. A method for service discovery in an overlay network, comprising: A network device receives a multicast query from a client device connected to the network device for a service advertised by a host device connected to another network device, the network device being configured as a first Virtual Tunnel Endpoint (VTEP) in the overlay network, and the other network device being configured as a second VTEP in the overlay network, wherein the multicast query includes the service name of the service; The network device determines whether the host name corresponding to the service name of the host device exists in the resource record of the network device, wherein the resource record includes an entry that associates the host name of the VTEP to be connected to the overlay network with the corresponding service name and the corresponding overlay network path; In response to determining that the host name corresponding to the service name of the host device exists in the resource record, the network device identifies the overlay network path corresponding to the host name from the resource record, the overlay network path indicating the reachability information of the host device in the overlay network; The network device encapsulates the multicast query based on an overlay encapsulation protocol implemented at the first VTEP, wherein the encapsulated multicast query includes at least a portion of the overlay network path; as well as The network device routes the encapsulated multicast query to the host device via the overlay network path, making the service discoverable by the client device.

15. The method of claim 14, wherein the overlay network path includes a second-layer L2 virtual network instance (VNI) or a third-layer L3 VNI, and the IP address of the second VTEP.

16. The method of claim 14, wherein the multicast query is discarded in response to determining that the hostname does not exist in the resource record.

17. The method of claim 14, further comprising: The host device receives an encapsulated multicast service announcement from the second VTEP via the overlay network path, wherein the encapsulated multicast service announcement includes the host device's hostname and service name; Create a record entry that associates the overlay network path with the service name and the hostname; as well as The record entry is stored in the resource record, which is maintained at the first VTEP.

18. A network device, comprising: processor; A non-transitory computer-readable storage medium storing instructions that, when executed by the processor, cause the processor to: Receive a multicast service announcement from a host device connected to the network device, wherein the multicast service announcement includes the host name of the host device and the service name of the service announced by the host device, and wherein the network device is configured as a virtual tunnel endpoint (VTEP) in the overlay network; Identify a set of overlay network paths that connect the VTEP to other VTEPs in the overlay network; Resource records are created based on the multicast service announcement, wherein the resource records include entries that associate the host name of the host device of the VTEP to be connected in the overlay network with the service name and at least one of the identified overlay network paths; Receive a multicast query for the service announced by the host device, wherein the multicast query includes the service name of the service; In response to determining that the host name corresponding to the service name of the host device exists in the resource record, the at least one overlay network path identified is identified from the resource record; A set of copies of the multicast service announcement are created, and each copy of the multicast service announcement is forwarded along a corresponding overlay network path from the set of overlay network paths. Each of the replicas is encapsulated based on an overlay encapsulation protocol implemented at the VTEP, wherein each of the encapsulated replicas announced by the multicast service includes at least a portion of the encapsulated replica along the corresponding overlay network path along which it will be routed. as well as Each of the encapsulated replicas of the multicast service announcement is routed to each of the other VTEPs via the corresponding overlay network path.

19. The network device of claim 18, wherein the multicast service announcement is a multicast Domain Name System (mDNS) pointer PTR record with a Time-to-Live (TTL) of 1 second.

20. The network device of claim 18, wherein the processor is further configured to associate a role tag and a location tag of the host device with each of the copies of the encapsulated multicast service announcement, the role tag indicating a role-based access policy of the host device, and the location tag indicating the geographical region where the host device is located.

Images