CN109327374B - System and method for realizing three-layer VPN network access - Google Patents

System and method for realizing three-layer VPN network access Download PDF

Info

Publication number
CN109327374B
CN109327374B CN201710636116.8A CN201710636116A CN109327374B CN 109327374 B CN109327374 B CN 109327374B CN 201710636116 A CN201710636116 A CN 201710636116A CN 109327374 B CN109327374 B CN 109327374B
Authority
CN
China
Prior art keywords
openflow
sdn controller
bgp
client
router
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201710636116.8A
Other languages
Chinese (zh)
Other versions
CN109327374A (en
Inventor
徐锋
王仙平
吕屹
庞俊英
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhenle Technology Service (Shanghai) Co.,Ltd.
Original Assignee
Shanghai Layer Peak Network Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Layer Peak Network Technology Co ltd filed Critical Shanghai Layer Peak Network Technology Co ltd
Priority to CN201710636116.8A priority Critical patent/CN109327374B/en
Publication of CN109327374A publication Critical patent/CN109327374A/en
Application granted granted Critical
Publication of CN109327374B publication Critical patent/CN109327374B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The application discloses a system for realizing three-layer VPN network access, which comprises: the system comprises at least two client routers, a plurality of Openflow switches and an SDN controller; deploying an Openflow switch at a service access point; each client router is connected with at least one Openflow switch; the SDN controller manages the Openflow switch through an Openflow protocol; BGP neighbor relations are respectively established between the SDN controller and each client router; the SDN controller informs BGP routing information learned from each client router to other client routers; each customer router establishes local routing table information according to the learned BGP routing information of other customer routers; the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information and issues the Openflow flow tables to corresponding Openflow switches, and the Openflow switches realize the forwarding of flow among the connected client routers according to the Openflow flow tables, so that three-layer VPN network access is realized.

Description

System and method for realizing three-layer VPN network access
Technical Field
The application relates to the field of computer networks, in particular to a system and a method for realizing three-layer VPN network access.
Background
Today, in the global economy, branches of companies, companies and partners, suppliers, companies and customers may establish connection channels for information transfer. In the traditional enterprise networking scheme, no better solution exists for remote LAN-to-LAN interconnection except for the leased DDN private line or frame relay. Such a solution, however, entails high toll line renting fees and toll charges. Thus, a virtual Private network (vpn) should be created.
In the prior art, in an IP network, in order to implement three-layer VPN network interconnection (fig. 1 is a system architecture diagram for implementing three-layer VPN network access in the prior art), an operator needs to deploy a border router PE at a network edge, advertise a route between a PE router and a customer router CE through an EBGP protocol or other IGP routing protocols, and advertise a route between PE routers through MP-BGP to implement three-layer VPN based on MPLS.
The scheme for realizing three-layer VPN network access provided by the prior art has some defects: firstly, an operator needs to invest a PE router to build an MPLS L3VPN network, and the PE router needs to adopt a high-end router, so that the investment is high; secondly, when configuring the PE router, a large number of complex routing protocols need to be configured through a command line, which not only makes the service opening and maintenance in the early stage more complex, but also makes troubleshooting in the later stage more difficult.
In summary, the existing scheme for realizing three-layer VPN network access has the problems of large investment, complex service provisioning and difficult troubleshooting.
Disclosure of Invention
The application provides a system for realizing three-layer VPN network access, which aims to solve the problems of high investment, complex service opening and difficult troubleshooting of the conventional system for realizing three-layer VPN network interconnection.
The application provides a system for realizing three-layer VPN network access, which comprises: the system comprises at least two client routers, a plurality of Openflow switches and an SDN controller; these devices have the following relationships between them:
an Openflow switch is deployed at a service access point and used for providing three-layer VPN network access;
each client router is connected with at least one Openflow switch;
the SDN controller manages the Openflow switch through an Openflow protocol;
BGP neighbor relations are respectively established between the SDN controller and each client router;
the SDN controller learns the routing information of each client router through a BGP routing protocol, and notifies the BGP routing information learned from each client router to other client routers;
each customer router establishes local routing table information according to the learned BGP routing information of other customer routers;
the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information and issues the Openflow flow tables to corresponding Openflow switches, and the Openflow switches realize the forwarding of flow between networks connected with the client routers according to the Openflow tables, so that three-layer VPN network access is realized.
Optionally, the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information, and issues the Openflow flow tables to corresponding Openflow switches, where the method includes:
the SDN controller maps BGP routing information of the client router into forwarding entries in an Openflow flow table of the Openflow switch one by one and sends the forwarding entries to the corresponding Openflow switch; or
And the SDN controller maps the MAC address of the interconnection interface of the client router into a forwarding entry in an Openflow flow table and issues the forwarding entry to a corresponding Openflow switch.
Optionally, when a manner of mapping the MAC address of the interconnection interface of the client router to a forwarding entry in an Openflow flow table and issuing the forwarding entry to a corresponding Openflow switch is adopted, the IP addresses interconnected by the SDN controller and the client router are located in the same large network segment.
Optionally, when the SDN controller advertises, to other client routers, a BGP route learned from a client router, a BGP route server technique or a BGP route policy technique is used to ensure that a BGP next hop address of the advertised route remains unchanged.
Optionally, the routing protocol used when establishing the BGP neighbor relationship includes: EBGP routing protocol or IBGP routing protocol.
The application also provides a method for realizing three-layer VPN network access, which comprises the following steps:
deploying an Openflow switch at a service access point and deploying SDN controllers in a centralized manner;
BGP neighbor relations are respectively established between the SDN controller and each client router;
the SDN controller learns the routing information of each client router through a BGP routing protocol, and notifies the BGP routing information learned from each client router to other client routers;
each customer router establishes local routing table information according to the learned BGP routing information of other customer routers;
the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information and issues the Openflow flow tables to corresponding Openflow switches, and the Openflow switches realize the forwarding of flow between networks connected with the client routers according to the Openflow tables, so that three-layer VPN network access is realized.
Optionally, the establishing, between the SDN controller and each client router, a BGP neighbor relationship respectively includes:
the SDN controller establishes a management VLL between a port of each Openflow switch access customer router and the SDN controller;
and the SDN controller respectively establishes a BGP neighbor relation with each customer router through the management VLL.
Optionally, the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information, and issues the Openflow flow tables to corresponding Openflow switches, where the method includes:
and the SDN controller maps the MAC address of the interconnection interface of the client router into a forwarding entry in an Openflow flow table and issues the forwarding entry to a corresponding Openflow switch.
Optionally, the method includes:
and the IP addresses of the SDN controller and the client router which are interconnected are positioned in the same large network segment.
Optionally, when the SDN controller advertises, to other client routers, a BGP route learned from a client router, a BGP route server technique or a BGP route policy technique is used to ensure that a BGP next hop address of the advertised route remains unchanged.
Optionally, the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information, and issues the Openflow flow tables to corresponding Openflow switches, where the method includes:
and the SDN controller maps BGP routing information of the client router into forwarding entries in an Openflow flow table of the Openflow switch one by one and sends the forwarding entries to the corresponding Openflow switch.
Optionally, the routing protocol used when establishing the BGP neighbor relationship includes: EBGP routing protocol or IBGP routing protocol.
Compared with the prior art, the invention has the following advantages:
the application provides a system for realizing three-layer VPN network access, which comprises: the system comprises at least two client routers, a plurality of Openflow switches and an SDN controller; these devices have the following relationships between them: deploying an Openflow switch at a service access point for providing three-layer VPN network access; each client router is connected with at least one Openflow switch; the SDN controller manages the Openflow switch through an Openflow protocol; BGP neighbor relations are respectively established between the SDN controller and each client router; the SDN controller learns the routing information of each client router through a BGP routing protocol, and notifies the BGP routing information learned from each client router to other client routers; each customer router establishes local routing table information according to the learned BGP routing information of other customer routers; the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information and issues the Openflow flow tables to corresponding Openflow switches, and the Openflow switches realize the forwarding of flow between networks connected with the client routers according to the Openflow tables, so that three-layer VPN network access is realized.
The system for realizing three-layer VPN network access provided by the application has the following advantages: firstly, the Openflow switch adopted by the backbone network device in the scheme of the application usually adopts a white box switch supporting an Openflow protocol, and belongs to middle and low-end equipment, so that the investment is small; secondly, the routing protocol and the service opening and maintenance in the system provided by the application are realized by the SDN controller, and the SDN network adopts a graphical interface, so that the user interface is more friendly, the network investment can be greatly reduced, and the quick opening and flexible management of the service can be provided.
Drawings
Fig. 1 is a diagram of a system architecture for implementing three-layer VPN network access in the prior art.
Fig. 2 is a schematic system diagram illustrating a first method for constructing an Openflow flow table according to the first embodiment of the present application.
Fig. 3 is a schematic system diagram illustrating a second method for constructing an Openflow flow table according to the first embodiment of the present application.
Fig. 4 is a flowchart of a method for implementing three-layer VPN network access according to a second embodiment of the present application.
Detailed Description
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein, but rather construed as limited to the embodiments set forth herein.
Prior to describing embodiments of the present application, technical terms related to the present application will be described.
Routing table: refers to a routing information table stored on a router or other internet network device, where the table stores paths to specific network terminals.
VPN: the technology of providing private networks on a public communication infrastructure, operators typically satisfy the privacy requirements of customers by tunneling protocols and employing security mechanisms.
Three-layer VPN (L3 VPN): the method is applied to the private network service with three-layer requirements. The L3VPN service adopts a routing mode to forward the flow. After the router receives the traffic data packet, the destination address of the traffic data packet is searched in the route forwarding table, and the traffic data packet is transmitted across the network by using a pre-established channel. In order to sense the customer network, the operator uses the boundary router PE and the customer router CE to perform the interaction of the routing information.
SDN: software Defined Networking, a new network architecture innovative to traditional networks, aims to achieve a thorough separation of the data plane and the control plane of a network device.
SDN controller (SDN controller): refers to a control unit interacting with network elements (including switches, routers, etc.), and a single or multiple controllers constitute a control plane.
MPLS label: MPLS uses labels (labels) for data forwarding. When a packet enters the network, a short mark with a fixed length is allocated to the packet, and the mark and the packet are packaged together, and the switching node only forwards the packet according to the mark in the whole forwarding process.
OpenFlow: a new network protocol defines a new network switching model at the forwarding plane and a standard for communication with forwarding devices at the control plane.
VLL: virtual Leased Line, layer 2 Virtual private Line.
BGP: the commonly used IP routing protocol is used to advertise routes between different routers.
EBGP: an outer border gateway protocol.
IBGP: internal border gateway protocol.
VLAN: the virtual local area network isolates the service in a two-layer network.
OFS: and short for OpenFlow switch.
MAC: the location is defined by the physical address and the hardware address of the network equipment. In the OSI model, a third layer network layer is responsible for IP addresses and a second layer data link layer is responsible for MAC addresses.
Customer router ce (customer edge), customer edge equipment, customer end router to which the service provider is connected. The customer router CE provides service access for the customer by connecting one or more PE routers.
The flow table is composed of a plurality of flow table entries, each flow table entry is a forwarding rule, and a flow data packet entering the switch acquires a forwarding destination port by inquiring the flow table.
A first embodiment of the present application is a system for implementing three-layer VPN network access, including: the system comprises at least two client routers, a plurality of Openflow switches and an SDN controller; these devices have the following relationships between them:
an Openflow switch is deployed at a service access point and used for providing three-layer VPN network access;
each client router is connected with at least one Openflow switch;
the SDN controller manages the Openflow switch through an Openflow protocol;
BGP neighbor relations are respectively established between the SDN controller and each client router;
the SDN controller learns the routing information of each client router through a BGP routing protocol, and notifies the BGP routing information learned from each client router to other client routers;
each customer router establishes local routing table information according to the learned BGP routing information of other customer routers;
the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information and issues the Openflow flow tables to corresponding Openflow switches, and the Openflow switches realize the forwarding of flow between networks connected with the client routers according to the Openflow tables, so that three-layer VPN network access is realized.
In specific implementation, the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information, and issues the Openflow flow tables to corresponding Openflow switches, including two ways of constructing Openflow flow tables:
the first mode is as follows: the SDN controller maps BGP routing information of the client router into forwarding entries in an Openflow flow table of the Openflow switch one by one and sends the forwarding entries to the corresponding Openflow switch;
the second mode is as follows: and the SDN controller maps the MAC address of the interconnection interface of the client router into a forwarding entry in an Openflow flow table and issues the forwarding entry to a corresponding Openflow switch.
Fig. 2 is a schematic diagram of a system for constructing an Openflow flow table in a first manner according to the first embodiment of the present application. Fig. 3 is a schematic diagram of a system for constructing an Openflow flow table in a second manner according to the first embodiment of the present application.
In specific implementation, when BGP neighbor relations are respectively established between the SDN controller and each customer router, the SDN controller first establishes a management VLL between a port of each Openflow switch accessing the customer router and the SDN controller, and then the SDN controller establishes BGP neighbor relations between the management VLL and each customer router. The SDN controller may use an EBGP routing protocol or an IBGP routing protocol when establishing a BGP neighbor relationship with the client router. In fig. 2 and 3, EBGP neighbors are established between the SDN controller and each client router.
In the whole system, the SDN controller is in a core position, and learns BGP routing information to each client router through a neighbor routing protocol (e.g., EBGP), and advertises the BGP routing information learned from each client router to other client routers, so that the other client routers can learn BGP routing information to a remote network. For example, in fig. 2 and 3, the SDN controller learns BGP routing information to the customer router CE1 through the EBGP routing protocol and advertises it to the customer routers CE2 and CE 3; the SDN controller also advertises the learned BGP routing information for customer routers CE2 and CE3 to customer router CE 1. And advertising the BGP routing information of the client router to other client routers through the SDN controller, wherein each client router learns the BGP routing information of the other routers.
The SDN controller further records MAC address information corresponding to each CE interconnection IP address, for example, in fig. 2 and 3, the MAC address information corresponding to CE1 is 00:00:00:01, the MAC address information corresponding to CE2 is 00:00:00:02, and the MAC address information corresponding to CE3 is 00:00:00:00:00: 03.
It should be noted that, when the Openflow flow table is constructed in the second manner, the IP addresses of the SDN controller and the client router that are interconnected need to be in a large network segment. For example, in fig. 3, the IP addresses of the SDN controller and the customer routers CE1, CE2, and CE3 are interconnected within a large network segment: 10.1.1.0/24. When the SDN controller advertises a client router route, if a conventional BGP route advertising method is adopted, a BGP next hop address of the advertised route is changed into an IP address of the SDN controller, which does not meet the flow table design requirement in the scheme. Therefore, when the SDN advertises a client router route, it is necessary to ensure that a BGP next hop address of the advertised client router route remains unchanged through a BGP route server technology or a BGP routing policy technology.
After the learned BGP routing information of the other customer routers is obtained by each customer router, local routing table information may be established according to the learned BGP routing information of the other customer routers.
For example, the local routing table information of fig. 2:
CE1:
Routing Table:
11.1.1.0/24 local direct connection
11.1.2.0/24next-hop 10.1.1.2
11.1.3.0/24next-hop 10.1.1.2
CE2:
11.1.2.0/24 local direct connection
Routing Table:
11.1.1.0/24next-hop 10.1.2.2
11.1.3.0/24next-hop 10.1.2.2
CE3:
Routing Table:
11.1.3.0/24 local direct connection
11.1.1.0/24next-hop 10.1.3.2
11.1.2.0/24next-hop 10.1.3.2
The local routing table information of fig. 3 is:
CE1:
Routing Table:
11.1.1.0/24 local direct connection
11.1.2.0/24next-hop 10.1.1.2
11.1.3.0/24next-hop 10.1.1.3
CE2:
Routing Table:
11.1.2.0/24 local direct connection
11.1.1.0/24next-hop 10.1.1.1
11.1.3.0/24next-hop 10.1.1.3
CE3:
Routing Table:
11.1.3.0/24 local direct connection
11.1.1.0/24next-hop 10.1.1.1
11.1.2.0/24next-hop 10.1.1.2
To ensure that an Openflow switch correctly forwards a flow, an Openflow flow table needs to be configured for the Openflow switch, and there are two ways when configuring the flow table, the first way: the SDN controller maps BGP routing information of the client router into forwarding entries in an Openflow flow table of the Openflow switch one by one and issues the forwarding entries to the corresponding Openflow switch, namely the SDN controller maps the forwarding entries in the Openflow flow table of the Openflow switch one by one to issue to the corresponding Openflow switch through the learned BGP routing information of the whole network.
For example, the Openflow flow table of the Openflow switch in fig. 2 is:
OFS-1openflow table:
Entry1：match in_port p1+DIP 11.1.2.0/24actions＝output:link1,DMAC＝00:00:00:00:00:02
Entry2：match in_port p1+DIP 11.1.3.0/24actions＝output:link3,DMAC＝00:00:00:00:00:03
Entry3：match DIP 11.1.1.0/24actions＝output:p1
OFS-2openflow table:
Entry1：match in_port p1+DIP 11.1.1.0/24actions＝output:link1,DMAC＝00:00:00:00:00:01
Entry2：match in_port p1+DIP 11.1.3.0/24actions＝output:link2,DMAC＝00:00:00:00:00:03
Entry3：match DIP 11.1.2.0/24actions＝output:p1
OFS-3openflow table:
Entry1：match in_port p1+DIP 11.1.1.0/24actions＝output:link3,DMAC＝00:00:00:00:00:01
Entry2：match in_port p1+DIP 11.1.2.0/24actions＝output:link2,DMAC＝00:00:00:00:00:02
Entry3：match DIP 11.1.3.0/24actions＝output:p1
the link1, link2 and link3 are service traffic VLLs established between Openflow switches by the SDN controller, and are used for forwarding the service traffic.
link 1: forwarding traffic between CE1 and CE2 between OFS1 and OFS2
link 2: forwarding traffic between CE1 and CE3 between OFS1 and OFS3
link 1: forwarding traffic between CE2 and CE3 between OFS2 and OFS3
DIP is a destination IP of traffic, DMAC is a destination MAC of traffic, when traffic is sent from a client router CE to an Openflow switch, a destination MAC address is a MAC of an SDN controller, and a local Openflow switch directly sends the traffic to an Openflow switch at a destination end through links such as link1, link2, link3, and the like, so that the local Openflow switch needs to change the destination MAC of the traffic into a MAC address of a destination client router device where the traffic finally arrives.
It should be noted that the flow Entry in this example is not a complete flow Entry, and is intended to describe a part of the present application that is selected and related to the present application.
After the flow table of the switch is configured, the Openflow switch can forward the flow between the networks connected with the client router according to the Openflow flow table, so that three-layer VPN network access is realized.
For example, in fig. 2, after receiving traffic from network1 to network2, CE1 queries a local routing table according to destination address network segment 11.1.2.0/24 of the traffic, then sends the traffic to a port interconnected with OFS-1, where the OFS-1 matches traffic destination IP to Entry1 according to ingress port p1 of the traffic, and sends the traffic to OFS-2 through path link1, and where the OFS-2 matches the destination IP to Entry3, then sends the traffic to CE2 from port p 1. The forwarding of traffic from network1 to network2 is accomplished by flow tables.
In the first mode, the condition for matching the flow table is that a port through which the flow enters and a destination IP address of the flow, and because the number of the destination IP addresses is large, and routing changes are caused by reasons such as link interruption, client router routing changes, and the like, the Openflow switch needs to support a large number of flow table entries, and the SDN controller needs to update the flow table frequently.
The second mode is as follows: and the SDN controller maps the MAC address of the interconnection interface of the client router into a forwarding entry in an Openflow flow table and issues the forwarding entry to a corresponding Openflow switch, so that the configuration of the flow table is realized. The SDN controller maps the learned MAC addresses of the interconnection interfaces of the client routers to forwarding entries in an Openflow flow table, and the number of the forwarding entries can be reduced because only one MAC address of the interconnection interface of each client router is provided.
For example, the Openflow flow table of the Openflow switch in fig. 3 is:
OFS-1openflow table:
Entry1：match in_port p1+DMAC 00:00:00:00:00:02actions＝output:link1
Entry2：match in_port p1+DMAC 00:00:00:00:00:03actions＝output:link3
Entry3：match DMAC 00:00:00:00:00:01actions＝output:p1
OFS-2openflow table:
Entry1：match in_port p1+DMAC 00:00:00:00:00:01actions＝output:link1
Entry2：match in_port p1+DMAC 00:00:00:00:00:03actions＝output:link2
Entry3：match DMAC 00:00:00:00:00:02actions＝output:p1
OFS-3openflow table:
Entry1：match in_port p1+DMAC 00:00:00:00:00:01actions＝output:link3
Entry2：match in_port p1+DMAC 00:00:00:00:00:02actions＝output:link2
Entry3：match DMAC 00:00:00:00:00:03actions＝output:p1
the Link1, Link2, Link3 and DMAC are the same as those in fig. 2, and will not be described in detail.
After the flow table of the switch is configured, the Openflow switch can forward the traffic between the networks connected to the client router according to the Openflow flow table.
For example, in fig. 3, CE1 receives traffic from network1 to network2, and queries a local routing table according to destination address network segment 11.1.2.0/24 of the traffic, where next-hop of the route is 10.1.1.2, so that the destination MAC of the data packet is set to 00:00:00:00:02 and then sent to a port interconnected with OFS-1, an ingress port p1 on OFS-1 according to the traffic, the destination MAC of the traffic is matched to Entry1, the traffic is sent to OFS-2 through a path link1, and OFS-2 is sent to CE2 from port p1 after being matched to Entry3 according to the destination MAC.
By adopting the second mode, the condition of matching the flow table is the port for entering the flow and the destination MAC address of the flow, and because the target MAC matched is few, the MAC is the MAC of the client router port and has no relation with the destination IP of the user flow, thus the number of flow table entries required to be supported by the OFS can be greatly reduced, the oscillation convergence of the user route can not influence the content of the flow table, and the stability of the system is increased.
In fig. 2, which adopts the first approach, when the number of networks behind each customer router CE becomes 3, for example:
network connected to CE 1: 11.1.1.0/24, 11.1.11.0/24,11.1.21.0/24
Network connected to CE 2: 11.1.2.0/24, 11.1.12.0/24,11.1.22.0/24
Network connected to CE 3: 11.1.3.0/24, 11.1.13.0/24,11.1.23.0/24
The OPS-1 flow table is:
Entry1：match in_port p1+DIP 11.1.2.0/24actions＝output:link1,DMAC＝00:00:00:00:00:02
Entry2：match in_port p1+DIP 11.1.12.0/24actions＝output:link1,DMAC＝00:00:00:00:00:02
Entry3：match in_port p1+DIP 11.1.22.0/24actions＝output:link1,DMAC＝00:00:00:00:00:02
Entry4：match in_port p1+DIP 11.1.3.0/24actions＝output:link3,DMAC＝00:00:00:00:00:03
Entry5：match in_port p1+DIP 11.1.13.0/24actions＝output:link3,DMAC＝00:00:00:00:00:03
Entry6：match in_port p1+DIP 11.1.23.0/24actions＝output:link3,DMAC＝00:00:00:00:00:03
Entry7：match DIP 11.1.1.0/24actions＝output:p1
Entry8：match DIP 11.1.11.0/24actions＝output:p1
Entry9：match DIP 11.1.21.0/24actions＝output:p1
it can be seen that, in the first way, the number of flow entries of the Openflow switch increases as the number of networks connected behind the customer router CE increases.
In fig. 3, when the number of networks connected behind each CE becomes 3, each OPS flow table still contains 3 flow entries.
The following table compares the size of the flow table in the case where the number of CE local advertisement route entries is different:
Figure BDA0001364902050000121
as can be seen from the above table, when the second method is adopted, after the network topology is determined, the number of entries of the routing table is increased and decreased by the customer router CE, the number of entries of the flow table of the Openflow switch is not affected, and the oscillation convergence of the user route does not affect the content of the flow table.
The system for realizing three-layer VPN network access is introduced, and the system adopts a middle-low end Openflow switch to replace a traditional high-end PE router, so that the investment is low; secondly, the routing protocol and the service opening and maintenance in the system provided by the application are realized by the SDN controller, and the SDN network adopts a graphical interface, so that the user interface is more friendly, the network investment can be greatly reduced, and the quick opening and flexible management of the service can be provided. In particular, the second mode can also increase the stability of the system.
Based on the system for implementing three-layer VPN network access provided by the present application, a second embodiment of the present application provides a method for implementing three-layer VPN network access. Referring to fig. 4, a flowchart of a method for implementing three-layer VPN network access according to a second embodiment of the present application is shown. This is described below with reference to fig. 2, 3, and 4.
Step S401, deploying an Openflow switch and deploying SDN controllers in a centralized manner at a service access point.
The service access point refers to a service access point of an operator.
In specific implementation, the SDN controller is deployed on a server, and the SDN controller controls the Openflow switch through an Openflow protocol.
Step S402, BGP neighbor relations are respectively established between the SDN controller and each client router.
The purpose of this step is to realize the exchange of routing information between the SDN controller and the client router by respectively establishing BGP neighbor relations between the SDN controller and each client router.
The neighbor relation refers to a neighbor relation established by adopting a certain routing protocol, such as an EBGP routing protocol neighbor relation.
When a BGP neighbor relation is respectively established between the SDN controller and each customer router, the SDN controller firstly establishes a management VLL between a port of each Openflow switch accessing the customer router and the SDN controller, and then the SDN controller respectively establishes the BGP neighbor relation between the management VLL and each customer router. The SDN controller may use an EBGP routing protocol or an IBGP routing protocol when establishing a BGP neighbor relationship with the client router. In fig. 2 and 3, EBGP neighbors are established between the SDN controller and each client router.
Step S403, the SDN controller learns the routing information of each client router through the BGP routing protocol, and notifies the BGP routing information learned from each client router to other client routers.
After the BGP neighbor relationships are respectively established between the SDN controller and each customer router, the SDN controller may notify the BGP routing information learned from each customer router to other customer routers.
For example, in fig. 2 and 3, the SDN controller learns BGP routing information to the customer router CE1 through the EBGP routing protocol and advertises it to the customer routers CE2 and CE 3; the SDN controller also advertises the learned BGP routing information for customer routers CE2 and CE3 to other customer routers. Each customer router learns BGP routing information for other routers by advertising the customer router's BGP routing information to customer router CE1 through the SDN controller.
The SDN controller further records MAC address information corresponding to each CE interconnection IP address, for example, in fig. 2 and 3, the MAC address information corresponding to CE1 is 00:00:00:01, the MAC address information corresponding to CE2 is 00:00:00:02, and the MAC address information corresponding to CE3 is 00:00:00:00:00: 03.
And step S404, each client router establishes local routing table information according to the learned BGP routing information of other client routers.
The client router includes the routing network segment and the next hop information in the routing table information, when the flow is forwarded, the client router inquires the routing table information according to the destination IP address of the flow, and the flow is forwarded after matching with the corresponding routing entry.
For example, the local routing table information of fig. 2:
CE1:
Routing Table:
11.1.1.0/24 local direct connection
11.1.2.0/24next-hop 10.1.1.2
11.1.3.0/24next-hop 10.1.1.2
CE2:
11.1.2.0/24 local direct connection
Routing Table:
11.1.1.0/24next-hop 10.1.2.2
11.1.3.0/24next-hop 10.1.2.2
CE3:
Routing Table:
11.1.3.0/24 local direct connection
11.1.1.0/24next-hop 10.1.3.2
11.1.2.0/24next-hop 10.1.3.2
The local routing table information of fig. 3 is:
CE1:
Routing Table:
11.1.1.0/24 local direct connection
11.1.2.0/24next-hop 10.1.1.2
11.1.3.0/24next-hop 10.1.1.3
CE2:
Routing Table:
11.1.2.0/24 local direct connection
11.1.1.0/24next-hop 10.1.1.1
11.1.3.0/24next-hop 10.1.1.3
CE3:
Routing Table:
11.1.3.0/24 local direct connection
11.1.1.0/24next-hop 10.1.1.1
11.1.2.0/24next-hop 10.1.1.2
Step S405, the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information, and issues the Openflow tables to corresponding Openflow switches, and the Openflow switches implement forwarding of traffic between networks connected to the client routers according to the Openflow tables, thereby implementing three-layer VPN network access.
The SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information and issues the Openflow flow tables to corresponding Openflow switches, and the method comprises two ways of constructing the Openflow flow tables:
the first mode is as follows: the SDN controller maps BGP routing information of the client router into forwarding entries in an Openflow flow table of the Openflow switch one by one and sends the forwarding entries to the corresponding Openflow switch;
the second mode is as follows: and the SDN controller maps the MAC address of the interconnection interface of the client router into a forwarding entry in an Openflow flow table and issues the forwarding entry to a corresponding Openflow switch.
It should be noted that, when the Openflow flow table is constructed in the second manner, the IP addresses of the SDN controller and the client router that are interconnected need to be in a large network segment. For example, in fig. 3, the IP addresses of the SDN controller and the customer routers CE1, CE2, and CE3 are interconnected within a large network segment: 10.1.1.0/24. When the SDN controller advertises a client router route, if a conventional BGP route advertising method is adopted, a BGP next hop address of the advertised route is changed into an IP address of the SDN controller, which does not meet the flow table design requirement in the scheme. Therefore, when the SDN advertises a client router route, it is necessary to ensure that a BGP next hop address of the advertised client router route remains unchanged through a BGP route server technology or a BGP routing policy technology.
The Openflow flow tables generated in the two ways, the flow forwarding implementation process, and the differences between the two ways are described in detail in the first embodiment, and the details are referred to the first embodiment, and are not described in detail here.
According to the method for realizing three-layer VPN network access, three-layer VPN interconnection among client networks is provided through an SDN network, and backbone network equipment is built by a white box switch supporting an openflow protocol, so that network investment can be greatly reduced; in addition, the routing protocol and the service activation and maintenance in the method provided by the application are realized by the SDN controller, and the SDN network adopts a graphical interface, so that the user interface is more friendly, and the quick activation and flexible management of the service can be provided.
Although the present invention has been described with reference to the preferred embodiments, it is not intended to be limited thereto, and variations and modifications may be made by those skilled in the art without departing from the spirit and scope of the present invention.

Claims (12)

1. A system for enabling three-tier VPN network access, the system comprising: the system comprises at least two client routers, a plurality of Openflow switches and an SDN controller; these devices have the following relationships between them:
an Openflow switch is deployed at a service access point and used for providing three-layer VPN network access;
each client router is connected with at least one Openflow switch;
the SDN controller manages the Openflow switch through an Openflow protocol;
BGP neighbor relations are respectively established between the SDN controller and each client router;
the SDN controller learns the routing information of each client router through a BGP routing protocol, and notifies the BGP routing information learned from each client router to other client routers;
each customer router establishes local routing table information according to the learned BGP routing information of other customer routers;
the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information and issues the Openflow flow tables to corresponding Openflow switches, and the Openflow switches realize the forwarding of flow between networks connected with the client routers according to the Openflow tables, so that three-layer VPN network access is realized.
2. The system of claim 1, wherein the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information, and issues the Openflow tables to corresponding Openflow switches, and the system comprises:
the SDN controller maps BGP routing information of the client router into forwarding entries in an Openflow flow table of the Openflow switch one by one and sends the forwarding entries to the corresponding Openflow switch; or
And the SDN controller maps the MAC address of the interconnection interface of the client router into a forwarding entry in an Openflow flow table and issues the forwarding entry to a corresponding Openflow switch.
3. The system of claim 1, wherein when the MAC address of the interconnection interface of the client router is mapped into a forwarding entry in an Openflow flow table and issued to the corresponding Openflow switch, the IP addresses of the interconnection of the SDN controller and the client router are located in the same large network segment.
4. The system of claim 3, wherein the SDN controller employs a BGP route server technique or a BGP route policy technique to ensure that a BGP next hop address of the advertised route remains unchanged when advertising the BGP route learned from the client router to other client routers.
5. The system of claim 1, wherein the routing protocol used in establishing the BGP neighbor relation comprises: EBGP routing protocol or IBGP routing protocol.
6. A method for realizing three-layer VPN network access is characterized by comprising the following steps:
deploying an Openflow switch at a service access point and deploying SDN controllers in a centralized manner;
each client router is connected with at least one Openflow switch;
the SDN controller manages the Openflow switch through an Openflow protocol;
BGP neighbor relations are respectively established between the SDN controller and each client router;
the SDN controller learns the routing information of each client router through a BGP routing protocol, and notifies the BGP routing information learned from each client router to other client routers;
each customer router establishes local routing table information according to the learned BGP routing information of other customer routers;
the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information and issues the Openflow flow tables to corresponding Openflow switches, and the Openflow switches realize the forwarding of flow between networks connected with the client routers according to the Openflow tables, so that three-layer VPN network access is realized.
7. The method of claim 6, wherein establishing a BGP neighbor relationship between the SDN controller and each customer router comprises:
the SDN controller establishes a management VLL between a port of each Openflow switch access customer router and the SDN controller;
and the SDN controller respectively establishes a BGP neighbor relation with each customer router through the management VLL.
8. The method of claim 7, wherein the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information, and issues the Openflow flow tables to corresponding Openflow switches, and the method comprises:
and the SDN controller maps the MAC address of the interconnection interface of the client router into a forwarding entry in an Openflow flow table and issues the forwarding entry to a corresponding Openflow switch.
9. The method of claim 8, wherein the method comprises:
and the IP addresses of the SDN controller and the client router which are interconnected are positioned in the same large network segment.
10. The method of claim 8 or 9, wherein when the SDN controller advertises the BGP route learned from the client router to other client routers, a BGP route server technique or a BGP routing policy technique is used to ensure that a BGP next hop address of the advertised route remains unchanged.
11. The method of claim 6 or 7, wherein the SDN controller constructs different Openflow flow tables according to the collected BGP routing information and routing topology information, and issues the Openflow flow tables to corresponding Openflow switches, and the method comprises:
and the SDN controller maps BGP routing information of the client router into forwarding entries in an Openflow flow table of the Openflow switch one by one and sends the forwarding entries to the corresponding Openflow switch.
12. The method according to any of claims 6-9, wherein the routing protocol used in establishing the BGP neighbor relation comprises: EBGP routing protocol or IBGP routing protocol.
CN201710636116.8A 2017-07-31 2017-07-31 System and method for realizing three-layer VPN network access Active CN109327374B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710636116.8A CN109327374B (en) 2017-07-31 2017-07-31 System and method for realizing three-layer VPN network access

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710636116.8A CN109327374B (en) 2017-07-31 2017-07-31 System and method for realizing three-layer VPN network access

Publications (2)

Publication Number Publication Date
CN109327374A CN109327374A (en) 2019-02-12
CN109327374B true CN109327374B (en) 2021-09-28

Family

ID=65245565

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710636116.8A Active CN109327374B (en) 2017-07-31 2017-07-31 System and method for realizing three-layer VPN network access

Country Status (1)

Country Link
CN (1) CN109327374B (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110380900B (en) * 2019-07-12 2022-03-08 中国电信集团工会上海市委员会 Network configuration system based on SDN
CN112769699B (en) * 2019-11-05 2022-04-15 烽火通信科技股份有限公司 Method and controller for distributing and updating routing information in SD-WAN (secure digital-Wide area network)
CN112838985B (en) * 2019-11-25 2024-04-02 中兴通讯股份有限公司 Heterogeneous network communication method, system and controller
CN115086978B (en) * 2021-03-11 2024-05-07 中国移动通信集团四川有限公司 Network function virtualization SDN network system
CN113794617B (en) * 2021-08-31 2023-04-07 新华三信息安全技术有限公司 Open flow Openflow instance binding method and device
CN116760764B (en) * 2023-08-18 2023-11-17 深圳捷誊技术有限公司 Route announcement method, server node, information bulletin board and storage medium
CN116996406B (en) * 2023-09-22 2024-02-02 山东未来互联科技有限公司 Provincial SDN backbone network networking-based data interaction management system and method

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102449964A (en) * 2011-07-22 2012-05-09 华为技术有限公司 Three-layer virtual exclusive network routing control method, apparatus and system
CN104092684A (en) * 2014-07-07 2014-10-08 杭州华三通信技术有限公司 Method and device for supporting VPN based on OpenFlow protocol
EP3110083A1 (en) * 2014-02-19 2016-12-28 Nec Corporation Communication system, control device, communication control method and program
WO2017015667A1 (en) * 2015-07-23 2017-01-26 Cisco Technology, Inc. Systems, methods, and devices for smart mapping and vpn policy enforcement
CN106713137A (en) * 2015-11-13 2017-05-24 中国电信股份有限公司 VPN method based on segment routing and SDN technology and device and system thereof

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9331938B2 (en) * 2012-04-13 2016-05-03 Nicira, Inc. Extension of logical networks across layer 3 virtual private networks

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102449964A (en) * 2011-07-22 2012-05-09 华为技术有限公司 Three-layer virtual exclusive network routing control method, apparatus and system
EP3110083A1 (en) * 2014-02-19 2016-12-28 Nec Corporation Communication system, control device, communication control method and program
CN104092684A (en) * 2014-07-07 2014-10-08 杭州华三通信技术有限公司 Method and device for supporting VPN based on OpenFlow protocol
WO2017015667A1 (en) * 2015-07-23 2017-01-26 Cisco Technology, Inc. Systems, methods, and devices for smart mapping and vpn policy enforcement
CN106713137A (en) * 2015-11-13 2017-05-24 中国电信股份有限公司 VPN method based on segment routing and SDN technology and device and system thereof

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Agile VPN for Carrier/SP Network. ONOS- based SDN Controller for China Unicom MPLS L3VPN Service";China Unicom;《URL：http://img.lightreading.com/downloads/Agile-VPN-for-CarrierSP-Network-ONOS-based-SDN-Controller-for-China-Unicom-MPLS-L3VPN-Service.pdf》;20150630;正文第1-6页 *
"AT&T and Ericsson presenting SDN-based L3VPN solution for Telco NFV needs";Patrick Jestin;《URL：https://www.ericsson.com/en/blog/2015/6/att-and-ericsson-presenting-sdn-based-l3vpn-solution-for-telco-nfv-needs》;20150615;全文 *

Also Published As

Publication number Publication date
CN109327374A (en) 2019-02-12

Similar Documents

Publication Publication Date Title
CN109327374B (en) System and method for realizing three-layer VPN network access
CN112840625B (en) First hop migration gateway redundancy in a network computing environment
US8068442B1 (en) Spanning tree protocol synchronization within virtual private networks
US7756998B2 (en) Managing L3 VPN virtual routing tables
Pepelnjak et al. MPLS and VPN architectures
AU2004227785B2 (en) Method for recursive BGP route updates in MPLS networks
US8151000B1 (en) Transparently providing layer two (L2) services across intermediate computer networks
US9100213B1 (en) Synchronizing VPLS gateway MAC addresses
US20040255028A1 (en) Functional decomposition of a router to support virtual private network (VPN) services
US20120287818A1 (en) Multipoint-to-multipoint service for a communications network
CN104219147A (en) Implementation method and device of VPN (virtual private network) for edge equipment
CN110022262B (en) Method, system and device for realizing plane separation based on SDN (software defined network)
US7280534B2 (en) Managed IP routing services for L2 overlay IP virtual private network (VPN) services
CN112671650B (en) End-to-end SR control method, system and readable storage medium under SD-WAN scene
US8949460B2 (en) Apparatus and method for layer-2 and layer-3 VPN discovery
CN113630324A (en) Novel cross-domain interconnection method based on MPLS-VPN
Cisco Troubleshooting Tag and MLPS Switching Connections
Cisco Troubleshooting Tag and MPLS Switching Connections
CN112838985B (en) Heterogeneous network communication method, system and controller
Cisco Configuring Tag Switching
Wu et al. Research on the application of cross-domain VPN technology based on MPLS BGP
Joseph et al. Network convergence: Ethernet applications and next generation packet transport architectures
Yan et al. Configuration method of cross-domain MPLS VPN based on double MCE
CN112737951B (en) End-to-end SR control method, system and readable storage medium in public and private network mixed scene
WO2024001553A1 (en) Routing publishing method, electronic device and computer-readable storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20200324

Address after: 200040 room 1013, No. 250, JIANGCHANG Third Road, Jing'an District, Shanghai

Applicant after: Shanghai layer peak Network Technology Co., Ltd

Address before: 310012 506, room 4, 998 West Wen Yi Road, Wuchang Street, Yuhang District, Hangzhou, Zhejiang.

Applicant before: HANGZHOU DAHU TECHNOLOGY Co.,Ltd.

GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20220121

Address after: 200072 room 607, No. 1256 and 1258, Wanrong Road, Jing'an District, Shanghai

Patentee after: Zhenle Technology Service (Shanghai) Co.,Ltd.

Address before: Room 1013, no.250, JIANGCHANG Third Road, Jing'an District, Shanghai 200040

Patentee before: Shanghai layer peak Network Technology Co.,Ltd.