Bridging Layer 2 Across the Core

Welcome to netquirks

As this is my first blog I thought I should write a bit of an introduction. This site is dedicated to looking at interesting and, as the name suggests, quirky scenarios in the world of Network Engineering.

I’ve also added some of my study notes, GNS3 labs and other bits and pieces, so feel free to have a look around. Details of the site, including the layout and a bit about myself can be found on the About page.

Generally blogs will be divided up into three sections: the quirk, the search and the work. The quirk describes the scenario, the search describes how a solution was arrived at and the work shows the technical and command line details. I’ll try and add a new blog once a month.

I will add to this site as time goes by. Any feedback is more than welcome…

 

Bridging Layer 2 Across the Core

This first scenario looks at a case where two remote sites needed to be connected through layer 2 across a Service Provider Core and a single xconnect or changing of a BGP session type was not possible. We ended up having to combine bridging, pseudowires and trunking to provide access…

 

The quirk

The picture below shows the basic setup. We needed to combine two layer 2 domains across an MPLS core. A new connection was brought into a switch on VLAN 6 at Site A. It needed to connect over to Site B. Under normal circumstances we would build a layer 2 xconnect/pseudowire between the sites, however in this circumstance we were not able to…

For a layer 2 xconnect to be configured the terminating device must be able to determine the next-hop label to push on the top of the frame. However the gateway of the Site B Layer 2 domain was a Cisco 7200 router which ran an Option A eBGP session to our PE. This meant it wasn’t getting labels over BGP. In addition, there was no LDP between the 7200 and the PE.

We couldn’t simply configure an Option B session (and consequently move the xconnect onto the 7200) because this would involve potential downtime for the site which was unacceptable.

To make it worse, there were no cable runs between the two locations to bring up a simple layer 2 point-to-point.

It should also be noted that router-on-stick was used at Site B meaning there were other VLANs, all terminating on their own sub-interface, connected to the 7200.

In summary it looked as follows:

blog1_image1_setup

 

The search

Even though an xconnect could not go the full length, the decision was made to push one as far as was viable. So we began by creating an xconnect from PE1 to PE2. VLAN 6 was added to S1’s uplink trunk and the sub-interface that was created for it on PE1 was added to the xconnect (CLI to follow).

The problem we had to face was how to get the layer 2 connectivity around or through the 7200, with minimal disruption. A solution was found in bridging….

We configured a bridge domain on the 7200 and put two new sub-interfaces into the bridge-domain – one for the LAN interface and one for the WAN interface.

The gateway for this subnet was previously a layer 3 sub-interface on Gi0/0 (standard router-on-a-stick setup). This was changed to a BVI.

In a similar fashion a sub-interface was setup on the connecting interface on PE2. This was added to the other end of the xconnect.

What we ultimately ended up with was something that looked like this:

blog1_image2_solution

Once this was setup we could see MAC learning and L2 connectivity across the core.

 

The work

The below GNS3 topology was put together to test and demonstrate the solution before putting it into practice. This can be downloaded from the GNS3 page.

gns3_bridging_xconnect_lab_5

LDP is running between the service provider routers and loopbacks are distributed via IS-IS. IPv4 and VPNv4 relationships exist between the PEs. This config is not shown but is available on the lab download.

Host 4 represents the new incoming connection to VLAN 6. Host 2 represents a Site B device on VLAN 6. The other hosts are simply representative of other devices on other VLANs for the sake of variation.

If we look at the configuration of CE1 we can see the config behind a the basic bridging setup:

hostname CE1
!
!enable irb and bridging
bridge irb
bridge 1 protocol ieee
bridge 1 route ip
!

!Configure the WAN sub-interface beneath the main interface, assign it to the bridge domain and set the encapsulation to vlan 6
interface FastEthernet0/0
 description link to PE2
 ip address 10.1.1.1 255.255.255.252
 duplex full
!
interface FastEthernet0/0.6
 description Bridged link to PE2
 encapsulation dot1Q 6
 !Technically the WAN interface need not have the same encapsulation as the LAN interface. But the sub-interface on the PE must have the same encapsulation as this WAN interface.
 bridge-group 1
!
!The key here is that VLAN 6's sub-interfaces is added to the bridge group using the bridge-group command
interface FastEthernet1/0.5
 description VLAN 5 GATEWAY
 encapsulation dot1Q 5
 ip address 172.16.1.1 255.255.255.0
!
interface FastEthernet1/0.6
 description L2 INTERFACE FOR VLAN 6
 encapsulation dot1Q 6
 bridge-group 1
!
!Configure the bridged virtual interfaces that will act as the gateway for VLAN 6.
interface BVI1
 ip address 192.168.1.1 255.255.255.0
!
!Very basic configuration of an IPv4 eBGP neighborship with the PE for the purposes of making the LAB go.
router bgp 100
 bgp log-neighbor-changes
 neighbor 10.1.1.2 remote-as 500
 !
 address-family ipv4
  no synchronization
  redistribute connected
  neighbor 10.1.1.2 activate
  no auto-summary
 exit-address-family

Then, turning to PE2, we can see that the sub-interface for vlan 6 is pushed into an xconnect.

hostname PE2
!
!Psueduowire class is used to set the encapsulation for the xconnect
pseudowire-class CLASS_ONE
 encapsulation mpls
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
!A standard /30 IP address is configured on the main interfaces. The sub-interface, however, listens for a VLAN 6 tag and pushes traffic into an xconnect.
interface FastEthernet1/0
 description link to Site B
 ip address 10.1.1.2 255.255.255.252
 duplex full
 speed 100
!
interface FastEthernet1/0.2
 description VLAN 6 link to CE1
 encapsulation dot1Q 6
 xconnect 1.1.1.1 100 pw-class CLASS_ONE

Likewise on the PE1 side the configuration of the xconnect is very similar:

hostname PE1
!
pseudowire-class CLASS_ONE
 encapsulation mpls
!
interface FastEthernet1/1.6
 description VLAN 6 link to S1
 encapsulation dot1Q 6
 xconnect 2.2.2.2 100 pw-class CLASS_ONE
!

We can verify the successful connection of the xconnect using the show xconnect peer <ip> vcid <id> command.

PE1#sh xconnect peer 2.2.2.2 vcid 100
Legend:    XC ST=Xconnect State  S1=Segment1 State  
S2=Segment2 State  UP=Up DN=Down  AD=Admin Down      
IA=Inactive  SB=Standby  RV=Recovering  NH=No Hardware

XC ST  Segment 1                   S1 Segment 2          S2
------+---------------------------+--+-------------------+--
UP     ac   Fa1/1.6:6(Eth VLAN)    UP mpls 2.2.2.2:100    UP
PE1#

Additionally we can see MAC learning on the bridge group of router CE1 (c208.0d06.0000 is the MAC address for Host 4):

CE1#show bridge 1

Total of 300 station blocks, 298 free
Codes: P - permanent, S - self

Bridge Group 1:

    Address       Action   Interface       Age   RX count   TX count
c206.0d04.0000   forward   Fa1/0.6           0          5          4
c208.0d06.0000   forward   Fa0/0.6           0          5          5
CE1#

And finally we can see that we are able to run a ping from Host4 to Host2:

Host4#ping 192.168.1.50

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.50, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 128/167/224 ms
Host4#

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s