IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post, we'll take a look the more scalable and flexible L2VPN Protocol CLI variant. We'll configure a new PW between R1 and R5, we'll also migrate the PW from the "xconnect" to the L2VPN Protocol CLI to leverage "redundancy" moving forward. Keep in mind, these are 2 separate tunnels and each can have individually different configurations.
R1
interface GigabitEthernet2.20
encapsulation dot1Q 20
!
template type pseudowire CCIE
encapsulation l2tpv3
ip local interface Loopback0
!
interface pseudowire20
source template type pseudowire CCIE
encapsulation l2tpv3
neighbor 192.168.1.5 20
!
l2vpn xconnect context L2TP
member pseudowire20
member GigabitEthernet2.20
R5
interface GigabitEthernet3.20
encapsulation dot1Q 20
!
template type pseudowire CCIE
encapsulation l2tpv3
ip local interface Loopback0
!
interface pseudowire20
source template type pseudowire CCIE
encapsulation l2tpv3
neighbor 192.168.1.1 20
!
l2vpn xconnect context L2TP
member pseudowire20
member GigabitEthernet3.20
Verification of the initial configuration:
R5# sh l2tp tunnel
L2TP Tunnel Information Total tunnels 1 sessions 1
LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/
Count VPDN Group
2355360215 3142881823 R1 est 192.168.1.1 1 l2tp_default_class
The tunnel between R1 and R5 is up and operational.
R5#sh l2vpn service xconnect interface pseudowire 20
Legend: St=State XC St=State in the L2VPN Service Prio=Priority
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
m=manually selected
Interface Group Encapsulation Prio St XC St
--------- ----- ------------- ---- -- -----
VPWS name: L2TP, State: UP
pw20 192.168.1.1:20(L2TP) 0 UP UP
Gi3.20 Gi3.20:20(Eth VLAN) 0 UP UP
I migrated the configuration on R1 and R6 from the "xconnect" syntax to the L2VPN Protocol CLI with the "l2vpn xconnect context" variant. This will give R1 the ability to have peerings to R5 and R6, with one of them being in SB or standby mode.
R1
template type pseudowire CCIE
encapsulation l2tpv3
ip local interface Loopback0
!
interface pseudowire10
source template type pseudowire CCIE
encapsulation l2tpv3
neighbor 192.168.1.6 10
!
l2vpn xconnect context L2TP
member pseudowire20 group RED priority 5
member pseudowire10 group RED priority 6
member GigabitEthernet2.20
R1#sh l2tp tunnel
L2TP Tunnel Information Total tunnels 2 sessions 2
LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/
Count VPDN Group
2702183390 2981560783 R6 est 192.168.1.6 1 l2tp_default_class
3142881823 2355360215 R5 est 192.168.1.5 1 l2tp_default_class
R1 from an L2TPv3 perspective has both tunnels configured and established, which is a good sign but is also deceiving since it uses the "pseudowire" configuration option, you can't have 2 paths to the same device when advertising MACs over both peers, you'll end up in a "flip-flop" design.
R1#sh l2vpn service xconnect name L2TP
Legend: St=State XC St=State in the L2VPN Service Prio=Priority
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
m=manually selected
Interface Group Encapsulation Prio St XC St
--------- ----- ------------- ---- -- -----
VPWS name: L2TP, State: UP
pw20 RED 192.168.1.5:20(L2TP) 5 UP UP
pw10 RED 192.168.1.6:10(L2TP) 6 SB IA
Gi2.20 Gi2.20:20(Eth VLAN) 0 UP UP
To solve that issue, the L2VPN service automatically places the PW with a higher priority into SB or standby mode and the XC is inactive until, based on the redundancy group configuration, the PW with the lower priority fails, the backup PW will take over.
So there is your "redundancy" just like we same in MPLS L2 VPN.
The authentication piece is a bit different, each PW will receive it's authentication, the older and the newer styles will be used leveraging the "l2tp-class" feature, which is specific to L2TPv3 for apply "templates" to configuration items. There are 2 authentication methods, L2TP control-channel authentication and L2TPv3 control message hashing. R1 and R6 will use the older variant, and R1 and R5 will use the newer variant.
R1
l2tp-class AUTH
authentication
password CCIE_AUTH
!
interface pseudowire10
source template type pseudowire CCIE
encapsulation l2tpv3
neighbor 192.168.1.6 10
signaling protocol l2tpv3 AUTH
!
!
l2tp-class HASH
digest secret 0 CCIE_HASH hash SHA1
!
interface pseudowire20
source template type pseudowire CCIE
encapsulation l2tpv3
neighbor 192.168.1.1 20
signaling protocol l2tpv3 HASH
R5
l2tp-class HASH
digest secret 0 CCIE_HASH hash SHA1
!
interface pseudowire20
source template type pseudowire CCIE
encapsulation l2tpv3
neighbor 192.168.1.1 20
signaling protocol l2tpv3 HASH
R6
l2tp-class AUTH
authentication
password CCIE_AUTH
!
interface pseudowire10
source template type pseudowire CCIE
encapsulation l2tpv3
neighbor 192.168.1.1 10
signaling protocol l2tpv3 AUTH
R1
R1#sh l2tp class
class [AUTH]
is a statically configured class
configuration:
l2tp-class AUTH
authentication
digest check
hello 60
password CCIE_AUTH
receive-window 1024
retransmit retries 15
retransmit timeout max 8
retransmit timeout min 1
retransmit initial retries 2
retransmit initial timeout max 8
retransmit initial timeout min 1
timeout setup 300
!
class [HASH]
is a statically configured class
configuration:
l2tp-class HASH
digest secret 0 CCIE_HASH hash SHA1
digest check
hello 60
receive-window 1024
retransmit retries 15
retransmit timeout max 8
retransmit timeout min 1
retransmit initial retries 2
retransmit initial timeout max 8
retransmit initial timeout min 1
timeout setup 300
As you can see, pretty simple overall configuration wise. There are some handy debugs that will tell you there is an issue if the password is wrong. My method for making sure I don't misconfigure the authentication is to copy and paste the configuration between the peers. There is no tunnel specific output that states the tunnel is authenticated by a certain method, it does however state an L2TP class and it's associated name.
R1#sh l2tp tunnel all id 806532845 | in HASH
L2TP class for tunnel is HASH
R1#sh l2tp tunnel all id 4291111902 | in AUTH
L2TP class for tunnel is AUTH
Last but not least, we need to verify that the customers peering is up and running.
R10#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.20.13 Gi2.20 10 00:44:06 52 312 0 623
All is well!
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment