Introduction
Figure 2-1 shows
the Control Plane operation when host EP1 using IP 172.16.100.10/32 joins the
network. In the previous chapter, we saw how Edge-xTR-11 learned the IP address
and registered it to MapSrv-22 by using the LISP Map-register Message where the
Instance-Id 100 represents Virtual Network-Id (VN-Id). MapSrv-22, in turn,
advertised the NLRI to Border-PxTR-13 as BGP VPNv4 Update message where
extended community RT 1:100 (=VN-Id) is used as a kind of VPN identifier (BGP
VPNv4 route import/export policy is based on RT value). This chapter first
explains how Border-PxTR-13 sends BGP IPv4 Update message to local SD-WAN
device vEdge-1. The eBGP peering between Border-PxTR-13 and vEdge1 is VRF based
and BGP updates over it don’t carry any VN-Id. vEdge-1 imports the routing
information from BRIB to RIB. Then it advertises the routing information by
using OMP (Overlay Management Protocol) to the SD-WAN centralized Control Plane
vSmart over the DTLS tunnel using System-IP as an originator-Id and VPN label
1003 as a VN-Id. vSmart forwards this update to SD-WAN device vEdge-2 located
in Datacenter. vEdge-2 installs the route into the routing table. After that,
it exports the routing information from the RIB to the BGP process and sends
the BGP IPv4 Update message to Border-Leaf-13 over VRF NWKT eBGP peering
without VN-Id.
Figure 2-1: Overall Control-Plane Operation.
BRIB, RIB, and OMP on Local Edge
When
vEdge-1 receives the BGP update about 172.16.100.0/24, it first imports the
route into the VPN 10 BGP table and from there to VPN 10 RIB. The next-hop for
the route is 172.16.10.13 (Border-PxTR-13). From VPN 10 RIB routing information
is exported to the OMP database (Overlay Management Protocol) with Label 1003
that is used as VPN-Id. The OMP table includes several entry-specific
attributes, just like BGP. Originator, Site-Id, and Origin Protocol attributes
are quite self-explanatory. The Transport Locator (TLOC) describes, as the name
implies, the transport network along which you can use to get to the
destination network. We only have one transport network, Public-Internet, in
our example but in real life, there will be more than just one transport
network. TLOC also describes the tunneling mechanism which the originator uses
with this particular transport network as well as the originator's System
Identifier (Sys-ID).
Figure 2-2: vEdge Local Processes - Import Route into
BRIB, RIB, and OMP.
Capture 2-1 shows
the BGP Update sent by Border-PxTR-13. Notice that the aggregate origin is the
LISP Control-Plane Node MapSrv-22.
Internet
Protocol Version 4, Src: 172.16.10.13, Dst: 172.16.10.1
Transmission
Control Protocol, Src Port: 179, Dst Port: 43025, Seq: 1, Ack: 1, Len: 61
Border
Gateway Protocol - UPDATE Message
Marker: ffffffffffffffffffffffffffffffff
Length: 61
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 34
Path attributes
Path Attribute - ORIGIN: IGP
Path Attribute - AS_PATH: 65010
Path Attribute - AGGREGATOR: AS: 65010
origin: 192.168.0.22
Path Attribute - ATOMIC_AGGREGATE
Path Attribute - NEXT_HOP: 172.16.10.13
Network Layer Reachability Information
(NLRI)
172.16.100.0/24
NLRI prefix length: 24
NLRI prefix: 172.16.100.0
Capture 2-1: BGP Update from Border-PxTR-13 to vEdge1.
Example
2-1 shows the routing information about network 172.16.100.0/24 in the VPN 10
RIB of vEdge-1. The route is selected as the best route and installed into FIB
(Forwarding Information Base - Data-Plane) with the next-hop 172.16.10.13
reachable via the interface ge0/2.
vEdge-1# show ip routes bgp detail
Codes
Proto-sub-type:
IA -> ospf-intra-area, IE ->
ospf-inter-area,
E1 -> ospf-external1, E2 ->
ospf-external2,
N1 -> ospf-nssa-external1, N2 ->
ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes
Status flags:
F -> fib, S -> selected, I ->
inactive,
B -> blackhole, R -> recursive, L ->
import
""--------------------------------------------
VPN 10
PREFIX 172.16.100.0/24
--------------------------------------------
proto
bgp
proto-sub-type
e
distance
20
metric
0
uptime
0:00:06:45
nexthop-ifname
ge0/2
nexthop-addr
172.16.10.13
status
F,S
Example 2-1: VPN 10 RIB Entry about Network
172.16.100.0/24.
Example
2-2 shows the OMP table of vEdge-1about 172.16.100.0/24. The route is
redistributed to OMP and that is why the peer listed under received from section is 0.0.0.0 and the origin attribute is the
system-id of vEdge-1. vEdge-1 advertises the information to SD-WAN
Control-Plane node vSmart using Label 1003 as VN-Id.
vEdge-1# show omp routes received detail
---------------------------------------------------
omp route
entries for vpn 10 route 172.16.100.0/24
---------------------------------------------------
RECEIVED FROM:
peer 0.0.0.0
path-id 37
label 1003
status C,Red,R
Attributes:
originator 10.100.100.101
type installed
tloc 10.100.100.101, public-internet,
gre
overlay-id 1
site-id 10
origin-proto eBGP
origin-metric 0
ADVERTISED TO:
peer 10.100.100.13
Attributes:
originator 10.100.100.101
label 1003
path-id 37
tloc 10.100.100.101, public-internet,
gre
site-id 10
overlay-id 1
origin-proto eBGP
origin-metric 0
Example 2-2: OMP Routing Information about Network
172.16.100.0/24.
Setting Up Data-Path - OMP TLOC Route
Before
explaining how the routing information about network 172.16.100.0/24 is
propagated to remote vEdge-2 over SD-WAN I will shortly introduce the OMP TLOC
routes. In order to send traffic to network 172.16.100.0/24, the remote SD-WAN
device vEdge-2 has to know a) the transport network where vEdge-1 is connected
(Public-Internet), b) What is the public IP address that vEdge-1 uses for the transport
connection (10.100.0.101), c) what is the tunneling protocol (GRE in our case),
and d) does vEdge-1 allow tunneling only within one transport network (true =
restrict bit set to 1). Based on this information vEdge-2 builds the Overlay
Network using GRE (Generic Route Encapsulation) tunneling solution. Note, I’m
using GRE only because I want clear text packet captures from data packets send
between vEdge-1 and vEdge-2. Before setting up the GRE tunnel, vEdge-2 confirms
that vEdge-1 is reachable by using BFD (Bi-Directional Forwarding Detection).
Figure 2-3 shows how vEdge-1 sends OMP TLOC information to vSmart, which
forwards the information to the remote edge device vEdge-2. edge devices
exchange routing information only with vSmart, never between themselves.
Figure 2-3: OMP TLOC Process.
Example
2-3 shows the OMP TLOC route that vEdge-1 advertises to SD-WAN Control-Plane
node vSmart (10.100.100.13). vEdge-1 tells that it belongs to site 10 and is
connected to the transport network Public-Internet by using an IP address
10.100.0.101 (listed as public-ip). It also describes that it uses GRE as a tunneling
protocol and accepts tunneling only from edge nodes that are connected to the
same transport network (restrict bit set to one).
vEdge-1#
show omp tlocs | exclude not | nomore
---------------------------------------------------
tloc
entries for 10.100.100.101
public-internet
gre
---------------------------------------------------
RECEIVED FROM:
peer 0.0.0.0
status C,Red,R
Attributes:
attribute-type installed
encap-key 0
public-ip 10.100.0.101
public-port 0
private-ip 10.100.0.101
private-port 0
<IPv6 part snipped>
bfd-status up
site-id 10
preference 0
weight 1
version 3
gen-id 0x80000034
carrier default
restrict 1
<snipped>
ADVERTISED TO:
peer 10.100.100.13
Attributes:
encap-key 0
public-ip 10.100.0.101
public-port 0
private-ip 10.100.0.101
private-port 0
<IPv6 part snipped>
site-id 10
preference
0
weight 1
version 3
gen-id 0x80000034
carrier default
restrict 1
on-demand 0
<snipped>
Example 2-3: vEdge-1 - OMP TLOC entries.
Example
2-4 shows OMP TLOC routing information that vSmart has received from vEdge-1
(10.100.100.101).
vsmart#
show omp tlocs | exclude not | nomore
---------------------------------------------------
tloc
entries for 10.100.100.101
public-internet
gre
---------------------------------------------------
RECEIVED FROM:
peer 10.100.100.101
status C,I,R
Attributes:
attribute-type installed
encap-key 0
public-ip 10.100.0.101
public-port 0
private-ip 10.100.0.101
private-port 0
<snipped>
site-id 10
<snipped>
restrict 1
<snipped>
Example 2-4: vSmart - OMP TLOC entries.
Example
2-5 shows the OMP TLOC routing information that remote vEdge-2 has learned from
vSmart (10.100.100.13).
vEdge2#
show omp tlocs | exclude not | nomore
---------------------------------------------------
tloc
entries for 10.100.100.101
public-internet
gre
---------------------------------------------------
RECEIVED FROM:
peer 10.100.100.13
status C,I,R
Attributes:
attribute-type installed
encap-key 0
public-ip 10.100.0.101
public-port 0
private-ip 10.100.0.101
private-port 0
<snipped>
bfd-status up
site-id 10
<snipped>
restrict 1
<snipped>
Example 2-5: vEdge-2 - OMP TLOC entries.
Example 2-6
verifies the BFD session between vEdge-1 and vEdge-2.
vEdge2# show bfd sessions
system-ip 10.100.100.101 | beg 10.
10.100.100.101 10 up
public-internet public-internet
10.100.0.102 10.100.0.101 gre
Example 2-6: BFD Session Between vEdge-2 and vEdge-1.
Example
2-7 shows that GRE tunneling between vEdge-1 and vEdg-2. Note, that statistic is
not shown in the example.
vEdge2# show tunnel
statistics
tunnel stats gre 10.100.0.102 10.100.0.101 0 0
system-ip 10.100.100.101
local-color public-internet
remote-color public-internet
<snipped>
Example 2-7: GRE Tunneling Between vEdge-1 and vEdge-2.
Overlay Network Control-Plane - OMP Service Route
When vEdge-1 and vEdge-2 know each other’s TLOC information, they can install customer routing information into the RIB. Figure 2-4 illustrates the process, where vEdge-1 advertises the OMP Service route about network 172.16.100.0/24 to vSmart over the DTLS tunnel. The VPN-Id VPN 10 is used as VN-Id in Control-Plane. Based on that the vEdge-2 installs the information into the correct VPN RIB. OMP Service route also carries a set of attributes. These attributes describe the VN-Id used in Data-Plane (Label 1003), TLOC information, and Site-Id among the other things. vSmart verifies that the vEdge-1 is reachable before forwarding the OMP Service route to vEdge-2. vEdge-2 also verifies that it can route data to vEdge-1 before installing the information into the RIB. The OMP Service route doesn’t carry the Underlay Network routable public IP address. vEdge-2 knows how to reach vEdge-1 based TLOC database.
Figure 2-4: OMP Service Route Propagation.
Example
2-8 shows that vEdge-1 is redistributed the route from the eBGP into OMP
Process. Status bits describe that the route is Chosen (C), Redistributed (R),
and the Origin is Reachable (R). vEdge-1 advertises this information to vSmart
(10.100.100.13).
vEdge1# show omp routes received detail
---------------------------------------------------
omp route entries for
vpn 10 route 172.16.100.0/24
---------------------------------------------------
RECEIVED FROM:
peer 0.0.0.0
path-id 37
label 1003
status C,Red,R
Attributes:
originator 10.100.100.101
type installed
tloc 10.100.100.101, public-internet,
gre
overlay-id 1
site-id 10
origin-proto eBGP
origin-metric 0
ADVERTISED TO:
peer 10.100.100.13
Attributes:
originator 10.100.100.101
label 1003
path-id 37
tloc 10.100.100.101, public-internet,
gre
site-id 10
overlay-id 1
origin-proto eBGP
origin-metric 0
vEdge-1#
Example 2-8: OMP Service Route Information on vEdge-1.
Example
2-9 shows that vSmart has received the OMP Service route from vEdge-1. Status
bits describe that the route is Chosen (C) and that the origin is Reachable
(R). Example 2-9 also shows that vSmart advertises the information to vEdge-2.
vsmart# show omp routes received detail | exclude
not\ set | nomore
---------------------------------------------------
omp route entries for
vpn 10 route 172.16.100.0/24
---------------------------------------------------
RECEIVED FROM:
peer 10.100.100.101
path-id 37
label 1003
status C,R
Attributes:
originator 10.100.100.101
type installed
tloc 10.100.100.101, public-internet,
gre
overlay-id 1
site-id
10
origin-proto eBGP
origin-metric 0
ADVERTISED TO:
peer 10.100.100.102
Attributes:
originator 10.100.100.101
label 1003
path-id 6
tloc 10.100.100.101, public-internet,
gre
site-id 10
overlay-id 1
origin-proto eBGP
origin-metric 0
Example 2-9: OMP Service Route Information on vSmart.
Example
2-10 shows that vEdge-2 has received the OMP Service route from vSmart.
vEdge2# show omp routes received detail | exclude
not | nomore
---------------------------------------------------
omp route entries for
vpn 10 route 172.16.100.0/24
---------------------------------------------------
RECEIVED FROM:
peer 10.100.100.13
path-id 6
label 1003
status C,I,R
Attributes:
originator 10.100.100.101
type installed
tloc 10.100.100.101, public-internet,
gre
overlay-id 1
site-id 10
origin-proto eBGP
origin-metric 0
vEdge2#
Example 2-10: OMP Service Route Information on vEdge-2.
Example
2-11 shows VPN 10 RIB o vEdge-2. vEdge-2 does recursive route lookup for tloc-ip from the TLOC database in order
to find the IP address used in the tunnel header. vEdge-2 sends data packets to
VPN 10 network 172.16.100.0/24 over the Public-Internet transport network using
GRE encapsulation and VPN label 1003.
vEdge2# show ip routes vpn 10 172.16.100.0/24
detail
Codes Proto-sub-type:
IA -> ospf-intra-area, IE ->
ospf-inter-area,
E1 -> ospf-external1, E2 ->
ospf-external2,
N1 -> ospf-nssa-external1, N2 ->
ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I ->
inactive,
B -> blackhole, R -> recursive, L ->
import
""--------------------------------------------
VPN 10
PREFIX 172.16.100.0/24
--------------------------------------------
proto
omp
distance
250
metric
0
uptime 0:00:04:42
tloc-ip
10.100.100.101
tloc-color
public-internet
tloc-encap
gre
nexthop-label
1003
status
F,S
Example 2-11: VPN 10 RIB on vEdge-2.
OMP to BGP on Remote Edge
Figure
2-5 illustrates the process of how vEdge-2 redistributes OMP VPN 10 route
172.16.100.0/24 from the RIB to the BGP process to Border-Leaf-13. We are using
VRF-based eBGP IPv4 peering between vEdge-2 and Border-Leaf-13, so there is no
VN-Id carried within BGP Update message. Border-Leaf-13 verifies that the BGP
Update is valid (configured peer with the right ASN, available next-hop, and so
on). In case that update is valid, it installs route into VRF-specific RIB.
Figure 2-5: OMP Service Route to BGP on vEdge-2.
Capture
2-1 shows the BGP Update message sent by vEdge-2 to Border-Leaf-13. Note that
the Path Attribute AS_PATH has only AS 65100 that is the VPN 10 specific ASN on
vEdge-2. The OMP Service route updates don’t carry BGP ASN information and that
is why the LISP domain BGP ASN 65010 is not shown.
Internet
Protocol Version 4, Src: 172.16.20.1, Dst: 172.16.20.13
Transmission
Control Protocol, Src Port: 40769, Dst Port: 179, Seq: 20, Ack: 1, Len: 66
Border
Gateway Protocol - UPDATE Message
Marker: ffffffffffffffffffffffffffffffff
Length: 66
Type: UPDATE Message (2)
Withdrawn Routes Length: 0
Total Path Attribute Length: 39
Path attributes
Path Attribute - ORIGIN: INCOMPLETE
Path Attribute - AS_PATH: 65100
Path Attribute - NEXT_HOP: 172.16.20.1
Path Attribute - MULTI_EXIT_DISC: 1000
Path Attribute - EXTENDED_COMMUNITIES
Flags: 0xc0, Optional, Transitive,
Complete
Type Code: EXTENDED_COMMUNITIES
(16)
Length: 8
Carried extended communities: (1
community)
Route Origin: 0:20 [Transitive
2-Octet AS-Specific]
Type: Transitive 2-Octet
AS-Specific (0x00)
Subtype (AS2): Route Origin
(0x03)
2-Octet AS: 0
4-Octet AN: 20
Network Layer Reachability Information
(NLRI)
172.16.100.0/24
NLRI prefix length: 24
NLRI prefix: 172.16.100.0
Capture 2-2: BGP Update from vEdge-2 to Border-Leaf-13.
Example
2-13 shows the VRF NWKT BGP table on Border-Leaf-13.
Border-leaf-13#
show ip bgp vrf NWKT
BGP
routing table information for VRF NWKT, address family IPv4 Unicast
BGP
table version is 9, Local Router ID is 172.16.30.1
Status:
s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best
Path
type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist, I-i
njected
Origin
codes: i - IGP, e - EGP, ? - incomplete, | - multipath, & - backup, 2 - b
est2
Network Next Hop Metric LocPrf
Weight Path
*>e172.16.100.0/24 172.16.20.1 1000 0 65100 ?
Example 2-12: VRF NWKT BRIB on Border-Leaf-13.
Example
2-13 verifies that the route is also installed into VRF NWKT RIB with the
next-hop 172.16.20.1 (vEdge-2).
Border-leaf-13#
show ip route 172.16.100.0/24 vrf NWKT
IP Route
Table for VRF "NWKT"
'*'
denotes best ucast next-hop
'**'
denotes best mcast next-hop
'[x/y]'
denotes [preference/metric]
'%<string>'
in via output denotes VRF <string>
172.16.100.0/24,
ubest/mbest: 1/0
*via 172.16.20.1, [20/1000], 00:11:45,
bgp-65030, external, tag 65100
Example 2-13: VRF NWKT BRIB on Border-Leaf-13.
This
chapter describes how the routing information is sent from LISP domain edge
device Border-PxTR-13 to local SD-WAN device vEdge-1. Besides we saw the
process of how the routing information ends up into RIB of remote SD-WAN edge
device vEdge-2 and finally how it is sent to Datacenter border leaf
Border-Leaf-13. The next chapter explains how the route to network 172.16.100.0/24
ends up in the RIB of Leaf-11.
Chapter 2 Appendix A: Device config Configuration
vEdge-1
vEdge-1#
show run
system
host-name vEdge-1
system-ip 10.100.100.101
site-id 10
admin-tech-on-failure
no route-consistency-check
sp-organization-name nwkt
organization-name nwkt
vbond 10.100.0.11
aaa
auth-order local radius tacacs
usergroup basic
task system read write
task interface read write
!
usergroup netadmin
!
usergroup operator
task system read
task interface read
task policy read
task routing read
task security read
!
user admin
password
$6$siwKBQ==$wT2lUa9BSreDPI6gB8sl4E6PAJoVXgMbgv/whJ8F1C6sWdRazdxorYYTLrL6syiG6qnLABTnrE96HJiKF6QRq1
!
user ciscotacro
description CiscoTACReadOnly
group
operator
status
enabled
!
user ciscotacrw
description CiscoTACReadWrite
group
netadmin
status
enabled
!
!
logging
disk
enable
!
!
ntp
server 10.100.0.14
version 4
exit
!
!
omp
no shutdown
graceful-restart
advertise bgp
advertise connected
advertise static
!
security
ipsec
authentication-type sha1-hmac ah-sha1-hmac
!
!
vpn 0
interface ge0/0
description "Internet Transport"
ip address 10.100.0.101/24
tunnel-interface
encapsulation gre
color public-internet restrict
allow-service all
no allow-service bgp
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service ospf
no allow-service stun
allow-service https
!
no shutdown
!
interface ge0/1
description "MPLS Transport"
ip address 10.200.0.101/24
tunnel-interface
encapsulation gre
color mpls restrict
max-control-connections 0
no control-connections
allow-service all
no allow-service bgp
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service ospf
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0 10.100.0.1
ip route 0.0.0.0/0 10.200.0.1
!
vpn 10
router
bgp 65100
address-family ipv4-unicast
redistribute omp
!
neighbor 172.16.10.13
no shutdown
remote-as 65010
address-family ipv4-unicast
!
!
!
!
interface ge0/2
ip address 172.16.10.1/24
no shutdown
!
!
vpn 512
interface eth0
description Management
ip dhcp-client
no shutdown
!
ip route 0.0.0.0/0 192.168.10.1
!
vEdge-2
vEdge2#
show run
system
host-name vEdge2
system-ip 10.100.100.102
site-id 20
admin-tech-on-failure
no route-consistency-check
sp-organization-name nwkt
organization-name nwkt
vbond 10.100.0.11
aaa
auth-order local radius tacacs
usergroup basic
task system read write
task interface read write
!
usergroup netadmin
!
usergroup operator
task system read
task interface read
task policy read
task routing read
task security read
!
user admin
password
$6$siwKBQ==$wT2lUa9BSreDPI6gB8sl4E6PAJoVXgMbgv/whJ8F1C6sWdRazdxorYYTLrL6syiG6qnLABTnrE96HJiKF6QRq1
!
user ciscotacro
description CiscoTACReadOnly
group
operator
status
enabled
!
user ciscotacrw
description CiscoTACReadWrite
group
netadmin
status
enabled
!
!
logging
disk
enable
!
!
ntp
server 10.100.0.14
version 4
exit
!
!
omp
no shutdown
graceful-restart
advertise bgp
advertise connected
advertise static
!
security
ipsec
authentication-type sha1-hmac ah-sha1-hmac
!
!
vpn 0
interface ge0/0
description "Internet Transport"
ip address 10.100.0.102/24
tunnel-interface
encapsulation gre
color public-internet restrict
allow-service all
no allow-service bgp
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service ospf
no allow-service stun
allow-service https
!
no shutdown
!
interface ge0/1
description "MPLS Transport"
ip address 10.200.0.102/24
tunnel-interface
encapsulation gre
color mpls restrict
max-control-connections 0
no control-connections
allow-service all
no allow-service bgp
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service ospf
no allow-service stun
allow-service https
!
no shutdown
!
ip route 0.0.0.0/0 10.100.0.1
ip route 0.0.0.0/0 10.200.0.1
!
vpn 10
router
bgp 65100
address-family ipv4-unicast
redistribute omp
!
neighbor 172.16.20.13
no shutdown
remote-as 65030
address-family ipv4-unicast
!
!
!
!
interface ge0/2
ip address 172.16.20.1/24
no shutdown
!
!
vpn 512
interface eth0
description Management
ip dhcp-client
no shutdown
!
ip route 0.0.0.0/0 192.168.10.1
vSmart
vsmart#
show run
system
host-name vsmart
system-ip 10.100.100.13
site-id
100
admin-tech-on-failure
organization-name nwkt
vbond 10.100.0.11
aaa
auth-order local radius tacacs
usergroup basic
task system read write
task interface read write
!
usergroup netadmin
!
usergroup operator
task system read
task interface read
task policy read
task routing read
task security read
!
usergroup tenantadmin
!
user admin
password
$6$jKzSSqC2GCJveJV4$VxMCv59Qv2J.lDd2luqXXJ9dUuv3izVKXPEbE3b43AAry3n6ptI7DqunO0y0TzxaUVRGAUZ7E/ySEiWdyt8/60
!
user ciscotacro
description CiscoTACReadOnly
group
operator
status
enabled
!
user ciscotacrw
description CiscoTACReadWrite
group
netadmin
status
enabled
!
!
logging
disk
enable
!
!
ntp
server 10.100.0.14
version 4
exit
!
!
omp
no shutdown
graceful-restart
!
vpn 0
interface eth0
ip address 10.100.0.13/24
ipv6 dhcp-client
tunnel-interface
allow-service all
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
allow-service netconf
no allow-service ntp
no allow-service stun
!
no shutdown
!
ip route 0.0.0.0/0 10.100.0.1
!
vpn 512
interface eth1
ip dhcp-client
no shutdown
!
!
No comments:
Post a Comment
Note: only a member of this blog may post a comment.