Archive for June, 2008

QinQ: 802.1q Tunneling on Cisco Switches

June 23, 2008 · Filed under Service Provider · Tagged , ,

One of Metro Ethernet solution to extend Layer 2 Ethernet Connection between two customer sites is use 802.1q Tunneling, also known as QinQ.

QinQ concept is explained based on the diagram below:

Customer Switch Site A and B connected to SP (Service Provider) Edge Switch, usually use trunk mode on the port that facing to SP. SP Edge Switch use 802.1q Tunnel mode. Service Provider usually allocated one VLAN tag per-customer and used to tagging ethernet frames that coming from customer.

How the 802.1q work? See the example below:

Every frames from Customer is tagged with the SP allocated VLAN tag for customer. This process done in the SP Edge Switch that facing to the Customer Switch site A. The existing VLAN tag of the frames is not changed. So, every frames from customer will have two VLAN tag in the SP Networks. The inner tag is the customers real VLAN tag, and the outer tag is the SP VLAN Tag allocated to the customer. In the SP Edge Swtich that facing to the Site B, the outer VLAN tag is stripped, and the frames is forwarded to the Customer Site B switch.

In the diagram above, we look that every customers can use the same VLAN tags, and this will not conflicted. Every customers can not see the other customer even their VLAN tags is same, because Service Provider will tagging the customers frame with the unique per-customer VLAN tag. We see that Customer XYZ is allocated with the VLAN Tag 10 and Customer ABC with the VLAN tag 9.

Because the port from customer switch that connected to SP Edge switch can use the trunk-mode, so there are a few requirement:

  1. Port in the SP Edge switch that facing to the customer must set BPDU Filter and Root Guard to prevent the customer switches act as a STP root switch. The customer switches can see the BDPU from their opponent switches.
  2. By default, VTP between two customer switches across the Service Provider network is not work. You must configure protocol tunneling to enabled the VTP between the customer switches in both of the SP Edge Switches.
  3. UDLD, PAgP and CDP (disabled by default) can work.
  4. The maximum VLAN that can allocated to the customer is 4096 VLAN ID, because the VLAN ID field in the 802.1q frame is 12 bits.

See the example configuration of Service Provider Edge Switch below:

SPE-Site-A#sh run int f0/10
interface FastEthernet0/10
description Connection to Customer-XYZ-Site-A
switchport access vlan 10
switchport mode dot1q-tunnel

SPE-Site-A#sh run int f0/9
interface FastEthernet0/9
description Connection to Customer-ABC-Site-A
switchport access vlan 9
switchport mode dot1q-tunnel

Comments (2) »

BGP Confederation

June 14, 2008 · Filed under Service Provider · Tagged ,

My friend who now work in Dar-es-Salaam, Tanzania, asked me about BGP Confederation. He asked me why we don’t use BGP Confederation on our IP Networks nationwide, so our country just use one AS Number, and every ISP use Private AS Number.

But the answer is, no we can’t. Because the purpose of using BGP as exterior routing protocol between ISPs is to manage routing policy as flexible as possible. One of the routing policy factor is AS-Path list. Unfortunately when we use BGP Confederation, our external BGP Peers (in this point is foreign country AS, as our upstream provider for example) just saw one AS Number, that is the Confederation ID.

The other BGP Confederation characteristic is some BGP Attribute like MED and Local-Preference is can crossing along the BGP Confederation AS members (sub AS). This is the characteristic of IBGP.

This is because the BGP Confederation function is to minimizing the need of full-mesh of the BGP speakers for the IBGP updates. One Autonomous-System (AS) is dividing to several sub AS. Every sub AS is peering with the other using EBGP rule.

Below is an example of the BGP Confederation implementation:

Assumed that the IGP of the AS 100 is already working. These is the network prefixes of every router:

  • R1 = 1.1.1.1/32
  • R2 = 2.2.2.2/32
  • R3 = 3.3.3.3/32
  • R4 = 4.4.4.4/32

AS 100 consist of two sub AS, that is AS 65001 and AS 65002. AS 100 peering with AS 200 via R2. We will find that AS 200 just see AS 100 in the AS-Path list for every prefix that send to AS 200. This is because list of Confederation sub AS attribute is stripped from every prefix that send to the external BGP peers of the AS. Beside that, the global AS number is prepended to the prefixes. See the BGP table of R1 below:

  • R1#sh ip bgp
  • BGP table version is 6, local router ID is 1.1.1.1
  • Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
  • r RIB-failure, S Stale
  • Origin codes: i – IGP, e – EGP, ? – incomplete
  • Network Next Hop Metric LocPrf Weight Path
  • *> 1.1.1.1/32 0.0.0.0 0 32768 i
  • *> 2.2.2.2/32 10.1.1.2 0 0 100 i
  • *> 3.3.3.3/32 10.1.1.2 0 100 i
  • *> 4.4.4.4/32 10.1.1.2 0 100 i
  • * 10.1.1.0/24 10.1.1.2 0 0 100 i
  • *> 0.0.0.0 0 32768 i
  • R1#

If we set the MED or Local-Preference attribute in R2 (for example 200) for every prefixes that receive from R1, we will see that those attributes is send across every sub AS. See the BGP table of R4 below:

  • R4#sh ip bgp
  • BGP table version is 8, local router ID is 4.4.4.4
  • Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
  • r RIB-failure, S Stale
  • Origin codes: i – IGP, e – EGP, ? – incomplete
  • Network Next Hop Metric LocPrf Weight Path
  • *> 1.1.1.1/32 10.1.1.1 200 200 0 (65002) 200 i
  • *> 2.2.2.2/32 10.2.2.1 0 100 0 (65002) i
  • *> 3.3.3.3/32 10.3.3.1 0 100 0 (65002) i
  • *> 4.4.4.4/32 0.0.0.0 0 32768 i
  • *> 10.1.1.0/24 10.2.2.1 0 100 0 (65002) i
  • R4#

CMIIW….

Leave a comment »

« Previous entries
Next Page »