Archive

Archive for June, 2008

QinQ: 802.1q Tunneling on Cisco Switches

June 23, 2008 6 comments

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

Categories: Service Provider Tags: , ,

BGP Confederation

June 14, 2008 Leave a comment

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….

Categories: Service Provider Tags: ,

IP PIM Auto-RP in NBMA Environment

June 9, 2008 Leave a comment

One of my favourite topic when i preparing for CCIE Routing and Switching Lab is IP Multicast, especially in Auto-RP section.

There is one scenario about IP Multicast in NBMA environment that used PIM (Protocol Independent Multicast) with Auto-RP mechanism to propagate RP (Rendezvous Point) information when every interfaces that running Multicast use sparse-mode. If we put the RP Router and Mapping Agent on the spoke, the other spoke router that participated in the Multicast Group will not get the RP or Mapping Router information.

This is because there is a rule that every multicast packet that came from one physical interface, will not send back again to that interface. (Like IP Split Horizon rule in RIP). so, every packet from Mapping Agent (Router C) send to 224.0.0.40 and from RP-Candidate (Router D) send to 224.0.0.39 will not reach other spoke router(s), but can reach to Router D (forwarded from Hub Router A).

To solve this problem, Cisco give a solution, that is to break the rule above. Simply just put one command in the Multicast interface at the Hub (Router A) that connected to the spokes, ” ip pim nbma-mode “, so every packet from Mapping Agent Router or Candidate-RP Router send to Multicast Address 224.0.0.40 and 224.0.0.39 can reach the other spoke router(s).

There is another solution for this scenario, that is make a tunnel between Router B and Router C, so the multicast traffic from those routers can reach each other without need router A to forward. But to create tunnel need more effort than previous solution.

CMIIW….

Categories: Service Provider Tags: , , ,

Filtering Pornography Sites with Free Tools

June 8, 2008 Leave a comment

How to filtering pornography sites with no cost ?. Use these tools to implement your objective:

Check and learn those tools from their sites. I have been try in my networks and the result is satisfied me. Although the free database (from BigURLBlackList) just contain hundred thousand of urls/domains (comparing with the commercial database that have million of urls from Websense or ISS for example). But it is enough for our network…

You can use the Dansguard Linux Server as a gateway to your ISP like the diagram below:

Dansguardian Linux Server as a gateway to the ISP

Or you can use your default router as a gateway for all of yours workstation and use PBR (Policy Based Routing) or WCCP (Web Cache Communication Protocol) to forward every HTTP traffic to Dansguardian Server. For this purpose, you must enable the transparent proxy option in Squid, and use Redirect option in the IPTables. All of those application running in one server. You don’t need to set the proxy server address on every workstion browsers, just use the existing default gateway.

 

One of disadvantage for use these implementiation is your networks public IP Address is just one, that is your Dansguardian IP Address, because Squid and IPTables is NAT-ing your workstation IP Address. One solution to prevent NAT-ing process (so your workstation can still use it local IP) is use TProxy option in IPTables. But for this purpose, you must recompile your Linux Kernel and your IPTables application to support TProxy.

Use the links below to learn furthermore:

Controlling TCP-Half (Embryonic) Connection on Cisco PIX Firewall

June 6, 2008 Leave a comment

One solution to prevent or minimizing the risk of DoS/DDoS (Dsitributed Denial of Service) attack is to limit the tcp-half connection from outside to the inside or DMZ network (Usually every administrator of networks, put the public servers (web, ftp, mail servers, etc.) in the DMZ network).

TCP half connection is the TCP connection that not yet completed. One of the DoS/DDoS attack method is to flood the target with the TCP Syn packet. The objective of this attack is to fulfill the TCP connection slots of the target, so the legitimate traffic will not occur.

If your network use Cisco PIX Firewall, you can minimize the risk of this attack with controlling the TCP-Half (Embryonic) connection, with add an option in your Static NAT configuration like an example below:

static (dmz,outside) 123.1.2.3 192.168.100.12 netmask 255.255.255.255 tcp 0 1000

1000 is the limit of the TCP-Half connection that can occur between the outside network and the server in the DMZ network (192.168.100.12 is the local and 123.1.2.3 is the global IP Address).

At least there are two things that will happen for this scenario:

  • If until the tcp half-closed time reach the timeout value and the ACK signal is never come, then the TCP half-connection will drop by PIX Firewall. You can set the TCP Half Connection timeout with the command: ” timeout half-closed hh[:mm[:ss]] “. The default time is 10 minutes.

  • If the TCP Syn packet that coming from the outside network was spoofed active IP Address, then the real appliance that used the spoofed IP Address will send the TCP RST packet to the PIX Firewall, so the TCP half connection will be dropped.
Categories: Network Security Tags: , , ,