notes::::::::: (802.1q tunneling/qinq tunneling)(used for ... · (802.1q tunneling/qinq...

::::::::Notes:::::::::

(802.1q Tunneling/QinQ Tunneling)(Used for Metro-Ethernet Networks/Layer

2 VPN)

1.Layer 2 VPN over switched ethernet network (similar to lightweight

version of MPLS L2VPN)(Any transport over MPLS(AToM)/Virtual Private Lan

Services(VPLS) feature)

2.SP's PE adds additional 802.1q tag to all frames received from CE (called

'metro tag' or 'QinQ)(transport frames over the provider network)

3.PE assigns all CE facing ports to the same VLAN (one VLAN per customer

in P network)

4.deplolyed in metro-ethernet environment (transparent L2 trunk through

the services provider switches)

5.Can't be dynamically negotiated

6.cusctomer's traffic is segmented from the provider's traffic (metro tag

added and removed from end to end)

7.core of the service provider will know about the mac addresses of

customers

8.once configured CE switches will be able to see each other and won't see

any PE switches as cdp neighbors.

(802.1q Tunneling Design Issues)

1.Assumes layer 2 network end-to-end

->PE-P-PE links must all run layer 2 trunking

(implies scalability issues(ethernet inside and ethernet). If SP network

large they don't want to run layer2 everywhere, which is why MPLS layer2

VPNs over 802.1q tunnel. So both L2 and L3 services while tunneling the

traffic inside IP in the core)

2.Additional tags increase payload size (MTU issues)

->4 bytes per tag

->Potential to exceed MTU of transit path

->Ethernet doesn't support fragmentation

->PE should set the MTU higher than 1500 i.e 1504 to allow the 4 byte

metro-tag (it's important to do this)

3.Loss of control plane signaling for CE devices

->CDP, VTP, STP, etc. dropped by PE (as these are encoded with special

source and destination mac addresses and by default these can not be

inserted into the CAM table)(which is why Switch disables cdp by default)

(Layer 2 Protocol Tunneling)

1.Used to tunnel Layer 2 control plane protocols between ports

->typically used with 802.1q tunnel

2.Supports for CDP,VTP,STP,PAgP,LACP,UDLD.

(Etherchannel over 802.1 Tunnels)

1.CE can support aggregation of CE-PE links(e.g. 2xGigE per customer site)

2.Etherchannel always has to be point-to-point

(As many metro tags need as many links/ports being aggregated)(Implies one

metro tag per PE-CE link)

3.PE can tunnel negotiate aswell

4.If a frame leaves one CE and does not reach exactly the same to other

CE end then you have caused layer 2 loops

::::Commands and Configurations:::::

(802.1q tunneling/QinQ Tunneling)

->(CE/Customer Edge Switches configs)

(using a Routers S1 and S2 instead of switches in this case, just for the

lab, usually a switch with trunk connected to PE is used)

S1(config)#int f0/1.10

S1(config-if)#switchport dot1q 10

S1(config-if)#ip address 10.0.0.1 255.255.255.0
















->(Provider Core Switches configs)

SW1(config)#no vlan 2-1000

SW1(config)#vlan 100

SW1(config)#system mtu 1504 (SW1(config)#system mtu jumbo <1500-9000> /

depends on the indiviual hardware platform)

SW2(config)#no vlan 2-1000

SW2(config)#vlan 100

SW2(config)#system mtu 1504

->(PE/Provider Edge Switches configs)

SW3(config)#int f0/1

SW3(config-if)#switchport mode dot1q-tunnel (tells switch to double tag

frames)

SW3(config-if)#switchport access vlan 100 (metro vlan assignment)


SW4(config-if)#switchport mode dot1q-tunnel (tells switch to double tag

frames)

SW4(config-if)#switchport access vlan 100 (metro vlan assignment)

->(log message: %DOT1Q_Tunneling_MTU_Warning/1500 MTU insufficient/1504

required)(which is why core provider switches support MTU above 1500 and

giant/jumbo frames)

(Layer 2 Protocols Tunneling)

->(CE switched configs)

S1(config)#bridge 10 protocol ieee




S1(config-if)#bridge-group 10














->(PE switches configs)


SW3(config-if)#l2protocol-tunnel cdp

SW3(config-if)#l2protocol-tunnel rstp

SW3(config-if)#l2protocol-tunnel vtp


SW4(config-if)#l2protocol-tunnel cdp


SW4(config-if)#l2protocol-tunnel vtp

->(Avoid a problem of Customer's traffic leaking into the service

provider's network/Native VLAN PE-CE link)

if a frame from the customer's edge/CE has a native vlan that matches the

metro-vlan of the PE then the frame is not tagged by the PE, thus customer's

traffic leaks into the service provider's network. Solution to this is to

tag even the native vlan.

SW3(config)#vlan dot1q tag native

SW4(config)#vlan dot1q tag native

(Etherchannel over 802.1q/QinQ Tunnel)

(CE/Customer's Edge swicthes configs)

SW3(config)#default interface range fa0/1 - 2

SW3(config)#int range fa0/1 - 2

SW3(config-if-range)#shut

SW3(config-if-range)#channel-group 1 mode active (running

LACP/initiating negotiation)

->(will have to statically set the port-channel to trunk as DTP packets

were not tunneled through)

SW3(config)#int po1

SW3(config-if)#switchport trunk encapsulation dot1q

SW3(config-if)#switchport mode trunk

SW4(config)#default interface range fa0/1 - 2


SW4(config-if-range)#shut

SW4(config-if-range)#channel-group 1 mode passive (running LACP/listening

negotiation)

SW4(config)#int po1

SW4(config-if)#switchport trunk encapsulation dot1q

SW4(config-if)#switchport mode trunk

(PE/Customer's Edge swicthes configs)

SW1(config)#vlan 101,102 (metro vlans)

SW1(config)#default int range fa0/1 - 2

SW1(config)#int fa0/1

SW1(config-if)#switchport access vlan 101

SW1(config-if)#switchport mode dot1q-tunnel





SW1(config-if-range)#l2protocol-tunnel point-to-point lacp





SW2(config)#vlan 101,102

SW2(config)#default int range fa0/1 - 2








SW2(config-if-range)#l2protocol-tunnel point-to-point lacp





(no shut should be done once all config is done to avoid order of operation

problems and loops)


SW3(config-if-range)#no shut


SW4(config-if-range)#no shut

::::Verification/TSHOOT/Debugs/Show commands:::::

1.show dot1q-tunnel

2.sh spa vlan 100 (to check metro vlan)

3.sh int trunk

4.sh ip int bri

5.sh run int f0/1

6.sh arp

7.sh mac address-table dynamic vlan 100 (scalability issue: core of the

provider network knows the mac addresses of the end customer switches and

the hosts)

8.sh system mtu (need reloading)

9.sh l2protocol-tunnel

10.sh l2protocol-tunnel summary

11.sh run in | bridge|interface (to check CE side bridge group for stp)

12.sh spa 10 (to check end to end spanning-tree between CE switches over

the tunnel)

13.sh cdp nei (to check end to end cdp between CE switches over the tunnel)

14.sh vlan

15.sh etherchannel summary

16.sh int po1 switchport

17.sh run int fa0/1

--

(to put the interface back onto default settings)

S(config)#default int f0/1

------------------------------------------------------------

Topology Diagrams:

http://ccieccie.wordpress.com/category/ine-volume-1-lab-diagrams/

http://ccieccie.wordpress.com/category/ine-volume-1-lab-diagrams/

notes::::::::: (802.1q tunneling/qinq tunneling)(used for ... · (802.1q tunneling/qinq...

Documents