How bridging works in Cisco routers?

One of the layer two technologies that the CCIE candidate can face is bridging. What bridging does is that it transforms the Router’s behavior of IP routing into a switch like behavior.

The underlying commands are same, they differ when use different modes of Bridging on the router. There are three modes of bridging on Cisco routers. Transparent,  Concurrent routing and bridging, and Integrated routing and bridging.

Transparent Bridging

In this mode, the router will behave fully like a bridge (switch). It will no longer be able to do any IP routing operations. This was the legacy mode before newer modes were introduced. The syntax to run this mode is pretty simple.

no ip routing
!
bridge 1 protocol ieee \\ defining the STP protocol to be used for bridging.
!
int fa0/0
ip address 1.1.1.1 255.255.255.0
bridge-group 1
!
int fa0/1
ip address 1.1.1.1 255.255.255.0
bridge-group 1

we can still maintain reachability to the router by assigning an IP address to the bridge interfaces. But remember, the router will never be part of routing domain.

Figure 1: transparent bridging

Concurrent routing and bridging

The transparent bridging has a major limitation. what if my router is connected to both routed domain and bridge domain? It will not work. The solution was a concurrent routing and bridging mode. In this mode, the router will be divided logically into two domains. One part will be of the “ip routing” domain running routing protocols and routed ports, while the second domain is the “bridge”. The syntax is

bridge crb
ip routing
!
bridge 1 protocol ieee \\ defining the STP protocol to be used for bridging.
!
int fa0/0
bridge-group 1
!
int fa0/1
bridge-group 1

Will the router be able to route traffic between the routed and bridge domain? No. It will not. For that, the next mode was introduced.

Figure 2: concurrent routing and bridging

Integrated routing and bridging

In this mode, we would have both routing and bridging in one router. We would still be able to route traffic from and to the bridge domain.

The trick in this mode is to create a Bridged virtual interface (BVI). This interface will be used to route traffic from and to the bridged domain. Figure 3 shows the syntax.

bridge crb
ip routing
!
bridge 1 protocol ieee \\ defining the STP protocol to be used for bridging.
!
int fa0/0
bridge-group 1
!
int fa0/1
bridge-group 1

Figure 3: Integrated routing and bridging

There are other variables that can be changed for the bridging operations. But knowing the different kind of modes, how they work, and their limitation is a must know information if you are preparing for CCIE lab exam.

CCIE Datacenter

Cisco has finally announced the CCIE Datacenter Track. The rumors were out for almost a year now. Well, the wait is over. People should start taking the exam

The Track from my opinion is targeted for the Cloud services and cloud networking. As of the trend, the services are getting converged, and datacenter is becoming the connector for various sites.

The track will cover the datacenter networking, specifically the Nexus platform. The second section of the track covers the storage networking. Third part is the virtualization.  Further details can be found in https://learningnetwork.cisco.com/docs/DOC-13992

I see this as an essential for datacenter networking engineers. Specially if they want to work, and evolve into the newer technology “the Cloud”.

I would end this entry with a great article on this topic: “With CCIE Data Center, can network engineers become data center gurus?“

How to use route-target?

The main purpose of route targets is to provide connectivity between different  MPLS-VPN  networks. For example, there are three enterprises namely A, B, and C. A and B are major networks with their own MPLS-VPN.  Enterprise A requires to access some servers and resources from Enterprise C. The ISP will use route-targets to provide partial connectivity for certain private addresses routes between A and C. Then Enterprise B went and bought Enterprise C. So they would have full connectivity to C. This is all done using route targets.

The following example will provide details on how to provide partial connectivity between Enterprise A and B. Lets see how it works, the following is the configuration with brief explanation.

!
ip vrf VPN_A
rd 100:1 (organization A will usually have 100:1 as the route target)
export map RD
route-target export 100:1
route-target import 100:1
route-target import 100:66 (additionally to our normal VPN_A network, we are importing anything with route-target set to 100:66. Organization B will make set the values for 100:66)
!
interface Loopback101
ip vrf forwarding VPN_A
ip address 172.16.5.5 255.255.255.0
!
ip prefix-list FILTER seq 10 permit 172.16.5.0/24
!
route-map RD permit 10
match ip address prefix-list FILTER
set extcommunity rt  100:55 (we are setting the route target extended value to 100:55) so any routes confirming to the prefix list will not be advertised to VPN_A networks)
!
route-map RD permit 20
set extcommunity rt  100:1 (default, all networks are set to have route target of 100:1)

Now in Router 2 (the other side of cloud) we are doing the opposite. we will be importing 100:55, and re-writing the route target value for certain routes to be 100:66.

!
ip vrf VPN_B
rd 100:2
export map RD
route-target export 100:2
route-target import 100:2
route-target import 100:55
!
!
interface Loopback102
ip vrf forwarding VPN_B
ip address 192.168.6.6 255.255.255.0
!
ip prefix-list FILTER seq 10 permit 192.168.6.0/24
!
route-map RD permit 10
match ip address prefix-list FILTER
set extcommunity rt  100:66
!
route-map RD permit 20
set extcommunity rt  100:2

A diagram for such network can be seen below.

It really comes down on how good you can manipulate the route targets, setting them, importing and exporting them. Beaware, never forget to make sure that BGP is handling the extended community as it should, otherwise these routes will not be advertise anyways.  route target are the critical elements the decide which routes to be installed on which vrf route table.

Moving from Explicit Proxy to Transparent Proxy – part 4

We have reached into a finalized design to run transparent proxy setup. The figure below shows the network diagram.

This is the finalized design, i will go through the logical flow of traffic since it might not be that clear from first look. Traffic will reach the core network, from there it will be routed to PBR. The PBR process will send traffic of 80 and 443 to the load balancers, while rest of traffic will be routed with the default policy. Load balancers will load balance the proxies using two or three virtual IPs.

The proxy will be installed in one leg setup. with the feature to reflect the client source IP. This is important to have a full transparent setup, so that private IPs can be natted to pool of public IPs (instead of 1 as right now).

Once that is done, the packet shaper will insure fair share of bandwidth by dividing the big pipe into 2 or 3 main segments that will be shared based on the source IPs (group based shaping), and another dynamic partition to give the IPs fair bandwidth (user based shaping).

We have multiple firewalls and VPN concentrator to provide the required security

How to configure VRF-lite?

VRF-lite is as the name says, light version of VRF. What is VRF? It is Virtual Routing and Forwarding. It is a logical way of segregating network traffic. Mostly used with MPLS-VPN. So, lets what what is VRF-lite

According to Cisco VRF considered to be “lite” without using MPLS. Which means that creating interfaces, and running routing protocols without the use of MPLS will make it VRF-lite.

To configure VRF-lite, follow the steps:

1. Define the VRF instance by using ip vrf name
2. Give the appropriate rd values rd nn:nn
3. If using BGP, then add route-targets {export/import} nn:nn
4. Add the Interface to the VRF by using the command ip vrf forwarding name

ip vrf VPN_A

rd 100:1

!

ip vrf VPN_B

rd 100:2

!

interface FastEthernet0/0.67

encapsulation dot1Q 67

ip vrf forwarding VPN_A

ip address 155.1.67.6 255.255.255.0

!

interface FastEthernet0/0.76

encapsulation dot1Q 76

ip vrf forwarding VPN_B

ip address 155.1.76.6 255.255.255.0

!

ip route vrf VPN_A 172.16.7.0 255.255.255.0 155.1.67.7

ip route vrf VPN_B 192.168.7.0 255.255.255.0 155.1.76.7

!

ip vrf VPN_A

rd 100:1

!

ip vrf VPN_B

rd 100:2

!

!

interface Loopback101

ip vrf forwarding VPN_A

ip address 172.16.7.7 255.255.255.0

!

interface Loopback102

ip vrf forwarding VPN_B

ip address 192.168.7.7 255.255.255.0

!

!

interface Vlan67

ip vrf forwarding VPN_A

ip address 155.1.67.7 255.255.255.0

!

interface Vlan76

ip vrf forwarding VPN_B

ip address 155.1.76.7 255.255.255.0

!

ip route vrf VPN_A 0.0.0.0 0.0.0.0 155.1.67.6

ip route vrf VPN_B 0.0.0.0 0.0.0.0 155.1.76.6

Review of INE workbook I

In the process of gaining my CCIE certification, I had to select a CCIE vendor to start. I used INE workbook for the lab preparation.

The book covered almost every command possible to enter. If you read the DOC you would find that they managed to utilize all details. I was surprised by the amount of depth, but again CCIE is about doing one thing by 3 different ways.

This is what i wish for,

1. • More explanation, yes the book is detailed. but there are some points that were not explained and some other points that need more details.
   • Fix the questions/answers. Few tasks were asked in wrong manner or unclear. I found some some solutions that were not right. in some cases, the question asked something and the answer did something else.

BlueCoat Certified ProxySG Professional Exam

I have attended the BlueCoat ProxySG training for the Professional course. While i did learn a lot, in the operation of ProxySG I did learn more about Proxy operations, theory, forwarding and reverse proxy setups. It is intriguing how many things can be done with the ProxySG

What i really applaud Bluecoat, is the caching in their ProxySG. later I would write, and show you how did the traffic changed within our enterprise once we started caching youtube.

The exam was tough, not easy at all. After reading the course book, it did solidify much of the theory and information i had. But when i started doing the test, i realized how tough the exam is.

I’m glad the exam was open book, otherwise I’m very sure that I would have failed in it. It was a tough one to crack. My advice will be, be ready! Read multiple times, understand everything, and highlight any details that you can’t memorize and you think it is important.

Lastly, I would say. best of luck.

BlueCoat Certified ProxySG administrator Course

I recently have passed the Blue Coat Certified ProxySG administrator course. The exam could have been better, what i suggest to bluecoat is:

1. The questions should address the understanding of ProxySG functions.
2. NO questions about other blue coat products.
3. More efforts into the concepts and implementations of ProxySG.
4. Reduce the exam time, 4 hours is a lot.

Moving from Explicit Proxy to Transparent Proxy – part 3

While we had overall idea of the design direction, we have identified other points that were integrated into the final design. The diagram below shows the almost finalized design.

I would like to mention the hardware being used at this design, as it could provide guidelines for other network engineers when it comes to transparent proxy for enterprise networks.

1. PBR are Cisco Catalyst 6506-E with SUP720-B3, X6748 line cards
2. Proxies are Bluecoat ProxySG x5,
3. Packetshapers are Bluecoat 0 x3
4. Core layer Cisco Catalyst 6509 with SUP720-3B.

Moving from Explicit Proxy to Transparent Proxy – part 2

If you have read the first part of this series, you would know that there is major upgrade plan move from explicit proxy to transparent. One of the major objective that during migration to the new network, there should be minimal downtime. But since we are going to utilize the same hardware, downtime can’t be totally avoided. The current firewall is not able to handle the traffic going to the internet by itself.

with that in mind, we have few things to workout to finilize the network design:

1. IP addressing scheme throughout the network.
2. The integration of older firewall with the new firewall.
3. The implementation of packet shaping for provisioning IP based, and group based bandwidth.
4. How the traffic will route from the PBR to IR going by two firewalls contexts.
5. The integration of new LB by keeping the proxy traffic/control plane segregated from the other traffic.

In the above diagram, we are showing a basic idea of the connectivity. I would go into the details of hardware and logical connectivity in the next blog entry.