IPv6 over AToM pseudowire


The purpose of this lab is to show the flexibility of Layer2 VPN technology AToM (Any Transport over MPLS), which allows service providers to smoothly transit the core network from legacy layer2 technologies into a single MPLS infrastructure ready for customer IPv6 transport.

Customer transition from IPv4 to dual stack is as easy as adding an IPv6 configuration to a point-to-point segment.

The lab is organized as follow:

  • Lab topology overview
  • MPLS Core
  • Pseudowire circuit establishment over MPLS
  • Customer configuration
  • MTU
  • Offline Lab
  • Quiz
  • Conclusion

Lab topology overview

Let’s consider the following lab topology: one core MPLS and three customers. Customer1 uses Ethernet port-to-port layer2 circuit to connect to Provider Edge access router, Customer2 uses Ethernet VLAN layer2 circuit and customer3 uses Frame Relay layer2 circuit.

Picture1: High-level Lab topology

AToM pseudowire High level design

Picture2: Low-level Lab topology

AToM pseudowire low level design

MPLS Core

The MPLS core is configured independently from any pseudowire configuration.

Picture3: MPLS core

AToM-pseudowire-MPLS-core

In the core MPLS, there is practically nothing special to do. IGP and LDP configuration is straightforward. The goal is to guarantee core stability.

Make sure LDP router id is forced to a loopback interface.

Look here for the router’s main configuration:

http://hpnouri.free.fr/atom/atom-core.swf

Pseudowire circuit establishment over MPLS

Picture4: AToM Pseudowire establishment

AToM Pseudowire establishment

The configuration to establish the different pseudowires do not depend on client configuration.

Note for each virtual circuit a directed LDP session is established between PEs connecting customer sites. Each PE uses a /32 loopback IP.

Layer2 Circuit PE2 PE1
Port-to-port interface FastEthernet0/0
no cdp enable

xconnect 22.2.2.2 24 encapsulation mpls
interface FastEthernet0/0
no cdp enable
xconnect 44.4.4.4 24 encapsulation mpls
Layer2 Circuit PE2 PE1
Vlan interface FastEthernet1/0
no cdp enable
!
interface FastEthernet1/0.10

encapsulation dot1Q 10

xconnect 22.2.2.2 242 encapsulation mpls
interface FastEthernet1/0
no cdp enable
!
interface FastEthernet1/0.10

encapsulation dot1Q 10

xconnect 44.4.4.4 242 encapsulation mpls
Layer2 Circuit PE2 PE1
FR connect fratom Serial2/0 501 l2transport

xconnect 22.2.2.2 241 encapsulation mpls
!
interface Serial2/0

encapsulation frame-relay

frame-relay lmi-type cisco

frame-relay intf-type dce
connect fratom Serial2/0 105 l2transport

xconnect 44.4.4.4 241 encapsulation mpls
!
interface Serial2/0

encapsulation frame-relay

frame-relay lmi-type cisco

frame-relay intf-type dce

Now, let’s take the east side as example of configuration between clients and the provider edge

Customer configuration

Picture5: Customer circuits

AToM pseudowire customer circuits

Note the provider edge is configured independently of the client layer3 protocol IPv4/IPv6.

Customer devices are configured in dual stack.

Ethernet port-to-port pseudowire

East C1 PE1
IPv4 interface FastEthernet0/0
ip address 192.168.15.1 255.255.255.0
ip ospf 15 area 0
interface FastEthernet0/0
no cdp enable
xconnect 44.4.4.4 24 encapsulation mpls
IPv6 interface FastEthernet0/0
ipv6 address FE80::15:5 link-local
ipv6 address 2001:DB8:15::5/64
ipv6 ospf 15 area 0

Ethernet vlan pseudowire

East C3 PE1
IPv4 interface Vlan10
ip address 192.168.152.1 255.255.255.0
ip ospf 15 area 0
interface FastEthernet1/0
switchport access vlan 10
switchport mode trunk
interface FastEthernet1/0
no cdp enable
!
interface FastEthernet1/0.10
encapsulation dot1Q 10
xconnect 44.4.4.4 242 encapsulation mpls
IPv6 interface Vlan10
ipv6 address FE80::152:1 link-local
ipv6 address 2001:DB8:152::1/64
ipv6 ospf 15 area 0

Use sub-interface on PE and disable CDP on the main interface.

FR pseudowire

East C2 PE1
IPv4 interface Serial1/0
ip address 192.168.151.1 255.255.255.0
encapsulation frame-relay
ip ospf network broadcast
frame-relay interface-dlci 105
connect fratom Serial2/0 105 l2transport
xconnect 44.4.4.4 241 encapsulation mpls
!
interface Serial2/0
encapsulation frame-relay
clock rate 2016000
frame-relay lmi-type cisco
frame-relay intf-type dce
IPv6 interface Serial1/0
encapsulation frame-relay
ipv6 address FE80::151:5 link-local
ipv6 address 2001:DB8:151::5/64
ipv6 enable
ipv6 ospf network broadcast
ipv6 ospf 15 area 0
frame-relay map ipv6 FE80::151:1 105
frame-relay map ipv6 2001:DB8:151::1 105 broadcast

For the west side the client configuration is mirrored.

The offline lab provides a complete access to outcomes of large range of commands related to AToM.

The resulting virtual topology looks as follow, typical point-to-point circuits between client devices:

Picture6: Logical connections

AToM pseudowire Logical connections

MTU

Let’s analyse the path for each type of AToM:

  • VC label (identify the pseudowire) = 4 bytes
  • LDP Core switching label = 4 bytes
  • AToM header for Ethernet = 4 bytes (empty)
  • AToM header for Frame Relay = 4 bytes
  • Ethernet port-to-port = 14 bytes
  • Ethernet VLAN = 14 bytes (Ethernet port-to-port) + 4 bytes (VLAN tag) = 18 bytes
  • Frame Relay encapsulation (Cisco) = 2 bytes.

Ethernet port-to-port AToM

Edge MTU AToM header for Ethernet Ethernet port-to-port LDP Core switching label VC label
1500 4 (empty) 14 4 4 1526 bytes

Ethernet VLAN AToM

Edge MTU AToM header for Ethernet Ethernet VLAN LDP Core switching label VC label
1500 4 (empty) 18 4 4 1530 bytes

FR AToM

Edge MTU AToM header for FR FR encapsulation LDP Core switching label VC label
1500 4 2 4 4 1514 bytes

Let’s set Max calculated MTU as Interface MTU of P/PE routers

On PE1 (Fa0/1), PE2 (FA0/1) and P (Fa0/0, Fa0/1)

(config-if)# mtu 1530
#sh int fa1/0 | i MTU
MTU 1530 bytes, BW 100000 Kbit/sec, DLY 100 usec,
#

MPLS MTU <= Core interfaces MTU

It is very important to distinguish IOS commands for setting MTU:

Hardware MTU

(config-if)# mtu <>: The maximum packet length the interface can support.

IP MTU

(config-if)# ip mtu <>: The maximum size of a non-labelled IP packet without fragmentation.

MPLS MTU

(config-if)# mpls mtu <>: The maximum size of a labelled IP packet without fragmentation (<= Hardware MTU).

Ivan Pepelnjak provides an excellent article about the difference between different MTU commands.

PE2#sh mpls int fa0/1 detail
Interface FastEthernet0/1:
IP labeling enabled (ldp):
Interface config
LSP Tunnel labeling not enabled
BGP labeling not enabled
MPLS operational

MTU = 1500
PE2#

Testing end-to-end MTU

Note: Lab limitation

This lab was performed on GNS3 and I had some difficulties building MPLS core using C7200 platform with IOS 12.4(24) as P router. 3700 platform IOS doesn’t allow me to change Hardware MTU.

So the following test is done considering the maximum MTU through MPLS core of 1500 bytes.

The ping test is performed on a client site using EoMPLS VLAN to test the MTU limit

WestC3#ping
Protocol [ip]: ipv6
Target IPv6 address: 2001:db8:52::1
Repeat count [5]:
Datagram size [100]: 1400
Timeout in seconds [2]:
Extended commands? [no]: yes
Source address or interface: 2001:db8:12::1
UDP protocol? [no]:
Verbose? [no]:
Precedence [0]:
DSCP [0]:

Include hop by hop option? [no]:

Include destination option? [no]:

Sweep range of sizes? [no]: yes

Sweep min size [1400]:

Sweep max size [18024]: 1530

Sweep interval [1]: 4

Type escape sequence to abort.

Sending 165, [1400..1530]-byte ICMP Echos to 2001:DB8:52::1, timeout is 2 seconds:

Packet sent with a source address of 2001:DB8:12::1

!!!!!!!!!!!!!!!!C!. (size 1472)

. (size 1476)

. (size 1480)

. (size 1484)

. (size 1488)

. (size 1492)

. (size 1496)

. (size 1500)

. (size 1504)

. (size 1508)

. (size 1512)

. (size 1516)

. (size 1520)

. (size 1524)

. (size 1528)

… <output omitted>

Success rate is 53 percent (88/165), round-trip min/avg/max = 28/136/344 ms

WestC3#

Note that ping fails starting from a packet size of 1472.

EoMPLS VLAN pseudowire adds 30 bytes to 1472 bytes which makes the packet bigger than 1500 bytes (lab max MTU limitation).

In fact, beyond the configured MTU on the core MPLS there is an implicit 18 bytes of the underlying Ethernet.

Following an illustrating hopefully clarifies the relationship between different MTUs:

AToM pseudowire MTU

Interactive illustration of Wireshark captured MPLS core transport packet

http://hpnouri.free.fr/atom/wireshark-atom-demo/wireshark-atom-demo.swf

Selection_005_11_11

Offline Lab

http://hpnouri.free.fr/atom/offlinelabv1.swf

Selection_003_11_11

Quiz

http://hpnouri.free.fr/atom/atom-quiz/atom-quiz.swf

Selection_004_11_11

Conclusion

  • AToM pseudowires are configured independently of IPv4/IPv6, which makes the client transition from IPv4 to IPv6 transparent.
  • From the client point of view it is a directly connected point-to-point circuit.
  • Make sure MPLS core interfaces MTU are configured with the maximum packet size and the MPLS MTU is not bigger that interface hardware MTU to avoid unnecessary fragmentation.
Advertisements

VLAN hopping or double tagging using “Yersinia”


Here an example in Video of “VLAN hopping” or “double tagging” using Linux tool “yersinia”.

Some recommendation to mitigate the threat of “VLAN hopping”
– Clear Native VLAN from All .1q Trunk.
– Put unused port into unused VLAN.
– Shutdown unused port.
– Configure user ports as static access.
– Filter tagged traffic entering access ports.
– Set native VLAN an unused VLAN.
– Do not use Default Native VLAN = 1.

Example of other tools:
– Mausezahn: http://www.perihel.at/sec/mz/index.html
– Scapy: http://www.secdev.org/projects/scapy/

Differences between STP and RSTP


The following table outlines the main differences between Rapid STP (802.1w) and the legacy STP(802.1d):

STP (802.1d)

Rapid STP (802.1w)

In stable topology only the root sends BPDU and relayed by others. In stable topology all
bridges generate BPDU every Hello (2 sec) : used as “keepalives” mechanism.
Port states
Disabled
Blocking
Listening
Learning
Forwarding
Discarding (replaces disabled, blocking and listening)
Learning
Forwarding
To avoid flapping, it takes 3 seconds for a port to migrate from one protocol to another (STP / RSTP) in a mixed segment.
Port roles
Root (Forwarding)
Designated
(Forwarding)
Non-Designated
(Blocking)
Root (Forwarding)
Designated
(Forwarding)
Alternate
(Discarding)Backup (Discarding)
Additional configuration to make an end node port a port fast (in case a BPDU is received). – An edge port (end node port) is an integrated Link type which depends on the duplex : Point-to-point for full duplex & shared for half duplex).
Topology changes and convergence
Use timers for convergence (advertised by the root):
Hello
(2 sec)
Max Age
(20 sec = 10 missed hellos)
Forward delay timer (15 sec)
– Introduce proposal and agreement process for synchronization (< 1 sec).- Hello, Max Age and Forward delay timer used only for backward compatibility with standard STP
Only RSTP port receiving STP (802.1d) messages will behaves as standard STP.
Slow transition (50sec):
Blocking (20s) =>Listening (15s) =>Learning (15s) =>Forwarding
Faster transition on point-to-point and edge ports only:Less states – No learning state, doesn’t wait to be informed by others, instead, actively looks for possible failure by RLQ (Request Link Query) a feedback mechanism.
Use only 2 bits from the flag octet:Bit 7 : Topology Change Acknowledgment.Bit 0 : Topology Change Use other 6 bits of the flag octet (BPDU type 2/version 2):
Bit 1 : ProposalBit 2, 3 : Port roleBit 4 : LearningBit 5 : ForwardingBit 6 : AgreementBit 0, 7 : TCA & TCN for backward compatibility
The bridge that discover a change in the network inform the root, that in turns informs all others by sending BPDU with TCA bit set and instruct them to clear their DB entries after “short timer” (~Forward delay) expire. TC is flooded through the network, every bridge generate TC (Topology change) and inform its neighbors when it is aware of a topology change and immediately delete old DB entries.
If a non-root bridge doesn’t receive Hello for 10*Hello (advertised from the root), start claiming the root role by generating its own Hello. Wait for 3*Hello on a root port (advertised from the root) before deciding to act.
Wait until TC reach the root + short timer (~Forward delay) expires, then flash all root DB entries Delete immediately local DB except MAC of the port receiving the topology changes (proposal)

Differences between PVST and PVST+


Behind the simple “plus” in PVST+ lurk quite subtle details that can make the difference between the two concepts very fuzzy, so the goal of this post is to give you a very brief explanation and I hope enough simple to grasp about PVST and PVST+ and their relationship with the standard IEEE 802.1q:

IEEE 802.1q standard

PVST (Per VLAN Spanning Tree) Cisco proprietary

PVST+ Cisco proprietary

BPDU transported over native VLAN untagged (cannot differentiate between different VLANs), therefore support natively only one single instance of STP for all VLAN, MST (Mono Spanning Tree).

(-) Not interoperable and less flexible approach.

(+) Improve the limitation of 802.1d STP (created before VLAN) by supporting one separate instance for each VLAN, using ISL trunk only.

(-) Still not interoperable with IEEE 802.1q that supports only one STP instance.

(+) Modification of PVST: allow PVST over standard IEEE 802.1q:

1) – PVST+ native VLAN BPDUs are transported (merged) in IEEE native VLAN (CST) untagged using IEEE STP MAC 0180.0CCC.CCCD 01-80-C2-00-00-00

2)– In addition to that, PVST+ native VLAN is send a second time tunneled over IEEE 802.1q using special multicast MAC 0100.0CCC.CCCD (Shared spanning Tree, SSTP):

  1. Untagged, if PVST+ native VLAN=VLAN 1. (figure1)
  2. Tagged (coded with TLV, containing VLAN ID), if native VLAN other than VLAN 1. (figure2)

This is used exclusively for consistency check. Besides, the error “PVID-inconsistency” is generated if PVST+ BPDU is received on a VLAN different from the one it was generated from.

3)– non-native VLAN BPDUs always tunneled over IEEE 802.1q using special multicast MAC 0100.0CCC.CCCD (Shared spanning Tree, SSTP), tagged (coded with TLV, containing VLAN ID)

– Make sure the native VLAN in PVST+ regions, communicating together through IEEE 802.1q, is the same.

– Whatever the complexity of the IEEE 802.1q network, only costs at the borders with PVST+ regions counts for PVST+-IEEE 802.1q native VLAN (VLAN 1 by default) cooperate with PVST, PVST+ and MSTI (802.1s).

– PVST (ISL) instances are mapped one-to-one with PVST+ (802.1q) instances.

Figure 1: PVST+ native VLAN is VLAN 1

Figure 2: PVST+ native VLAN is different from VLAN 1

Here is what to retain :

802.1q (standard) supports only one single instance of STP

  • native VLAN (Common Spanning Tree)  – (let’s say channel 1)
  • one STP instance – (let’s say channel 2)

PVST (Cisco proprietary)

  • Support one STP instance per each VLAN
  • uses ISL trunk only.
  • Doesn’t support 802.1q

PVST+ (Cisco proprietary) Enhance PVST capabilities by allowing to transport PVST over 802.q :

  • native VLAN over “Common Spanning Tree” (over channel 1)
  • Each per-VLAN STP is encapsulated using a special Multicast MAC and transported (over channel 2)

… and little of history from Scott Morris :

“For a long time, IEEE believed there should be one common spanning tree (CST) and obviously Cisco had come out with ISL trunking and PVST allowing for multiple instances.

When the 802.1Q standard was derived, they mandated a single spanning tree, which if you followed the spec would **** the operation of PVST.  So Cisco “improvised” by merely changing the destination address to a different L2 multicast address.

The good thing about that is that in case you had a mixed environment, now any non-Cisco switch receiving a PVST+ BPDU would simply flood it out all available ports for that vlan instead of killing it if it were using the original IEEE multicast address and not in the native vlan.

Sometimes the history of “why” makes it easier to remember the details of “how”.  So PVST doesn’t “not support” 802.1Q, it’s the 802.1Q won’t support PVST.”

Scott

%d bloggers like this: